Hello all -
I figured out was was happening here - I had instantiated several copies of the same object, and *each* had a netreceive object inside. Each of these netreceive objects was trying to bind to the same port, and based on playing around with it, it looks like the most recent one to ask for that port "wins". So when I thought I was seeing mis-routing in object with 0-id (I had objects 0, 1, and 2), it was really object 2 that was getting these messages, since it appears that it was the last one created as PD instantiates objects, and therefore the one that the network messages were being passed to. And object 2, of course, had a [route 2-id] box, making it not surprising at all that messages beginning with 0-id were ending up at the rightmost outlet.
One observation that comes out of this is that it would be nice to be able to change the listening port of a netreceive object with a message. Then I could have instantiated all 3 with a "dummy" port-number initially, and then changed them to dummy + $id, making them all unique. I suppose it's probably possible to instantiate the object with something like [netreceive $2 1], but that means that I still have hard-code the port numbers *somewhere*, and I am trying to make my objects very modular... Any thoughts on this?
thanks again for the help, -David
Frank Barknecht wrote:
Hallo, Chuckk Hubbard hat gesagt: // Chuckk Hubbard wrote:
It seems to only work if it is the first argument. Try my version.
No, that's probably a different error: [route] wants either symbol or float argument, mixing is illegal and will probably lead to undefined behaviour.
(This time I *did* check the help patch, unlike last time, when the same came up for [select], where mixing is allowed and I thought it wasn't. I often confuse these two. It would be nice, if both could be made to behave the same in this regard...)
It might be that this is the same error David is hitting as well, though.
Ciao