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.
surely other sssad users have encountered such a problem? are there any ideas to workaround it?
is there any way to add a creation argument to an abstraction without re-creating and re-setting the abstraction?
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__
hi frank, thanks for the reply.
your system uses extra inlets and outlets on each abstraction to load the preset data, which is something i wanted to avoid if at all possible. but saying that, i think your system has one really great advantage which i didn't imagine by myself... the preset data is also passed THRU each abstraction, so abs can be chained together and pass the preset information along that chain. if all else fails and i can't come up with anything, then i'll use that approach too.
that rjlib is looking really excellent now, by the way. been a couple of months since i checked it out, and it's really grown.
cheers. matt
Hallo, hard off hat gesagt: // hard off wrote:
your system uses extra inlets and outlets on each abstraction to load the preset data, which is something i wanted to avoid if at all possible.
Note that these are optional: You can still adjust stuff globally. But these inlets are very useful.
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
-
Frank Barknecht -
hard off