hey Jonathan thx for the screencast!
> Here's a rudimentary screencast: > http://pdblog.nfshost.com/fielddemo.webm oh yeah! that looks indeed really handy and cute :). then i guess such a circle can have (animated) inlets/outlets and "modulate" other guis and so on... nice cheers On Sat, Sep 5, 2015, at 07:31 AM, Jonathan Wilkes wrote: > 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 >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
