Yeti

Hi Alkrever,

As I am sure you have discovered, your two lists make two different sets of numbers despite having the same parameters (The first list creates 5 numbers, from 0 to 44.44, the second creates 5 numbers from 0 to 100).

I have not found a clean solution to this problem yet.

The essential difficulty some keywords (like the list) can have conflicting parameters. Consider :-

double:
from: 0
steps: 5
to: 100
stepsize: 1

The list clearly can not have numbers spanning from 0 to 100 in 5 steps when the numbers only increase in 1 unit increments.

The way Yeti currently handles these situations is by applying the parameters top to bottom, overriding parameters as they come into conflict. So the list created at each stage from top to bottom is:
from: 0 = {0, 1, ... 9}
steps: 5 = {0, 1, 2, 3, 4}
to: 100 = {0, 25, 50, 75, 100}
stepsize: 1 = {0, 1, 2, 3, 4}

I initially thought this would be the most intuitive way of dealing with conflicts since the user can see the impact of adding a new parameter to the list. But it doesn't work primarily because when you are using Yeti it is hard to know what parameters are being overridden (your first list produces what seems like the wrong list because setting 'to: 100' overrides the stepsize parameter from the default of 1 to 11.11 and steps: 5 just creates 5 numbers of this new stepsize spacing).

I am still not sure what the best way to handle this is. The options I am looking at are:

1. Making it so the parameters to keywords do not conflict. For example 'list' could be replaced with a 'range' (from, to, stepsize) and 'series' (from, stepsize, number) like in Grasshopper. I don't like this option because one advantage of text based input is being able to have a general keyword (like list) and then choosing what combination of parameters to construct it with.
2. Not allowing the user to select conflicting parameters - it is probably going to be difficult to define the logic to identify what a conflict is, and I also suspect applying two conflicting parameters could be useful in some situations.
3. Making it so the top-down behavior only happens when a conflict occurs. The problem with this is that you could end up with an even more confusing situation where the order of parameters does not matter, except in certain cases.

I am not sure how to best resolve this, so any suggestions would be welcome.

Daniel

Hi Casy,

I definitely agree it would be beneficial to tie Yeti into the Grasshopper environment. One of my first ideas for implementing Yeti was to have it function like the cluster component in Grasshopper, with the code of Yeti generating a hidden Grasshopper model. I came across three problems with this:
1. You can't (and really don't want to) add inputs and outputs to a Grasshopper node on the fly. So the inputs and outputs would have to be predefined like the C# and python nodes.
2. A node within Grasshopper has no control of the update cycle - Yeti needs this control.
3. The interface to Grasshopper locks up when an update is underway - you would not be able to type while it updates.

Essentially putting Yeti into Grasshopper necessitates that it behaves like the compiled code nodes (C# or Python) and inorder for Yeti to be a live programming environment, it was necessary for Yeti to be separate from Grasshopper.

I still want to link the two, although I was thinking perhaps making it similar to the Excel link or the Slingshot Mysql link. If you have any ideas on how to make this happen I would be really interested in hearing them.

Daniel