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(
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?
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