[PD] Preset saving with SSSAD

[András Murányi]

On Mon, Jul 29, 2013 at 7:48 PM, Jonathan Wilkes <jancsika at yahoo.com> wrote:

>  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>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.
>
> -Jonathan
>

Now that you told it, I gave myself a shot of it. Mmmmmm...! Simple and
fast and feels so good.
However... I'm afraid of locking myself in pd-l2ork. That would mean that
my songs are basically in l2ork.
Where does this thing store its data? Is it possible to dump it out in raw
form?
On the other hand, you've been using l2ork for a while, right? Can I ask
you "how does it feel", do you feel locked in, etc? You no miss 0.43
plugins...?!

Thanks,

András
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130729/32bd9545/attachment.htm>