7 Sep
2015
7 Sep
'15
7:24 p.m.
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:
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