Hi,
I'm writing an external, and I want it to have multiple named receivers that do different things (something that seems trivial for an abstraction but rather tricky for an external).
I worked out how to have multiple 'anything' inlets using a proxy class (modelled after the [list ...] internals), but I'm stuck when it comes to multiple 'anything' receivers.
If i just do:
pd_bind(myobject, gensym("blah")); pd_bind(myobject, gensym("glah"));
then myobject can't distinguish whether the message got sent to "blah" or "glah", which is loss of information that I need.
So, I somehow need to create fake objects (one for each receiver) that forward the messages to the real object (adding in some extra info unique to the receiver).
The problem is I don't know how to create the fake objects. Anyone have any ideas / example code / tips to offer?
Claude
PS:
It would have been nicer if instead of:
pd_bind(object, symbol)
there was also something like:
pd_bind_method(object, symbol, method)
or even better:
pd_bind_method(object, symbol, method, methoddata)
Hallo, Claude Heiland-Allen hat gesagt: // Claude Heiland-Allen wrote:
I'm writing an external, and I want it to have multiple named receivers that do different things (something that seems trivial for an abstraction but rather tricky for an external).
Does it really have to be multiple receivers? Maybe you could use the equivalent of [route] as in
[r GLOBAl] | [route local-1 local-2 local-3 ...]
Then you would only need one receiver (with pd_bind) and most of the rest could be copied from the "route"-code. You would however need to use specially formatted messages on the sender-side, that use these "tags" to reach their correct destination.
Ciao
Frank Barknecht wrote:
Hallo, Claude Heiland-Allen hat gesagt: // Claude Heiland-Allen wrote:
I'm writing an external, and I want it to have multiple named receivers that do different things (something that seems trivial for an abstraction but rather tricky for an external).
Does it really have to be multiple receivers?
Yes, because...
Maybe you could use the equivalent of [route] as in
[r GLOBAl] | [route local-1 local-2 local-3 ...]
Then you would only need one receiver (with pd_bind) and most of the rest could be copied from the "route"-code. You would however need to use specially formatted messages on the sender-side, that use these "tags" to reach their correct destination.
...afaik no GUI objects send these specially formatted messages.
The initial aim is to write an external that does similar to what an abstraction made up of loads of copies of
[receive $1-balb]--[list prepend balb]--[list trim]--[outlet]
would do, with 'balb' different each time, and only one outlet for the whole abstraction.
I guess I could implement this as an abstraction with internal messages, but why should externals be second-class citizens? ;)
And it's also a learning exercise, of course :)
Ciao
Thanks,
Claude
Hallo, Claude Heiland-Allen hat gesagt: // Claude Heiland-Allen wrote:
The initial aim is to write an external that does similar to what an abstraction made up of loads of copies of
[receive $1-balb]--[list prepend balb]--[list trim]--[outlet]
would do, with 'balb' different each time, and only one outlet for the whole abstraction.
Okay, sounds like a very useful time saver.
Ciao
Frank Barknecht wrote:
Hallo, Claude Heiland-Allen hat gesagt: // Claude Heiland-Allen wrote:
The initial aim is to write an external that does similar to what an abstraction made up of loads of copies of
[receive $1-balb]--[list prepend balb]--[list trim]--[outlet]
would do, with 'balb' different each time, and only one outlet for the whole abstraction.
Okay, sounds like a very useful time saver.
Ciao
Attached is a simple, unoptimized version implemented in Pd. It could be improved by exploding the abstraction into the constructor subpatch (loading abstractions NN times is slow, and fewer files mean less to go missing...).
Still haven't worked out how to do this in an external...
Claude