> [...] >> - 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
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
