[PD] Preset saving with SSSAD

[András Murányi]

>   [...]
>>  - 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á.


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


>  * [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/3bf5f8b6/attachment.htm>