Hi,
attached is a small, simple, but very useful helper abstraction: [dispatcher] makes building those long [route method1 method2 method3] chains behind abstraction inlets a bit easier and also works around the problem of adding methods later on without breaking existing connections.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On 18/03/2007, at 13.16, Frank Barknecht wrote:
[dispatcher] makes building those long [route method1 method2 method3] chains behind abstraction inlets a bit easier and also works around the problem of adding methods later on without breaking existing connections.
Very neat.
It seams that [dispatcher $0 list] is in the same usefulness class as
[dispatcher $0 symbol]? Not that I think it matters much, given the
scope of said abstraction. And parallel connections gives funky
"help" message - but, again, given the scope, that got to be a fairly
dodgy use case.
Hallo, Steffen hat gesagt: // Steffen wrote:
On 18/03/2007, at 13.16, Frank Barknecht wrote:
[dispatcher] makes building those long [route method1 method2 method3] chains behind abstraction inlets a bit easier and also works around the problem of adding methods later on without breaking existing connections.
Very neat.
It seams that [dispatcher $0 list] is in the same usefulness class as
[dispatcher $0 symbol]?
Yes, right, dispatcher on "list" doesn't do anything useful as well, I'll add it to the help-patch later. For convenience the list-selector is [list trim]'d before it reaches the internal [route]. So your method inlet should not expect proper list messages.
Not that I think it matters much, given the
scope of said abstraction. And parallel connections gives funky
"help" message - but, again, given the scope, that got to be a fairly
dodgy use case.
yep, they are intended to be used in series after an inlet like:
[inlet] | [dispatcher $0 s0] | [dispatcher $0 s1] | [dispatcher $0 s2] | [dispatcher $0 s3] | [dispatcher $0 s4] | [dispatcher $0 s5]
etc. Then if you need another dispatcher because you've invented a new method to your abstraction, just add another [dispatcher $0 new] below the existing ones and use [r $0-new] wherever needed.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank, is the help patch supposed to be a working example? If it is, it doesn't seem to work for me. When I change any of the inputs, the number boxes attched to the receiving objects don't change.
Mike
On 3/18/07, Frank Barknecht fbar@footils.org wrote:
Hi,
attached is a small, simple, but very useful helper abstraction: [dispatcher] makes building those long [route method1 method2 method3] chains behind abstraction inlets a bit easier and also works around the problem of adding methods later on without breaking existing connections.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 19/03/2007, at 14.03, Mike McGonagle wrote:
Frank, is the help patch supposed to be a working example? If it is, it doesn't seem to work for me. When I change any of the inputs, the number boxes attched to the receiving objects don't change.
Excuse me for answering. What Frank didn't mention explicitly is that
It needs Pd version >=0.40. It uses a $1-$2 symbol construction which
is a new feature in Pd version 0.40.
Hence if you use Pd with a version like 0.39-2 or below it won't work.
Mike McGonagle wrote:
Frank, is the help patch supposed to be a working example? If it is, it doesn't seem to work for me. When I change any of the inputs, the number boxes attched to the receiving objects don't change.
the help-patch is working.
however, you need at least pd-0.40 (or a patched version of an older pd), to make the $1-$2 expansion work (on which the [dispatcher] relies)
fmgas.dr IOhannes
-
Frank Barknecht -
IOhannes m zmoelnig -
Mike McGonagle -
Steffen