<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div><div class="h5">
<blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<div><div><blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">[...]<br>
</div>
<div class="gmail_extra">- is the SSSAD in
s-abstractions recent enough for these tricks?
(<a href="http://code.google.com/p/s-abstractions/source/browse/#svn%2Ftrunk%2Fsssad" target="_blank">http://code.google.com/p/s-abstractions/source/browse/#svn%2Ftrunk%2Fsssad</a>)<br>
</div>
<div class="gmail_extra">- 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.<br>
</div>
<div class="gmail_extra"> - 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)?<br>
</div>
<div class="gmail_extra"> - 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?<br>
</div>
<div class="gmail_extra"> <br clear="all">
</div>
<div class="gmail_extra">...sorry for the
dependent mental state in which I am! :-o<br>
</div>
</div>
</blockquote>
<br>
</div>
</div>
I don't think it's your mental state. Those tools are
clunky.<br></div></blockquote></div></div></div></blockquote></div></div></div></blockquote><div><br></div><div>Clunky but portable. I'm still interested in an SSSAD-only solution.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div><div class="h5"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<br>
Have you looked at Ivica's [preset_hub] in Pd-l2ork?
You simply name the [preset_hub],<br>
and all the [preset_node] objects with the same name on
that canvas or a child of it<br>
(including abstractions) work together. No need to use
dollarsign arguments at all.<br>
All state is saved with the patch and adding/removing
nodes works seamlessly, even with<br>
infinite undo.<br>
<br>
His preset system even makes an automatic, hidden
connection back into the [preset_node]<br>
so you don't get crossed wires.<br>
<br>
-Jonathan</div>
</blockquote>
<div bgcolor="#FFFFFF" text="#000000"> <br>
</div>
<div bgcolor="#FFFFFF" text="#000000">Now that you told it,
I gave myself a shot of it. Mmmmmm...! Simple and fast and
feels so good.<br>
</div>
<div bgcolor="#FFFFFF" text="#000000">However... I'm afraid
of locking myself in pd-l2ork. That would mean that my
songs are basically in l2ork.<br>
</div>
<div bgcolor="#FFFFFF" text="#000000">Where does this thing
store its data? Is it possible to dump it out in raw form?<br>
</div>
</div>
</div>
</div>
</blockquote>
<br></div></div>
It stores it as hidden args to the relevant [preset_hub]. I told
Ivica I thought there should<br>
be an option to save the state out to a separate file, but he said
that would complicate<br>
things (and he's the one implementing all of it). After all, if
you're saving state for a patch,<br>
that state isn't much good outside of the context of the patch.<br></div></blockquote><div><br></div><div>Well, I just RTFM and the feature is there. You bang this into your preset_hub:<br></div><div>[symbol $1]<br>
|<br></div><div>[write $1.txt(<br></div><div>...and voilá.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
The one area that this method does not address is abstractions
managing their own state.<br>
The obvious benefit of such self-management is with gui
abstractions, where you want the<br>
abstraction to retain colors, slider values, or whatever when the
parent is saved, and without<br>
manual intervention.<br>
<br>
Maybe there's a way to "embed" a preset_hub into a canvas (as an
option in the gop dialog),<br>
so that when the patch is created as an abstraction the preset state
gets saved as args to<br>
the abstraction.<br>
<br>
Also-- I think this probably ties in somehow to the idea of
simulating named arguments<br>
by interpreting arguments after a \, as messages to the object. In
other words,<br>
[foo, pitch 1, decay 3]<br>
<br>
would be equivalent to<br>
<br>
[initbang]<br>
|<br>
[pitch 1, decay 3(<br>
|<br>
[foo]<br>
<br>
I can't remember the exact arg syntax of [preset_hub] for saving
state, but it seems like<br>
it's essentially the same idea, just with the args hidden from the
user.<div class="im"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div bgcolor="#FFFFFF" text="#000000">
</div>
<div bgcolor="#FFFFFF" text="#000000">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...?!<br>
</div>
</div>
</div>
</div>
</blockquote>
<br></div>
There are only a few things in the hard sense that could lock you
in:<br>
* Pd-l2ork uses Max-style [trigger]: e.g., [t b 123] would trigger
the number "123" then a bang<br>
(quite useful in my opinion)<br></div></blockquote><div><br></div><div>good reminder! I've just noticed a few days ago this works but wasn't fully aware it's not portable<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
* [preset_hub] isn't part of Pd-extended nor vanilla<br></div></blockquote><div><br></div><div>and i guess won't ever be<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
* discrepancy between iemgui placement on gop canvas that evidently
makes<br>
some gop abstractions not show up correctly in pd-l2ork<br></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
I think everything else would only "lock" in a user in the soft
sense, e.g., infinite undo<br>
makes you feel slightly less like you're programming on an Apple II
from the 80s.<br>
<br>
In fact there are so many of the latter type of improvements that
it's probably<br>
less work to port Pd-l2ork to Windows and OSX than it is to put
those features<br>
back into Pd-Extended and Vanilla. If Pd-l2ork incorporated the
0.43 gui changes<br>
then that's probably what I'd spend my time doing. :)<br>
<br>
-Jonathan<br>
<br></div></blockquote><div><br></div><div>make no mistake, I've been using l2ork for more than a year...<br>it's just that so far I've not burned the bridges behind me<br></div></div><br clear="all">András
</div></div>