On 07/29/2013 02:49 PM, András Murányi wrote:
On Mon, Jul 29, 2013 at 7:48 PM, Jonathan Wilkes <[email protected]
<mailto:[email protected]>> wrote:
On 07/29/2013 07:50 AM, András Murányi wrote:
On Thu, Nov 25, 2010 at 10:19 AM, Frank Barknecht
<[email protected] <mailto:[email protected]>> wrote:
Hi,
On Thu, Nov 25, 2010 at 03:28:01AM +0100, András Murányi wrote:
> Cool, i was wandering around in the rj lib but i couldn't
find how this thing
> works. Can you just tell me in a nutshell please?
yeah, it's a bit convoluted, to make it play nice in the
background without a
user ever having to see a single sssad object ...
Anyway the real interesting feature you will like is not so
much the "saveonly"
message but local saving which is enabled by adding something
like "$0" as
second argument to your [sssad] objects. Such local sssad
objects cannot be controlled
via sending to "SSSAD_ADMIN" anymore! Instead you have to
send to "$0-SSSAD_ADMIN".
In rj, the [u_sssad] objects are copies of sssad.pd and they
are hidden
in [u_dispatch] objects. These objects are in almost every rj
abstraction and
handle two things: Dispatching of "tagged messages" from an
inlet to local
receivers and saving the sssad-parameters.
For example a [u_dispatch $0 freq] will turn messages like
"freq 440" into a
"440" sent to [s $0-freq] and it will also save "440" into a
local(!)
sssad-parameter called "freq" that is local to the value of $0.
Now a second utility abstraction, [u_loader] will build a
bridge between these
local sssads with their $0-SSSAD_ADMIN receivers and two
global receivers
called RJ_SCENE_LOAD and RJ_SCENE_SAVE. Actually these are
seldomly used in
rjdj scenes.
A typical idiom to get the state of all sssads in one
abstraction is to send
"save" to the $0-SSSAD_ADMIN in ony abstraction, then collect
all the responses
into messages and save these into message boxes. This is
handled inside of
[u_loader] and can be seen all over the rj library,
expecially in Andy's synths
like s_ejun or s_cwc.
If this sounds too complicated and you want to just have a
presettable
abstraction, you just need to do this:
1) add a [u_loader abstractionname-$1 $0] object
2) add a [u_dispatch $0 parametername] object for every parameter
3) daisychain all [u_dispatch] with connections and connect
the first one to an inlet.
3.1) Optionally: Connect [u_loader]'s outlet to an outlet and
route incoming
"save" messages to its inlet to save settings in the parent
patch, e.g. with [u_cocollect]
4) Call you abstractions with unique tags as first argument
Now try sending stuff to RJ_SCENE_SAVE and RJ_SCENE_LOAD and
to the inlets of
your abstractions.
Ciao
--
Frank Barknecht Do You RjDj.me? _
______footils.org__
Huh, I'm trying to pick this up (after 3 years...)
Honestly, currently my IQ seems to be less than satisfactory to
understand and utilize the advice. (It's also almost 40 degrees C
here so I'll have to think out loud...)
- 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.
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.
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)
* [preset_hub] isn't part of Pd-extended nor vanilla
* 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
Thanks,
András
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
