[PD] Preset saving with SSSAD
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
>>> - 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.
>> 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
> [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
> [pitch 1, decay 3(
> 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
>> 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. :)
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-list