hi thoralf
if you create your messages with a "pack s s s f" object or with chains of "pp mov" and so on, then there will be a list output and it has to work with "route list". your patch is attached and corrected.
tm
hi thomas,
thank you for your patience ... unfortunately, it still doesn't work. The lists received and the messages do look exactly the same indeed, but route does seem to make a difference. I'm sending the whole patch - it would be great if you could have a look at how the lists are composed. The idea of this whole thing is that abstractions are sending requests for midi controllers to be assigned to control effects, I hope my comments are helpful. btw, what is this "mov"-thingie? Never heard of this before. The last thing I can think of now is to unpack the list and compose a message out of its elements.
thank you, thoralf.
___________________________________________________________ Gesendet von Yahoo! Mail - Jetzt mit 250MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Thoralf Schulze wrote:
hi thomas,
thank you for your patience ... unfortunately, it still doesn't work. The lists received and the messages do look exactly the same indeed, but route does seem to make a difference. I'm sending the whole patch - it would be great if you could have a look at how the lists are composed. The idea of this whole
oh, you are confusing lists and symbols that look like lists.
[route] works on lists: if you have a list(!) "in mov1 blur 10" and send it to a [route in], you will get "mov1 motionblur 10" out of the 1st outlet.
now you are trying to generate your list-message "in mov1 blur 2", BUT you are doing it wrong: [l2s] will take an incoming list (in your case "in mov1 blur") and convert it into a symbol 'in mov1 blur', then you create a list with this symbol and the controller-input: "'in mov1 blur' 22". this is _not_ a list of 4 elements "in", "mov1", "blur" and "22", _but_ a list only of 2 elements "in mov1 blur" and "22". now [route in] takes the 1st argument of your list (which is "in mov1 blur" instead of "in") and compares it to "in" (which is rejected, as the identifiers are not the same)
you have problems debugging it, as [print] does not show you the boundaries of symbols. if symbols where shown within single quotes you would get "'in mov1 blur' 22" while you want "'in' 'mov1' 'blur' 22" (ok, by now i assume you got it)
the solution is, to _not_ use [l2s], replace the [pack s 0] with [pack s s s 0] and the [symbol] by something that can store lists (like [l]). if you want to stay more general, you will have to construct your messages with [pp], [prepend], [glue], [add( or whatever comes to your mind.
thing is that abstractions are sending requests for midi controllers to be assigned to control effects, I hope my comments are helpful. btw, what is this "mov"-thingie? Never heard of this before.
which is a pity, as it was taken from your patch (probably instead of "mov1")
The last thing I can think of now is to unpack the list and compose a message out of its elements.
a list *is* a message. a symbol is an atom, which can be part of a list.
mfg.as.dr IOhannes
--- IOhannes m zmoelnig zmoelnig@iem.at schrieb: thanks johannes,
oh, you are confusing lists and symbols that look like lists.
i was afraid of this. your explanation made it clear ... it should probably be put somewhere in the help patches, the FAQ or some other prominent place.
hope my comments are helpful. btw, what is this "mov"-thingie? Never heard of this before.
which is a pity, as it was taken from your patch (probably instead of "mov1")
yeah. stupid me. i would blame the wonderful betriebsblindheit.
Thank you very much, Thoralf.
___________________________________________________________ Gesendet von Yahoo! Mail - Jetzt mit 250MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de