Re: [PD] Preset saving with SSSAD

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.

-Jonathan

* [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