[PD] adding SSSAD key creation argument after creating and changing an abstraction

[Frank Barknecht]

Hallo,
hard off hat gesagt: // hard off wrote:

> i have some GOP abstractions which use the sssad system for state saving, so
> they need a creation argument to set their 'key' for sssad to identify
> them.  as so often happens, i load up a bunch of these abstractions and
> start playing around with their sliders until it sounds good, and i decide
> to save the state using sssad.  then i realize that i forgot to add the
> creation argument keys to each abstraction.
> 
> now comes the dilemma.  if i add the creation argument to the abstractions,
> their slider data will be reset and i will lose my current settings.

I don't have a solution for the argument thing, but maybe you can
learn something from the way [sssad] is used in the RjDj library. Here
[sssad] is wrapped in [u_dispatch] objects that double as a dispatcher
for messages like "pitch 120" or "vol 0.4" into an abstractions inlet. 

Inside u_dispatch, there are *local* [sssad] instances that use the
abstractions $0 to avoid global nameclashes. To make instances of the
same abstraction unique, there still is a arg1 tag used, but this is
passed to a [u_loader] abstraction that similar to the [originator]
abstraction in Memento/RRADical handles communication with a global
sssad saving system (still to be written...)

Anyway, the [u_loader] also can report settings in an abstraction to
its outlet, so even if you decide to rename the main abstractions
"tag", you can still save your current settings using the [u_loader]
outlet before.

This is all very hard to explain in a mail, so I'd invite you to check
out the RJlib from http://trac.rjdj.me/wiki/RjLibnew and see the
preset system in action in the help file for s_fm4-help.pd and
s_fm4.pd itself. 

Ciao
-- 
 Frank Barknecht            Do You RjDj.me?          _ ______footils.org__