[PD] Preset saving with SSSAD

Jonathan Wilkes jancsika at yahoo.com
Mon Jul 29 19:48:08 CEST 2013

On 07/29/2013 07:50 AM, András Murányi wrote:
> On Thu, Nov 25, 2010 at 10:19 AM, Frank Barknecht <fbar at footils.org 
> <mailto:fbar at footils.org>> wrote:
>     Hi,
>     On Thu, Nov 25, 2010 at 03:28:01AM +0100, András Murányi wrote:
>     > Cool, i was wandering around in the rj lib but i couldn't find
>     how this thing
>     > works.  Can you just tell me in a nutshell please?
>     yeah, it's a bit convoluted, to make it play nice in the
>     background without a
>     user ever having to see a single sssad object ...
>     Anyway the real interesting feature you will like is not so much
>     the "saveonly"
>     message but local saving which is enabled by adding something like
>     "$0" as
>     second argument to your [sssad] objects. Such local sssad objects
>     cannot be controlled
>     via sending to "SSSAD_ADMIN" anymore! Instead you have to send to
>     "$0-SSSAD_ADMIN".
>     In rj, the [u_sssad] objects are copies of sssad.pd and they are
>     hidden
>     in [u_dispatch] objects. These objects are in almost every rj
>     abstraction and
>     handle two things: Dispatching of "tagged messages" from an inlet
>     to local
>     receivers and saving the sssad-parameters.
>     For example a [u_dispatch $0 freq] will turn messages like "freq
>     440" into a
>     "440" sent to [s $0-freq] and it will also save "440" into a local(!)
>     sssad-parameter called "freq" that is local to the value of $0.
>     Now a second utility abstraction, [u_loader] will build a bridge
>     between these
>     local sssads with their $0-SSSAD_ADMIN receivers and two global
>     receivers
>     called RJ_SCENE_LOAD and RJ_SCENE_SAVE. Actually these are
>     seldomly used in
>     rjdj scenes.
>     A typical idiom to get the state of all sssads in one abstraction
>     is to send
>     "save" to the $0-SSSAD_ADMIN in ony abstraction, then collect all
>     the responses
>     into messages and save these into message boxes.  This is handled
>     inside of
>     [u_loader] and can be seen all over the rj library, expecially in
>     Andy's synths
>     like s_ejun or s_cwc.
>     If this sounds too complicated and you want to just have a presettable
>     abstraction, you just need to do this:
>     1) add a [u_loader abstractionname-$1 $0] object
>     2) add a [u_dispatch $0 parametername] object for every parameter
>     3) daisychain all [u_dispatch] with connections and connect the
>     first one to an inlet.
>     3.1) Optionally: Connect [u_loader]'s outlet to an outlet and
>     route incoming
>       "save" messages to its inlet to save settings in the parent
>     patch, e.g. with [u_cocollect]
>     4) Call you abstractions with unique tags as first argument
>     Now try sending stuff to RJ_SCENE_SAVE and RJ_SCENE_LOAD and to
>     the inlets of
>     your abstractions.
>     Ciao
>     --
>      Frank Barknecht            Do You RjDj.me?          _
>     ______footils.org__
> Huh, I'm trying to pick this up (after 3 years...)
> Honestly, currently my IQ seems to be less than satisfactory to 
> understand and utilize the advice. (It's also almost 40 degrees C here 
> so I'll have to think out loud...)
> - is the SSSAD in s-abstractions recent enough for these tricks? 
> (http://code.google.com/p/s-abstractions/source/browse/#svn%2Ftrunk%2Fsssad)
> - is there an example patch of SSSAD local saving available? i just 
> wish to see/understand how to save and load presets exclusive for an 
> abstraction instance.
> - or, please, is it possible to list the steps of creating SSSAD local 
> saving for an abstraction? (eventually using [presetstore]... which I 
> have attached because it's not hosted anywhere any more)?
> - is at viable at all to avoid using rjlib for this (and to use 'pure' 
> SSSAD), or I couldn't get away without all that patching that is in 
> u_loader, u_dispatch, u_cocollect etc?
> ...sorry for the dependent mental state in which I am! :-o

I don't think it's your mental state.  Those tools are clunky.

Have you looked at Ivica's [preset_hub] in Pd-l2ork?  You simply name 
the [preset_hub],
and all the [preset_node] objects with the same name on that canvas or a 
child of it
(including abstractions) work together.  No need to use dollarsign 
arguments at all.
All state is saved with the patch and adding/removing nodes works 
seamlessly, even with
infinite undo.

His preset system even makes an automatic, hidden connection back into 
the [preset_node]
so you don't get crossed wires.


> András
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130729/28feda0f/attachment-0001.htm>

More information about the Pd-list mailing list