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

cheers On Wed, Sep 2, 2015, at 10:20 PM, Jonathan Wilkes wrote:

...

Sorry, I didn't clarify that these are brand new changes I made in my port of the GUI away from tcl/tk to nw.js. I developed them as a diversion from the otherwise mind-numbing task of measuring fonts, fixing scrollbars, etc. I'll try to post a screencast later. -Jonathan On Wednesday, September 2, 2015 2:29 PM, jamal crawford threen52@ml1.net wrote: hey list, Jonathan.

You start with a struct:[struct foo float x float y canvas a b]
Then create a scalar from this struct.
The scalar will have an "x" value, a "y" value, and a canvas "a"
which gets filled with the contents of an abstraction "b.pd" that
is somewhere in Pd's search path.
Now here's the neat thing-- inside the newly instantiated "b.pd"
you can do this:
[loadbang]|[field x]|[print x]

imagine you have a drawing instruction like this:[draw rect 0 0 20 20]
When you create the scalar you get a little black box on a canvas.
With a canvas field like I described, you can right-click the scalar and choose "Open" to show a canvas window.

while trying to create [struct foo float x float y canvas a b], i get: canvas: no such type, using pd 0.46.6 what am I missing? ~/.jc

then i guess such a circle can have (animated) inlets/outlets and "modulate" other guis and so on... nice

That would essentially let you do a fancier version of GOP abstractions where you'd have more control over the visual appearance.  I decided not to get into that because a) people seem to get by with GOP abstractions ok, b) you can draw scalars in a GOP window (though it's unnecessarily complex and buggy), and c) making scalars "patchable" probably opens up a big can of worms.  And even if you get all that right, there's still the issue of what to do about ds arrays.  But if a dev fairy magically implemented it I'd be happy. :) There's also the possibility to have something like [draw inlet] which would receive messages the way [struct] does for mouse events. On the face of it that seems like a more efficient/elegant approach than creating a canvas for each scalar.  But practically specaking I don't see a use for it-- either you have a small enough number scalars that the overhead of canvases doesn't matter, or you have so many scalars (or array elements) that it'd be impractical to make xlet connections to each of them. -Jonathan

hahaha! are you kidding me? (:

I guess the next step is to make pacman eat those objects as he moves over them.

.. or maybe even make him sing?

~/.jc

On Mon, Sep 7, 2015, at 09:52 PM, Jonathan Wilkes wrote:

Btw-- the "canvas" field isn't the only

  way to avoid throwing around gpointers.

  Here's a quick pacman vector animation where I just animate by
  changing the

  attributes of the drawing instruction.  Since it's all vector
  drawings I can scale pacman

  to any size I wish without it becoming pixelated:

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

  I guess the next step is to make pacman eat those objects as he
  moves over them.

  -Jonathan

  On 09/02/2015 02:29 PM, jamal crawford wrote:

...

hey list, Jonathan.

...

You start with a struct:[struct foo float x float y canvas

      a b]

...

...

Then create a scalar from this struct. The scalar will have an "x" value, a "y" value, and a

      canvas "a" which gets filled with the contents of an
      abstraction "b.pd" that is somewhere in Pd's search path.

...

...

Now here's the neat thing-- inside the newly instantiated

      "b.pd" you can do this:

...

...

[loadbang]|[field x]|[print x]

...

imagine you have a drawing instruction like this:[draw rect 0 0 20 20]

When you create the scalar you get a little black box on a canvas. With a canvas field like I described, you can right-click the scalar and choose "Open" to show a canvas window.

...

while trying to create [struct foo float x float y canvas a

    b], i get: canvas: no such type, using pd 0.46.6

...

what am I missing?

~/.jc