hello, i am trying out the rjdj lib and i am not sure to understand correctly how should the SSSAD abstraction u_loader be used. I used SSSAD before and built a global preset manager with a coll to get an index for each preset. Now when i open the u_loader help file i can see that the "SOMETAG" argument could represent the index that would permit me to retrieve each preset but, in this example, it is not designed in a way that you can dynamically change it. So each time you save a preset it will save the values with this prefix, and i don't understand how this way you can differentiate each preset then..
So my question is, do i have to design it myself or is there a ready made global preset manager technique that i missed in this help file? Thanks for you help, delphine
Hi,
On Sun, Jun 05, 2011 at 04:53:22PM +0200, manecante wrote:
i am trying out the rjdj lib and i am not sure to understand correctly how should the SSSAD abstraction u_loader be used.
Easy: Just add one with [u_loader <name_of_abstraction>-$1 $0] to each of your abstractions and then use [u_dispatch <param> $0] to handle your parameters inside the abstraction. It's used like that all over the library. See below for a detailed explanation. If you then use the abstraction, give each instance an unique first argument (the SOMETAG).
Optionally connect the u_loader's inlet/outlet to the abstraction's control inlet/oulet (the rightmost ones), like e.g. in [s_fm4].
I used SSSAD before and built a global preset manager with a coll to get an index for each preset. Now when i open the u_loader help file i can see that the "SOMETAG" argument could represent the index that would permit me to retrieve each preset but, in this example, it is not designed in a way that you can dynamically change it.
The "SOMETAG" identifier that is used as a placeholder in many help files is used to make different instances of an abstraction unique in the view of the saving system. It is not meant to be overridable, and actually I don't see why you would need to change it dynamically.
The rj library makes extensive use of "local" sssad objects that have a second argument, usually the parent's $0. This is to avoid nameclashes. These local sssad objects don't send anything to the usual global receivers SSSAD and SSSAD_ADMIN, instead they send to $2-SSSAD rsp. $2-SSSAD_ADMIN where $2 usually is parent-$0: It is taken from the second arg in [sssad myparameter $0].
So far this is not specific to rj or [u_loader], it's just a feature of [sssad] that I'd guess you probably haven't used much. But because the main receivers now are some local $2-SSSAD, there has to be another bridge between the sssad objects in abstractions and your global coll or textfile or whatever you want to save to.
[u_loader] is that bridge: By convention it is called with the abstraction's name and $1 as argument - this $1 is replaced for example with the "SOMETAG" from above. Instead of [sssad] (rsp. [u_sssad]) usually [u_dispatch] is used in the rj abstractions as a wrapper around [sssad] - it is designed to work nicely with [u_dispatch] if used like explained above.
Now you can save everything into a textfile/messagebox or probably a coll as shown in the [u_loader] help file: Send "save" to [s RJ_SCENE_SAVE] and collect your settings through [r RJ_SCENE]. Reload or remote-control settings via [s RJ_SCENE_LOAD].
So each time you save a preset it will save the values with this prefix, and i don't understand how this way you can differentiate each preset then..
Did you make sure your "SOMETAG" is replaced with something unique (per abstraction?)
All the best,
Frank Barknecht Do You RjDj.me? _ ______footils.org__
On Mon, Jun 06, 2011 at 03:06:52PM +0200, Frank Barknecht wrote:
Easy: Just add one with [u_loader <name_of_abstraction>-$1 $0] to each of your abstractions and then use [u_dispatch <param> $0] to handle your parameters
Oops, wrong order: It's [u_dispatch $0 <param>], because that's useful to copy-paste-edit it into [r $0-<param>].
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
hello Franck, thank's a lot for your reply. I didn't have so much time this week to deeply study it but in between i went to the pure data meeting in Berlin where i met Dan Wilcox who quickly made the attached patch that illustrates the answer of my question, that apparently i did not formulate correctly :) delphine
On Tue, Jun 7, 2011 at 10:51 AM, Frank Barknecht fbar@footils.org wrote:
On Mon, Jun 06, 2011 at 03:06:52PM +0200, Frank Barknecht wrote:
Easy: Just add one with [u_loader <name_of_abstraction>-$1 $0] to each of your abstractions and then use [u_dispatch <param> $0] to handle your parameters
Oops, wrong order: It's [u_dispatch $0 <param>], because that's useful to copy-paste-edit it into [r $0-<param>].
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sat, Jun 11, 2011 at 02:56:15PM +0200, manecante wrote:
thank's a lot for your reply. I didn't have so much time this week to deeply study it but in between i went to the pure data meeting in Berlin where i met Dan Wilcox who quickly made the attached patch that illustrates the answer of my question, that apparently i did not formulate correctly :)
Or maybe I just got carried away explaing the details. :)
Anyway a similar approach to the one, Dan showed you, is used in the help files for Andy Farnell's fantastic synthesizers like s_ejun: Check out the subpatch "pd ejun_presets" for the presets.
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
-
Frank Barknecht -
manecante