[PD] Preset saving with SSSAD

Jonathan Wilkes jancsika at yahoo.com
Tue Jul 30 03:27:23 CEST 2013

On 07/29/2013 04:18 PM, András Murányi wrote:
>>>         [...]
>>>         - 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.
> Clunky but portable. I'm still interested in an SSSAD-only solution.
>>         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?
>     It stores it as hidden args to the relevant [preset_hub].  I told
>     Ivica I thought there should
>     be an option to save the state out to a separate file, but he said
>     that would complicate
>     things (and he's the one implementing all of it).  After all, if
>     you're saving state for a patch,
>     that state isn't much good outside of the context of the patch.
> Well, I just RTFM and the feature is there. You bang this into your 
> preset_hub:
> [symbol $1]
>  |
> [write $1.txt(
> ...and voilá.

Ah, nice.  I guess he added it recently.

>     The one area that this method does not address is abstractions
>     managing their own state.
>     The obvious benefit of such self-management is with gui
>     abstractions, where you want the
>     abstraction to retain colors, slider values, or whatever when the
>     parent is saved, and without
>     manual intervention.
>     Maybe there's a way to "embed" a preset_hub into a canvas (as an
>     option in the gop dialog),
>     so that when the patch is created as an abstraction the preset
>     state gets saved as args to
>     the abstraction.
>     Also-- I think this probably ties in somehow to the idea of
>     simulating named arguments
>     by interpreting arguments after a \, as messages to the object. 
>     In other words,
>     [foo, pitch 1, decay 3]
>     would be equivalent to
>     [initbang]
>     |
>     [pitch 1, decay 3(
>     |
>     [foo]
>     I can't remember the exact arg syntax of [preset_hub] for saving
>     state, but it seems like
>     it's essentially the same idea, just with the args hidden from the
>     user.
>>     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...?!
>     There are only a few things in the hard sense that could lock you in:
>     * Pd-l2ork uses Max-style [trigger]: e.g., [t b 123] would trigger
>     the number "123" then a bang
>     (quite useful in my opinion)
> good reminder! I've just noticed a few days ago this works but wasn't 
> fully aware it's not portable

Not portable to Pd-extended or Vanilla, but portable to Max/MSP.


>     * [preset_hub] isn't part of Pd-extended nor vanilla
> and i guess won't ever be
>     * discrepancy between iemgui placement on gop canvas that
>     evidently makes
>     some gop abstractions not show up correctly in pd-l2ork
>     I think everything else would only "lock" in a user in the soft
>     sense, e.g., infinite undo
>     makes you feel slightly less like you're programming on an Apple
>     II from the 80s.
>     In fact there are so many of the latter type of improvements that
>     it's probably
>     less work to port Pd-l2ork to Windows and OSX than it is to put
>     those features
>     back into Pd-Extended and Vanilla.  If Pd-l2ork incorporated the
>     0.43 gui changes
>     then that's probably what I'd spend my time doing. :)
>     -Jonathan
> make no mistake, I've been using l2ork for more than a year...
> it's just that so far I've not burned the bridges behind me
> András

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

More information about the Pd-list mailing list