----- Original Message -----
From: Jörn Nettingsmeier nettings@stackingdwarves.net To: pd-list@iem.at Cc: Sent: Saturday, May 12, 2012 7:20 AM Subject: [PD] variable receive objects?
hi *!
i'm playing around with a theatre cue player written around readanysf, which i will post on the web as soon as i'm sure it's not going to be too embarrassing - need to pick up some more pd idioms first...
so far, i've been able to create a nice gui using graph-on-parent, and all gui events are messages sent to receive objects, internally. for instance, hitting the "play" bang button will send the bang to cfPlayer$0SetPlay.
the idea is that everybody can grab this event, not just the readanysf~ object.
now i've painted myself into a corner: i want to create a midi controller abstraction which is separate from the player and gui.
to that end, i have added an outlet to my player that contains the player's unique id $0. this outlet is connected to the controller object, which can now happily send messages back to the player, using message boxes:
|inlet| <-- gets the parent player's $0 ID |set $1( | ( |; cfPlayer$1SetPlay bang(
that gives me nice separation. the problem is that i want the controller object to be able to _listen_ to player events as well as generate them, so that the midi controller always reflects the current state, even if it was initiated elsewhere, such as via the gui or by loading a playlist item.
is there a way to generate a variable receive object similar to a send via message box, whose source is defined at load time? something like this: |inlet| <-- gets the parent player's $0 ID |set $1( | ( |receive cfPlayer$1GetPlay(
[inlet] | [list append $0 | [clear, obj 20 20 receive cfPlayer$1GetPlay, obj 20 80 send $2-out, connect 0 0 1 0( | [s pd-$0-dynamic-subpatch]
[pd $0-dynamic-subpatch]
[r $0-out] | [outlet] <-- all messages to cfPlayer$1GetPlay will go here
which, of course, doesn't work.
or maybe i'm totally up the wrong alley, and someone can suggest a more idiomatic way to deal with this issue?
There isn't because Pd sucks at specifying scope for the symbol name associated with an object. Thus you are sending messages through wires so that your abstractions can build their own notion of "library" level scope.
I made a source code patch that would make stuff like this easier. Instead of passing around $0 among the abstractions of a library, I made a [to]/[from] wrapper around [s]/[r] that takes an additional argument to specify the scope. I'm still figuring out what the best interface is, but for the purposes of this thread let's say "library" scope is specified by adding the argument "mylib" after the send name. This scope is shared among all the abstractions that are located in the same directory.
That means you can just do this:
| [to GetPlay mylib]
The [to] object does this:
- prefixes "GetPlay" with the path of the abstraction's directory (using my patch to the source)
- possibly prefixes that with "__" or something (not sure if that's necessary)
- sets an internal [s] object with that send-symbol
[from GetPlay mylib] does similarly, and at the end creates a [r] object with that same symbol as an arg. Thus you can send and receive messages without wires to any of the abstractions in your library, without using $0, and with a very low likelihood of running into namespace clashes (since it is unlikely that a [s] or [r] in some other random abstraction or patch will be using a receive name prefixed with the path of your library.)
The other nice thing about the [to]/[from] wrapper is that it defaults to canvas-local scope-- that is, if you just want [s $0-foo] you type [to foo], which 95% of the time is what you want anyway (look at how many of Miller's help patches have a "Put" menu array named "array1"!)
It's trivial to wrap [s~]/[r~], [throw~]/[catch~], and any others that I'm missing. Drawback is this doesn't jibe with message box nonlocal sends which are inescapably global in scope, nor with the iemguis (which could easily have a dialog option added to define scope), nor garrays (which could, too, except that there are tons of internals/externals that specify array name with a single symbolic arg, so to be consistent with this interface you'd have to set the array symbol with a message, and now we're back to the same ugliness of sending a $0 to a message box...).
-Jonathan
what i want is this:
player doesn't know or care who's controlling it.
controller can (and does) have knowledge of the player event model.
this way, i can easily add OSC or playlist controllers later, keeping the main player nice and simple.
best,
jörn
-- Jörn Nettingsmeier Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487
Meister für Veranstaltungstechnik (Bühne/Studio) Tonmeister VDT
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list