[PD] variable receive objects?

[Jonathan Wilkes]

----- Original Message -----
> From: Jörn Nettingsmeier <nettings at stackingdwarves.net>
> To: pd-list at 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:
1. prefixes "GetPlay" with the path of the abstraction's directory (using my patch to the source)
2. possibly prefixes that with "__" or something (not sure if that's necessary)
3. 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
> 
> http://stackingdwarves.net
> 
> 
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>