[PD-dev] Re: pure devel (fwd)

[ix at replic.net]

> hm ... although i'm not really fan of cathedral building, maybe it would
> be a good idea to write down some kind of language specification and a
> list of requests.

my request is a generic 'gui' object which caches model state in the kernel and message based access to update it via inlet or remote (tcp/shm/etc) client connection and a subsequent echoing of state changes to the outlet and subscribed clients.

for example my client caches a copy of the model to avoid roundtrips when redrawing, stored as a nested-list/multidimensional-array/dictionary/wotdoucallit, say an EQ curve generator something liek this:

in tcl:
id1145 {band1 {gain 0.0 freq 11646.0 q 0.71 bqp {-0.223 0.2222 1.20000 0.3332}}..}
or python:
id1145 : {'band1' : {'gain' : 0.04, 'freq': 47.0..}}

a message like 'id234234 band1 gain 6.0' might come over from the gui, which would update that element of the model and echo the message to the outlet, making it possible to [list remap] all x's to y's and cable in a second view with the axes flipped..

how does the gui object know to set 'band1 gain' to 6.0, and not band1 to 'gain 6.0'? in PDContainer this requires 2 inlets(one for each key+value), i'd prefer one cable but that would require pd support nested lists (which i am requesting as well, of course)..

about the subscribers, some sort of masking to say 'subscribe to all' or 'just send me /patch1/subpatch2/twirly/23' and finally a way to query a list of all subscribable gui objects and the array keys, so that if one wants to use a panda3D gui that only handles an object at a time, or if tom's gui called an attribute 'juiciness' and mine expects 'juice', its simply a matter of some quick drag'n'drop remapping on the client side..

and thats all. pretty simple. :)

> basically i'm thinking of splitting up pd's messaging and dsp core from
> the rest ... still thinking about how ... and what's part of pd's
> language and what of pd's library ...