hi,
i am using mrpeach osc external to talk to/from blender. it works fine, but not when using pipelist (routeOSC-help.pd):
error: pipelist: no method for '/test'
also the millisecond_delay is: -3.424e+12, but the testing application (a simple python script) is 0.5 sec.
for now i am using only udpreceive plug into unpackOSC and finally routeOSC /test and it works fine, but what i am missing from pipelist?
pat
i get the same error too, and removing pipelist seems to work... (and why is there no Makefile for OSC ?)
but, when i want to route like /foo/bar it wont be recognised by routeOSC. (but /foo works). does /foo/bar work for you ?
On Fri, 2008-07-04 at 23:44 -0400, patrick wrote:
hi,
i am using mrpeach osc external to talk to/from blender. it works fine, but not when using pipelist (routeOSC-help.pd):
error: pipelist: no method for '/test'
also the millisecond_delay is: -3.424e+12, but the testing application (a simple python script) is 0.5 sec.
for now i am using only udpreceive plug into unpackOSC and finally routeOSC /test and it works fine, but what i am missing from pipelist?
pat
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, patrick hat gesagt: // patrick wrote:
i am using mrpeach osc external to talk to/from blender. it works fine, but not when using pipelist (routeOSC-help.pd):
error: pipelist: no method for '/test'
Seems to be a bug in routeOSC-help.pd: [pipelist] doesn't convert meta-messates like "/text something" to list-messages like "list /test/something", while [unpackOSC] spits out OSC-meta-messages. Inserting a [list] before [pipelist] can fix that.
Ciao
Frank Barknecht _ ______footils.org__
patrick wrote:
hi,
i am using mrpeach osc external to talk to/from blender. it works fine, but not when using pipelist (routeOSC-help.pd):
error: pipelist: no method for '/test'
Strange I don't get that using Pd 0.40.3-extended-20080308, just using the packOSC-help and routeOSC-help patches. I think maybe different versions of pd differ in their use of the 'list' selector.
also the millisecond_delay is: -3.424e+12, but the testing application (a simple python script) is 0.5 sec.
Could be that the python script is generating a timecode of 0.5seconds instead of the current time plus 0.5 seconds. From the spec: 'Time tags are represented by a 64 bit fixed point number. The first 32 bits specify the number of seconds since midnight on January 1, 1900, and the last 32 bits specify fractional parts of a second to a precision of about 200 picoseconds. This is the representation used by Internet NTP timestamps.' (http://opensoundcontrol.org/spec-1_0)
1900 was about 3.4 trillion milliseconds ago.
for now i am using only udpreceive plug into unpackOSC and finally routeOSC /test and it works fine, but what i am missing from pipelist?
pat
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Martin Peach hat gesagt: // Martin Peach wrote:
Strange I don't get that using Pd 0.40.3-extended-20080308, just using the packOSC-help and routeOSC-help patches. I think maybe different versions of pd differ in their use of the 'list' selector.
That would be a desaster.
I checked pipelist.c, and it doesn't have a method for "anythings", so it cannot handle meta-mnessages.
Ciao
Frank Barknecht _ ______footils.org__
Frank Barknecht wrote:
Hallo, Martin Peach hat gesagt: // Martin Peach wrote:
Strange I don't get that using Pd 0.40.3-extended-20080308, just using the packOSC-help and routeOSC-help patches. I think maybe different versions of pd differ in their use of the 'list' selector.
That would be a desaster.
I checked pipelist.c, and it doesn't have a method for "anythings", so it cannot handle meta-mnessages.
True, but [pipelist] has a list method and [routeOSC] outputs lists, or a symbol if there are no arguments following an OSC path. I can't reproduce the original problem here, at least with the latest versions of these objects, except by sending a [/test( message to [pipelist], which is not the right way to use it. That doesn't work with [pipe] either. Maybe a [pipeanything]?
Martin
Hallo, Martin Peach hat gesagt: // Martin Peach wrote:
Frank Barknecht wrote:
Hallo, Martin Peach hat gesagt: // Martin Peach wrote:
Strange I don't get that using Pd 0.40.3-extended-20080308, just using the packOSC-help and routeOSC-help patches. I think maybe different versions of pd differ in their use of the 'list' selector.
That would be a desaster.
I checked pipelist.c, and it doesn't have a method for "anythings", so it cannot handle meta-mnessages.
True, but [pipelist] has a list method and [routeOSC] outputs lists,
The help-patch for routeOSC has a [unpackOSC] before the [pipelist], and [unpackOSC] sends meta-messages without "list" selector. There is some commented code which uses "outlet_list", though, but active is "outlet_anything".
But anyway routeOSC also outputs meta-messages unless you have messages starting with a number (which are autoconverted to lists by Pd). At least in attached example my version of routeOSC (current svn-trunk) routes to the the left outlet of [route a]. list-messages would go to the right outlet, as the example on the right shows.
Ciao
Frank Barknecht _ ______footils.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
But anyway routeOSC also outputs meta-messages unless you have messages starting with a number (which are autoconverted to lists by Pd).
Oh, and I actually think, [routeOSC] is right to do so, as it's compatible with [OSCroute] then.
Ciao
Frank Barknecht _ ______footils.org__
Frank Barknecht wrote:
Hallo, Martin Peach hat gesagt: // Martin Peach wrote:
Frank Barknecht wrote:
Hallo, Martin Peach hat gesagt: // Martin Peach wrote:
Strange I don't get that using Pd 0.40.3-extended-20080308, just using the packOSC-help and routeOSC-help patches. I think maybe different versions of pd differ in their use of the 'list' selector.
That would be a desaster.
I checked pipelist.c, and it doesn't have a method for "anythings", so it cannot handle meta-mnessages.
True, but [pipelist] has a list method and [routeOSC] outputs lists,
The help-patch for routeOSC has a [unpackOSC] before the [pipelist], and [unpackOSC] sends meta-messages without "list" selector. There is some commented code which uses "outlet_list", though, but active is "outlet_anything".
But anyway routeOSC also outputs meta-messages unless you have messages starting with a number (which are autoconverted to lists by Pd). At least in attached example my version of routeOSC (current svn-trunk) routes to the the left outlet of [route a]. list-messages would go to the right outlet, as the example on the right shows.
Aaargh... I was looking at an older version of [unpackOSC], before it was modified (zmoelnig's patch 1959417). I guess the best solution is to make [pipelist] accept lists without the list selector (aka meta-messages) then. I think it would be even better if [pipe] would pipe lists and meta-messages too, so there would be no need for a separate [pipelist].
I'm getting the feeling that list is becoming deprecated in favour of meta-messages, since the 'list' selector is redundant. Is that right?
Martin
Quoting Martin Peach martin.peach@sympatico.ca:
Aaargh... I was looking at an older version of [unpackOSC], before it was modified (zmoelnig's patch 1959417). I guess the best solution is to
sorry if i caused confusion here.
make [pipelist] accept lists without the list selector (aka meta-messages) then.
i agree.
I'm getting the feeling that list is becoming deprecated in favour of meta-messages, since the 'list' selector is redundant. Is that right?
no, it's just something different.
a list is "only data", without a special meaning attached to it via a
selector.
(implying: the selector puts the data into a special context)
as i understand it, an OSC message is a kind of generic message
(meta-message) with a selector (the address) and the data (the rest).
it is _not_ just a list that happens to have a symbol as the first argument.
that was the reason for my patch (stripping the "list"): make it
in-line with Pd's messages (as used e.g. in [route]; [route bla] will
not route "list bla 12", and rightly so)
i hope it makes sense.
fgmasdr. IOhannes
This message was sent using IMP, the Internet Messaging Program.
Hallo, zmoelnig@iem.at hat gesagt: // zmoelnig@iem.at wrote:
Quoting Martin Peach martin.peach@sympatico.ca:
I'm getting the feeling that list is becoming deprecated in favour of meta-messages, since the 'list' selector is redundant. Is that right?
no, it's just something different.
They are very different, and how different meta-messages and list-messages are can be seen clearly by seding a "list set a" message and a "set a" message to a message-object like [$1 $2(.
It's not that one can be replaced by the other or that one is becoming redundant. One could argue, that they were redundant in the first place, but it's too late. ;)
Ciao
Frank Barknecht _ ______footils.org__
zmoelnig@iem.at wrote:
Quoting Martin Peach martin.peach@sympatico.ca:
Aaargh... I was looking at an older version of [unpackOSC], before it was modified (zmoelnig's patch 1959417). I guess the best solution is to
sorry if i caused confusion here.
No problem, I had forgotten about that patch.
make [pipelist] accept lists without the list selector (aka meta-messages) then.
i agree.
OK, the latest [pipelist] in svn pipes lists as well as meta-messages.
I'm getting the feeling that list is becoming deprecated in favour of meta-messages, since the 'list' selector is redundant. Is that right?
no, it's just something different. a list is "only data", without a special meaning attached to it via a
selector. (implying: the selector puts the data into a special context)
...but isn't 'list' a selector as well? What is special about it apart from the existence of list methods in Pd? Couldn't one use outlet_anything for lists as well? It seems that outlet_list just prepends a 'list' selector to the rest of the atoms, and a list method on an inlet just strips it and passes the rest.
as i understand it, an OSC message is a kind of generic message
(meta-message) with a selector (the address) and the data (the rest). it is _not_ just a list that happens to have a symbol as the first argument.
Yes.
i hope it makes sense.
I'm getting there;)
Martin
On Sun, 6 Jul 2008, Martin Peach wrote:
...but isn't 'list' a selector as well? What is special about it apart from the existence of list methods in Pd? Couldn't one use outlet_anything for lists as well?
List messages are special because in plain Pd, there is no list atomtype, but there is a wish to take a list as being one datatype. At the same time, there is a need for messages that could be implemented as lists but that handle special functions. Therefore, anything() is the all-inclusive method for messages, and list() is a special case of anything() with s=&s_list. Other builtin selectors are special cases of list() even though they have a different selector, because that selector mutates automatically.
I think of the list-vs-anything distinction as being a good idea, while I tend to think of the selector mutation as being a bad idea, which could have been dealt with in several other ways (depending on other features that could have been dealt with differently), but this is largely theoretical, as we wouldn't be able to change it without having pd stop being pd.
It seems that outlet_list just prepends a 'list' selector to the rest of the atoms,
Yes, it's just a call to anything() with an implicit s=&s_list ... outlet_float and such are a tiny bit more complex as they build a t_atom[1] on top of that.
and a list method on an inlet just strips it and passes the rest.
Actually, it does not even strip it. The function-pointer signature for class_addanything and class_addlist are the same.
i hope it makes sense.
I'm getting there;)
The origin of the concept of selector is the method-names in object-oriented language (it is called "selector" in several of those languages). For example, if you define a member function named "open" in C++, or use class_addmethod(...gensym("open")...), or use [route open] on a leftmost [inlet] and connect something to the left outlet, what it does is morally equivalent.
PS: For further confusion, [route open] does the wrong thing by default, as the resulting message doesn't have the same $1 anymore... it would make more sense to just replace the selector by &s_list and let the user do [list trim] if (s)he wants, given what one would most want to do with a [route] on an [inlet].
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Martin Peach wrote:
make [pipelist] accept lists without the list selector (aka meta-messages) then.
i agree.
OK, the latest [pipelist] in svn pipes lists as well as meta-messages.
the problem with this is that the object behaves "weird" if it is also meant to have "special" messages.
e.g. [pipelist] had a special message "clear" (or so). now what happens if it pipes just _any_ message: will "clear" be piped or will it clear the buffer? whatever you chose, people will complain.
i was a bit hasty when i shouted "i agree"....
(the other, more clumsy solution was of course to use [list]->[pipelist]->[list trim])
fgmadsr IOhannes
IOhannes m zmoelnig wrote:
Martin Peach wrote:
make [pipelist] accept lists without the list selector (aka meta-messages) then.
i agree.
OK, the latest [pipelist] in svn pipes lists as well as meta-messages.
the problem with this is that the object behaves "weird" if it is also meant to have "special" messages.
e.g. [pipelist] had a special message "clear" (or so). now what happens if it pipes just _any_ message: will "clear" be piped or will it clear the buffer?
It has 'clear' and 'flush'. I suppose (without trying it right now) that those two will be interpreted as messages to pipelist, since the 'anything' method is called as a last resort by Pd when no method matches the selector. Perhaps renaming them to 'clearpipe' and 'flushpipe' would reduce the possibility of confusion; it's unlikely that anyone would want to send those two messages for any other reason, except to be perverse, like sending a clear message to a second pipelist...
whatever you chose, people will complain.
i was a bit hasty when i shouted "i agree"....
(the other, more clumsy solution was of course to use [list]->[pipelist]->[list trim])
Well now it handles lists as well as meta-messages, so you could do that as well, and send 'list clear' if you don't want 'clear' to be interpreted.
Martin
On Tue, 8 Jul 2008, Martin Peach wrote:
It has 'clear' and 'flush'. I suppose (without trying it right now) that those two will be interpreted as messages to pipelist, since the 'anything' method is called as a last resort by Pd when no method matches the selector. Perhaps renaming them to 'clearpipe' and 'flushpipe' would reduce the possibility of confusion;
You can eliminate the possibility of confusion by requiring that a "send" selector be prepended, just like it is for [netsend]. However, [list prepend send] doesn't cut it because [route send] doesn't undo it properly: "list a b c" becomes "a b c"... see my last email.
We need something called [list untrim] and/or [unroute].
C'est assez déroutant... ou dégoûtant: c'est selon.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Mathieu Bouchard wrote:
On Tue, 8 Jul 2008, Martin Peach wrote:
You can eliminate the possibility of confusion by requiring that a "send" selector be prepended, just like it is for [netsend]. However, [list prepend send] doesn't cut it because [route send] doesn't undo it properly: "list a b c" becomes "a b c"... see my last email.
what's the exact difference between your solution prepending "send" and my solution prepending "list"?
+-> "send a b c"--+
"list a b c" -+ +-> "a b c" +-> "list a b c" -+
fmgasd.r IOhannes
On Wed, 9 Jul 2008, IOhannes m zmoelnig wrote:
what's the exact difference between your solution prepending "send" and my solution prepending "list"?
Mine is more like [netsend].
If/when both solutions work perfectly, they should be pretty equivalent. Besides, I didn't see your solution when I posted mine.
No matter which selector is prepended, the difficulty is in prepending it correctly. There's no easy solution for that though. As long as you don't try to support both list and non-list messages at the same time in a given patch, you won't have to deal with the problem of constructing "list list" or "send list" messages correctly.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Tue, 8 Jul 2008, IOhannes m zmoelnig wrote:
(the other, more clumsy solution was of course to use [list]->[pipelist]->[list trim])
This doesn't work with real lists, because [list] won't prepend an extra list selector, so [list trim] will remove that when $1 is a symbol. Then you can use [route list] to distinguish that, but it will have the side effect of removing the list selector from a list when $1 is a symbol, but you can add it back once or twice using [list prepend list], which will add it twice when $1 was a symbol (except "list"), and once otherwise; then [list trim] will exactly undo the [list prepend list] or the [list] that the message went through depending on the case.
e.g. "a b c" becomes "list a b c" and then "a b c" again, fine, but your way, "list a b c" stays "list a b c" and then becomes "a b c", which is wrong; instead you [route list] which turns "list a b c" into "a b c", at which point you know it was a list that you just trimmed, therefore with [list prepend list] it becomes "list list a b c" which will go through [list trim] to become "list a b c".
However I can't think of a solution for dealing with "list list a b c" going through [route list] to become "list a b c" then through [list prepend list] to become "list list a b c" and not "list list list a b c", in which case it will end up being trimmed to "list a b c" instead of "list list a b c". But I know I can't just tell you to use [route2] instead of [route] for this case.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
However I can't think of a solution for dealing with "list list a b c" going through [route list] to become "list a b c" then through [list prepend list] to become "list list a b c" and not "list list list a b c", in which case it will end up being trimmed to "list a b c" instead of "list list a b c". But I know I can't just tell you to use [route2] instead of [route] for this case.
Which reminds me to remind people, that most of the [list]-abs abstractions fail horribly if one of the reserved selectors is part of a list, because many of the abstractions internally serialize the list and later repack it. For example a list "list 1 2 bang 3", when serialized will give:
1 2 bang 3
but I don't know of a smart way to repack this to get "list 1 2 bang 3" again. Same for "list list" lists.
Ciao
Frank Barknecht _ ______footils.org__
Hello Frank,
Here a simple patch to serialize a list and pack it again (i just get
'symbol bang', i think it's easy to get only 'bang' ?).
Hope is what you are looking for.
++
Jack
Le 8 juil. 08 à 21:07, Frank Barknecht a écrit :
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
However I can't think of a solution for dealing with "list list a
b c" going through [route list] to become "list a b c" then through [list prepend list] to become "list list a b c" and not "list list list
a b c", in which case it will end up being trimmed to "list a b c" instead of "list list a b c". But I know I can't just tell you to use [route2] instead of [route] for this case.Which reminds me to remind people, that most of the [list]-abs abstractions fail horribly if one of the reserved selectors is part of a list, because many of the abstractions internally serialize the list and later repack it. For example a list "list 1 2 bang 3", when serialized will give:
1 2 bang 3
but I don't know of a smart way to repack this to get "list 1 2 bang 3" again. Same for "list list" lists.
Ciao
Frank Barknecht _
______footils.org__
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Hallo, Jack hat gesagt: // Jack wrote:
Here a simple patch to serialize a list and pack it again (i just get
'symbol bang', i think it's easy to get only 'bang' ?).
Oh, yes. Well, I just checked and e.g. [list-map] also works. I wonder what I did to make it fail. I promise, I did run into problems once in the past ...
Ciao
Frank Barknecht _ ______footils.org__
On Sun, 6 Jul 2008, Martin Peach wrote:
I'm getting the feeling that list is becoming deprecated in favour of meta-messages, since the 'list' selector is redundant. Is that right?
I've always tended to see a so-called "meta-message" as being a selector symbol followed by a list, rather than as a list in which the first element has been taken out to be the selector. After all, in implementation, this is respectively selector,argc,argv versus argv[0].a_w.w_symbol,argc-1,argv+1 and the first one is more direct. The latter is what [list trim] does.
What Pd's message parser does tends to add to the confusion, as messages starting with a non-symbol are accepted and taken with an implicit "list" selector, and as some objects (but not all) take anything() such that any "meta-message" is "untrimmed" into a list... this is mostly limited to [pack] and [list] afair.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
-
Andre Schmidt -
Frank Barknecht -
IOhannes m zmoelnig -
Jack -
Martin Peach -
Mathieu Bouchard -
patrick -
zmoelnig＠iem.at