On Feb 22, 6:16 pm, David Rutten <[email protected]> wrote:
> Hi Marc,
>
> > 1) Working, separately editable/instanceable/properly previewable
> > clusters (I know, I know, it's complicated and you're working on it!!)
> > 2) A Send/Receive data component ...  I'm assuming
> > this is a fairly simple thing to implement?  It would be a godsend.
>
> It would be fairly simple to implement. And I can see the huge
> organisational benefits.
> Maybe I can slip one of these in before the next version is released.
> But since I kinda-sorta promised Bob it would be next week, I'm not
> sure if I can make that.

Wow.  Would be fantastic if you can manage it.  Otherwise, I will be
waiting patiently.  :-)



> > 3) Previewed geometry "always on top."  ... Is there an easy fix to make
> > the current preview component ALWAYS show in green over the top of all
> > red previews?
>
> I don't know. I'll have to discuss this with our main OpenGL guy, and
> then hope that it's possible in DotNET as well.
> It would incidentally be fairly easy to add Stored Preview States to
> Grasshopper. Does that sound like something you might still use if the
> other option would also be available?

I would definitely use a stored preview states function even with an
always-on-top preview.  In many cases I will be using GH for
functional diagram tools that generate different types of information
simultaneously.  The ability to save preview states would allow me to
use a single definition to generate a number of diagrams in the same
patch and switch seamlessly during presentations.  Would be fantastic.

> > 4) Gates and switches. Again, I use Max/MSP as a model... but having
> > controllable gates allows you to set up testing scenarios and quickly
> > switch between states.  Also has implications for conditional data
> > manipulation.
>
> There are some gates and merge components available now, but we need a
> lot more. Feel free to post some detailed descriptions of the
> functionality you're looking for.

Sorry, I should have been more specific.  Imagine a gate which has 5
inputs.  4 of this inputs are data streams, the fifth input is the
control number input.  The control number determines which data stream
gets passed through the gate.  In Max/MSP, you can set the gate
component to have N number of data stream inputs.  Also, conversely,
imagine a component that has two inputs, one is a data stream and the
other is the control input.  There are four outputs, and the control
input determines which output receives the data.  Attach an integer
slider to the input and you've got a simple switch.  Output a matching
data stream to the control input and you've got conditional data
manipulation.  Good stuff.

While we're talking specifics... another thing I've missed is an
inverse "Cull Nth" component.  In one recent case, I wanted to KEEP
every nth data point instead of excluding it.  Seems like it would
have been easy but I had to do a workaround with a series of numbers,
intervals, and list subsets.  Another thing I like in Max/MSP is that
most components have an additional output that gives miscellaneous
data.  Often this means boolean values about the success of the
operation or the "leftovers" generated by the component.  In my case,
the "leftovers" of the Cul Nth component would have been perfect for
this job.  Just a thought.

Thanks!

Marc

Reply via email to