[PD] variable arguments to route

[David Merrill]

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
>   


-- 
MIT Media Lab
dmerrill at media.mit.edu