Here's a rudimentary screencast:

http://pdblog.nfshost.com/fielddemo.webm

On 09/03/2015 08:11 AM, jamal crawford wrote:

oh nice :) im looking forward to this

 

Here's a rudimentary screencast:

http://pdblog.nfshost.com/fielddemo.webm

 

I start with a little abstraction named "b.pd".  It just polls an [osc~] which is scaled and offset by some amount to compute

a value for the [field radius].  In a toplevel patch, setting the [field] does nothing.

 

However, when I create the struct with the "canvas a b" definition, it tells Pd to load up the contents of "b.pd" into memory.  And when I create the scalar "foo", I also get a canvas "b.pd" associated with that scalar.

 

Now when I set the [field radius] in that abstraction, it updates the "radius" field for that scalar.  The "radius" field also happens to be used as a parameter to [draw circle].  That means when the "radius" changes it animates the circle's radius.

 

As I make copies of the scalar you can see why this interface is so powerful-- each scalar has its own [osc~] controlling the animation at a frequency independent of the others.  You can also get each one to [throw~] a signal to a bus for sound, but I didn't do audio with this screencast.

 

None of this is particularly efficient.  But conceptually it's much easier to deal with than juggling gpointers.  Also, once you start sending a lot of animation data to the gui, sys_queugui filters out redundant messages.

 

-Jonathan