[PD] state object

[Frank Barknecht]

Hallo,
Federico hat gesagt: // Federico wrote:

> unless pd will have a standardized way of doing this, I prefer doing:
> 
> [loadbang]
> | [r slider001]
> | |
> | [set $1(
> |/
> [0(
> |
> ##
> ##
> ##
> ##
> ## <- Vslider or whatever
> |
> [s slider001]

What if I already have a receiver called "slider001" somewhere else
which does something different? ;)
 
> however this can't be packed into an abstraction (only a subpatch will
> do), and not even into a GOP abstraction, because Vslider it's too narrow.
> 

With [sssad] this looks like this: 

              [r slider]
              |
    [sssad TAG]
    |
    [vsl]
    |
    [s slider]

Instead of [r/s slider] you use direct connections in a real patch,
but this is hard to draw in ASCII. Then it would look somehow like
this: 

[vsl]X[sssad TAG]

So to retrofit a slider for state saving, you just "cross-connect" a
[ssaad TAG] object to it. One additional object, two additional
connections. In an abstraction to be reused, one normally uses
something like [sssad $1/tag] and then you create this abstraction
with a unique argument. [sssad] only uses two global receivers,
there's no further receiver-namespace-pollution besides this. It saves
symbols, floats and lists (or actually just lists, including lists
with one element).

State-saving to a [textfile] then is easily done using the idiom
described in the help patch or use Chris McCormick's [ssad/panel]
abstraction.  All this is only using builtin objects, however you can
also extend it with [pool], [coll] or whatever. 

Known bug: If you create two or more [sssad] objects with the same tag and
then delete the first one, state saving is broken until you reload the
patch.

Ciao
-- 
 Frank Barknecht                 _ ______footils.org_ __goto10.org__