Hi all - I'm having trouble instantiating a route object with $1 type variable arguments... I made the following object:
[route $1-id]
where $1 is an argument to the patch, 0 for instance - but messages like 0-id are getting sent to the rightmost outlet (trash). Does route require literal (non variable) arguments?
thanks, -David M.
Zitat von David Merrill dmerrill@media.mit.edu:
Hi all - I'm having trouble instantiating a route object with $1 type variable arguments... I made the following object:
[route $1-id]
where $1 is an argument to the patch, 0 for instance - but messages like 0-id are getting sent to the rightmost outlet (trash). Does route require literal (non variable) arguments?
no it doesnt, i use such things quite a lot. chances are high, that your message is wrong (make sure, the message's type is "1-id" and not "list")
mfg.adsr. IOhannes
thanks, -David M.
-- MIT Media Lab dmerrill@media.mit.edu
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
zmoelnig@iem.at wrote:
no it doesnt, i use such things quite a lot. chances are high, that your message is wrong (make sure, the message's type is "1-id" and not "list")
Thanks IOhannes - how can I make sure that I'm doing the right thing here - I don't really understand your recommendation. cheers, -David M.
mfg.adsr. IOhannes
thanks, -David M.
-- MIT Media Lab dmerrill@media.mit.edu
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, David Merrill hat gesagt: // David Merrill wrote:
I'm having trouble instantiating a route object with $1 type variable arguments... I made the following object:
[route $1-id]
where $1 is an argument to the patch, 0 for instance - but messages like 0-id are getting sent to the rightmost outlet (trash). Does route require literal (non variable) arguments?
No, route with arguments works. I guess you're making a different mistake. My crystal ball say, it is the one in attached patch. ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
It seems to only work if it is the first argument. Try my version. -Chuckk
On 7/6/06, Frank Barknecht fbar@footils.org wrote:
Hallo, David Merrill hat gesagt: // David Merrill wrote:
I'm having trouble instantiating a route object with $1 type variable arguments... I made the following object:
[route $1-id]
where $1 is an argument to the patch, 0 for instance - but messages like 0-id are getting sent to the rightmost outlet (trash). Does route require literal (non variable) arguments?
No, route with arguments works. I guess you're making a different mistake. My crystal ball say, it is the one in attached patch. ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I'm setting it up now, and will report back.. thanks, -David
Chuckk Hubbard wrote:
It seems to only work if it is the first argument. Try my version. -Chuckk
On 7/6/06, Frank Barknecht fbar@footils.org wrote:
Hallo, David Merrill hat gesagt: // David Merrill wrote:
I'm having trouble instantiating a route object with $1 type variable arguments... I made the following object:
[route $1-id]
where $1 is an argument to the patch, 0 for instance - but messages
like
0-id are getting sent to the rightmost outlet (trash). Does route require literal (non variable) arguments?
No, route with arguments works. I guess you're making a different mistake. My crystal ball say, it is the one in attached patch. ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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
Frank Barknecht _ ______footils.org_ __goto10.org__
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
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?
you could do something like, use one netrecieve and prepend a selector at the source(s), a [route googlizer EEGhelmet tripwire] could forward them as appropriate, exchanging the need to think about hardcoded ports with a more memorable symbol.
this assumes a netrecieve can accept connections from multiple clients at once. i havent tested. but isnt that the way it works with eg HTTP or any other low-port service? theres also [netclient] and the [OSC*] family of objects..
carmen wrote:
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?
you could do something like, use one netrecieve and prepend a selector at the source(s), a [route googlizer EEGhelmet tripwire] could forward them as appropriate, exchanging the need to think about hardcoded ports with a more memorable symbol.
this assumes a netrecieve can accept connections from multiple clients at once. i havent tested. but isnt that the way it works with eg HTTP or any other low-port service? theres also [netclient] and the [OSC*] family of objects..
If you're using UDP, anybody can send messages to a netreceive, with TCP you need to use netserver if you want more than one connection. It's probably more stable to make a netreceive or netserver for each possible port than to change the port on the fly, because the underlying socket interface has to be completely reinitialized when you change the port anyway. I think it's probably abusing the internet protocol to use randomly changing port numbers although FTP does this sometimes using a fixed port for control messages and a variable one for the file transfers.
Martin
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Frank, I'm puzzled.. Your attached version works given the inputs you've set up as an example, but mine doesn't - and I'm not sure what the difference is. I suspect that there is a difference in how the messages emerge from netreceive.. Here is my setup:
[netreceive 4955 1] | [route $1-id] | |
and everything goes to the rightmost outlet, when strings come in like: 0-id blah blah blah ..I even tried putting a [list trim] in as you suggest:
[netreceive 4955 1] | [list trim] | [route $1-id] | |
And it all *still* goes to the right.. Is it a subtle message-type-problem? thanks! -David M.
Frank Barknecht wrote:
Hallo, David Merrill hat gesagt: // David Merrill wrote:
I'm having trouble instantiating a route object with $1 type variable arguments... I made the following object:
[route $1-id]
where $1 is an argument to the patch, 0 for instance - but messages like 0-id are getting sent to the rightmost outlet (trash). Does route require literal (non variable) arguments?
No, route with arguments works. I guess you're making a different mistake. My crystal ball say, it is the one in attached patch. ;)
Ciao
#N canvas 0 0 450 300 10; #X obj 84 126 route $1-id; #X obj 84 101 inlet; #X obj 84 155 outlet; #X obj 156 156 outlet; #X connect 0 0 2 0; #X connect 0 1 3 0; #X connect 1 0 0 0;
#N canvas 0 0 777 395 10; #X obj 179 210 rid 0; #X msg 179 112 0-id 123; #X msg 264 109 list 0-id 123; #X obj 179 265 print HIT; #X msg 264 137 list 0-id 123; #X obj 264 161 list trim; #X text 164 307 Hint: Move [list trim] into the abstraction directly in frot of the[route]; #X text 180 87 HIT; #X text 268 86 MISS; #X text 374 137 HIT again; #X obj 209 236 print MISS; #X connect 0 0 3 0; #X connect 0 1 10 0; #X connect 1 0 0 0; #X connect 2 0 0 0; #X connect 4 0 5 0; #X connect 5 0 0 0;
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, David Merrill hat gesagt: // David Merrill wrote:
Frank, I'm puzzled.. Your attached version works given the inputs you've set up as an example, but mine doesn't - and I'm not sure what the difference is. I suspect that there is a difference in how the messages emerge from netreceive.. Here is my setup:
[netreceive 4955 1] | [route $1-id] | |
and everything goes to the rightmost outlet, when strings come in like: 0-id blah blah blah ..I even tried putting a [list trim] in as you suggest:
[netreceive 4955 1] | [list trim] | [route $1-id] | |
And it all *still* goes to the right.. Is it a subtle message-type-problem?
I remember strange things happen with floats in exponential notation (1.2e10) being interpreted as symbols by netsend/receive, but trying to reproduce your phenomenon I only came up with attached patch, which still hits correctly...
Could you maybe strip down your patch to the core "bug" and attach it?
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
It seems to only work with float arguments, and doesn't expand. This may be a pain in the tuckus, but [select] with one argument gives a right inlet for changing it... of course the output is only a bang, but it might be one way to set up such a thing, maybe with a [list split 1]
On 7/6/06, David Merrill dmerrill@media.mit.edu wrote:
Hi all - I'm having trouble instantiating a route object with $1 type variable arguments... I made the following object:
[route $1-id]
where $1 is an argument to the patch, 0 for instance - but messages like 0-id are getting sent to the rightmost outlet (trash). Does route require literal (non variable) arguments?
thanks, -David M.
-- MIT Media Lab dmerrill@media.mit.edu
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
carmen -
Chuckk Hubbard -
David Merrill -
Frank Barknecht -
Georg Holzmann -
Martin Peach -
zmoelnig＠iem.at