hello folks, apparently [routeOSC] behaves differently between 42.5 and 43.1 releases (I'm aware mrpeach has been updated in between).
I have sliders sending out messages as [list /bla/1/blabli 0.437(
with Pd-extended 0.42.5 and the related "older" mrpeach lib, I used to route these messages with [routeOSC /bla]
I gave it a try with the 0.43.1 and the "new" mrpeach lib, but now I need to do [route list] | [routeOSC /bla]
If the [route list] is omitted, [routeOSC] won't output anything, and it does not complain.
it's really a minor fix for the patch, but I'm a bit confused:
- was I doing something wrong before?
- is this a new feature?
- should [routeOSC] tell me something if it can't parse the message?
thanks in advance,
-- Marco Donnarumma New Media + Sonic Arts Practitioner, Performer, Teacher, Director. ACE, Sound Design MSc by Research (ongoing) The University of Edinburgh, UK
Portfolio: http://marcodonnarumma.com
Research: http://res.marcodonnarumma.com | http://www.thesaddj.com |
http://www.flxer.net
Director: http://www.liveperformersmeeting.net
On 2012-03-12 14:35, Marco Donnarumma wrote:
hello folks, apparently [routeOSC] behaves differently between 42.5 and 43.1 releases (I'm aware mrpeach has been updated in between).
I have sliders sending out messages as [list /bla/1/blabli 0.437(
with Pd-extended 0.42.5 and the related "older" mrpeach lib, I used to route these messages with [routeOSC /bla]
I gave it a try with the 0.43.1 and the "new" mrpeach lib, but now I need to do [route list] | [routeOSC /bla]
If the [route list] is omitted, [routeOSC] won't output anything, and it does not complain.
it's really a minor fix for the patch, but I'm a bit confused:
- was I doing something wrong before?
I think so. [routeOSC] expects messages whose selector is an OSC path. If it worked before with list selector it was by accident, because routeOSC used to have a list method but now there is an anything method.
- is this a new feature?
I suppose it must be new that it ignores lists, but it's not really a feature.
- should [routeOSC] tell me something if it can't parse the message?
It tells you if the path is not a valid OSC path (no slash) only if you send it a [verbosity 1( message.
Martin
On 03/12/2012 03:50 PM, Martin Peach wrote:
On 2012-03-12 14:35, Marco Donnarumma wrote:
hello folks, apparently [routeOSC] behaves differently between 42.5 and 43.1 releases (I'm aware mrpeach has been updated in between).
I have sliders sending out messages as [list /bla/1/blabli 0.437(
with Pd-extended 0.42.5 and the related "older" mrpeach lib, I used to route these messages with [routeOSC /bla]
I gave it a try with the 0.43.1 and the "new" mrpeach lib, but now I need to do [route list] | [routeOSC /bla]
If the [route list] is omitted, [routeOSC] won't output anything, and it does not complain.
it's really a minor fix for the patch, but I'm a bit confused:
- was I doing something wrong before?
I think so. [routeOSC] expects messages whose selector is an OSC path. If it worked before with list selector it was by accident, because routeOSC used to have a list method but now there is an anything method.
- is this a new feature?
I suppose it must be new that it ignores lists, but it's not really a feature.
- should [routeOSC] tell me something if it can't parse the message?
It tells you if the path is not a valid OSC path (no slash) only if you send it a [verbosity 1( message.
IMHO, [routeOSC] should accept these two as the same thing:
[/bla/1/blabli 0.437( [list /bla/1/blabli 0.437(
It'll make life easier for a lot of people, and I can't see any disadvantage in that setup.
hc
On 03/12/2012 02:54 PM, Hans-Christoph Steiner wrote:
IMHO, [routeOSC] should accept these two as the same thing:
[/bla/1/blabli 0.437( [list /bla/1/blabli 0.437(
It'll make life easier for a lot of people, and I can't see any disadvantage in that setup.
well, in pd in general, [list foo bar( is not exactly the same as [foo bar(, unless I'm missing something (if so, please, feel free to enlighten me ;)).
why not change also the behavior of [route] (and tons of other objects) to make life easier for a lot of people ??
I don't really see the point.. [routeOSC] expects an OSC path, [list /foo/bar 666( is obviously not one.
my 20 COP anyway.
y
-- yvan.volochine@gmail.com http://yvanvolochine.com
On 03/12/2012 06:06 PM, yvan volochine wrote:
On 03/12/2012 02:54 PM, Hans-Christoph Steiner wrote:
IMHO, [routeOSC] should accept these two as the same thing:
[/bla/1/blabli 0.437( [list /bla/1/blabli 0.437(
It'll make life easier for a lot of people, and I can't see any disadvantage in that setup.
well, in pd in general, [list foo bar( is not exactly the same as [foo bar(, unless I'm missing something (if so, please, feel free to enlighten me ;)).
why not change also the behavior of [route] (and tons of other objects) to make life easier for a lot of people ??
I don't really see the point.. [routeOSC] expects an OSC path, [list /foo/bar 666( is obviously not one.
my 20 COP anyway.
I personally think it would be great to get rid of the separation between lists and non-list messages (i.e. lists of atoms that start with a symbol other than "list"). But that's a big project that will break backwards compatibility.
Changing specific objects to ignore the difference can be done now without compatibility concerns.
.hc
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: yvan volochine yvan.pd@gmail.com Cc: pd-list pd-list@iem.at Sent: Monday, March 12, 2012 6:36 PM Subject: Re: [PD] mrpeach routeOSC behaves differently then its previous release?
On 03/12/2012 06:06 PM, yvan volochine wrote:
On 03/12/2012 02:54 PM, Hans-Christoph Steiner wrote:
IMHO, [routeOSC] should accept these two as the same thing:
[/bla/1/blabli 0.437( [list /bla/1/blabli 0.437(
It'll make life easier for a lot of people, and I can't see any disadvantage in that setup.
well, in pd in general, [list foo bar( is not exactly the same as [foo bar(, unless I'm missing something (if so, please, feel free to enlighten me ;)).
why not change also the behavior of [route] (and tons of other objects) to make life easier for a lot of people ??
I don't really see the point.. [routeOSC] expects an OSC path, [list /foo/bar 666( is obviously not one.
my 20 COP anyway.
I personally think it would be great to get rid of the separation between lists and non-list messages (i.e. lists of atoms that start with a symbol other than "list"). But that's a big project that will break backwards compatibility.
In this world of no lists would bang be the equivalent of what is currently an empty list?
Changing specific objects to ignore the difference can be done now without compatibility concerns.
.hc
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 03/12/2012 07:04 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: yvan volochine yvan.pd@gmail.com Cc: pd-list pd-list@iem.at Sent: Monday, March 12, 2012 6:36 PM Subject: Re: [PD] mrpeach routeOSC behaves differently then its previous release?
On 03/12/2012 06:06 PM, yvan volochine wrote:
On 03/12/2012 02:54 PM, Hans-Christoph Steiner wrote:
IMHO, [routeOSC] should accept these two as the same thing:
[/bla/1/blabli 0.437( [list /bla/1/blabli 0.437(
It'll make life easier for a lot of people, and I can't see any disadvantage in that setup.
well, in pd in general, [list foo bar( is not exactly the same as [foo bar(, unless I'm missing something (if so, please, feel free to enlighten me ;)).
why not change also the behavior of [route] (and tons of other objects) to make life easier for a lot of people ??
I don't really see the point.. [routeOSC] expects an OSC path, [list /foo/bar 666( is obviously not one.
my 20 COP anyway.
I personally think it would be great to get rid of the separation between lists and non-list messages (i.e. lists of atoms that start with a symbol other than "list"). But that's a big project that will break backwards compatibility.
In this world of no lists would bang be the equivalent of what is currently an empty list?
Donno. That particular rule has always felt arbitrary to me. I don't think I've ever run into a case where there was an empty list being used as a bang.
.hc
Le 2012-03-12 à 22:30:00, Hans-Christoph Steiner a écrit :
Donno. That particular rule has always felt arbitrary to me. I don't think I've ever run into a case where there was an empty list being used as a bang.
Currently, [t a] turns every bang into an empty list, but whenever you try to print an empty list, [print] says «bang».
If you wish to see the true selector of every message, to see where pd is currently producing empty-lists in unsuspected areas, use [gf/selector].
http://gridflow.ca/help/gf/selector-help.html
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: yvan volochine yvan.pd@gmail.com; pd-list pd-list@iem.at Sent: Monday, March 12, 2012 10:30 PM Subject: Re: [PD] mrpeach routeOSC behaves differently then its previous release?
On 03/12/2012 07:04 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: yvan volochine yvan.pd@gmail.com Cc: pd-list pd-list@iem.at Sent: Monday, March 12, 2012 6:36 PM Subject: Re: [PD] mrpeach routeOSC behaves differently then its
previous release?
On 03/12/2012 06:06 PM, yvan volochine wrote:
On 03/12/2012 02:54 PM, Hans-Christoph Steiner wrote:
IMHO, [routeOSC] should accept these two as the same thing:
[/bla/1/blabli 0.437( [list /bla/1/blabli 0.437(
It'll make life easier for a lot of people, and I
can't see any
disadvantage in that setup.
well, in pd in general, [list foo bar( is not exactly the same as
[foo
bar(, unless I'm missing something (if so, please, feel free
to
enlighten me ;)).
why not change also the behavior of [route] (and tons of other objects) to make life easier for a lot of people ??
I don't really see the point.. [routeOSC] expects an OSC path,
[list
/foo/bar 666( is obviously not one.
my 20 COP anyway.
I personally think it would be great to get rid of the separation between lists and non-list messages (i.e. lists of atoms that start
with
a symbol other than "list"). But that's a big project
that will
break backwards compatibility.
In this world of no lists would bang be the equivalent of what is currently
an empty list?
Donno. That particular rule has always felt arbitrary to me. I don't think I've ever run into a case where there was an empty list being used as a bang.
It happens any time you bang [list], but it doesn't matter because pretty much everything treats the output as a bang.
In a world without the special selector "list", presumably you'd still have an object that counts the number of atoms in a message. Let's call it [length]. Does [length] count "bang" as "0"? And what about custom selectors like "foo"? If we're counting message arguments it seems we'd have to differ from the way [list length] works and count those as "0", too, but then every single-selector message registers as an empty list. Not that you couldn't treat bang specially elsewhere-- but still, it seems weird.
-Jonathan
Le 2012-03-12 à 18:36:00, Hans-Christoph Steiner a écrit :
I personally think it would be great to get rid of the separation between lists and non-list messages (i.e. lists of atoms that start with a symbol other than "list"). But that's a big project that will break backwards compatibility.
This sounds like something that will create more problems than it will solve.
I mean, it's possible to be both part of the problem and of the solution. It happens when the solution is the problem.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On 2012-03-12 22:49, Mathieu Bouchard wrote:
Le 2012-03-12 à 18:36:00, Hans-Christoph Steiner a écrit :
I personally think it would be great to get rid of the separation between lists and non-list messages (i.e. lists of atoms that start with a symbol other than "list"). But that's a big project that will break backwards compatibility.
This sounds like something that will create more problems than it will solve.
I mean, it's possible to be both part of the problem and of the solution. It happens when the solution is the problem.
Yes it's easier to just use [list trim].
Martin
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: Hans-Christoph Steiner hans@at.or.at Cc: pd-list pd-list@iem.at Sent: Monday, March 12, 2012 10:49 PM Subject: Re: [PD] mrpeach routeOSC behaves differently then its previous release?
Le 2012-03-12 à 18:36:00, Hans-Christoph Steiner a écrit :
I personally think it would be great to get rid of the separation between
lists and non-list messages (i.e. lists of atoms that start with a symbol other than "list"). But that's a big project that will break backwards compatibility.
This sounds like something that will create more problems than it will solve.
I think the current implementation (and documentation) tries to skirt the issue and ends up making it worse. The [route] object does...what? It looks like the object was designed so that the new user can quickly conclude that it takes the first "thingy" in the message you send it, eats the thingy and shoots out any remaining thingies (if no more thingies, then burp out a bang). Super simple if all the thingies in the message are numbers. A collection of exceptions if you want to do anything else. (It has three modes... I mean, two modes, and two selectors that never get stripped, I mean...hm... let me check the docs again...etc.)
Similar with [list length]. Just remember that all incoming messages are converted to lists. So an incoming "symbol foo" message will have... how many items? Uh-oh, we didn't define "convert".
[symbol foo( | [list length] | "1"
Selectors don't count...
[foo( | [list length] | "1"
I meant built-in selectors don't count...
[tranverse this, bang( | [pointer] | [route pointer] | | [s a] [s b]
[r a] | [list length] | "?"
[r b] | [list length] | "?"
[namecanvas this]
Let's start over. The [route] object takes the first thingy and...
-Jonathan
I mean, it's possible to be both part of the problem and of the solution. It happens when the solution is the problem.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi,
On Mon, Mar 12, 2012 at 06:36:25PM -0400, Hans-Christoph Steiner wrote:
On 03/12/2012 06:06 PM, yvan volochine wrote:
On 03/12/2012 02:54 PM, Hans-Christoph Steiner wrote:
IMHO, [routeOSC] should accept these two as the same thing:
[/bla/1/blabli 0.437( [list /bla/1/blabli 0.437(
It'll make life easier for a lot of people, and I can't see any disadvantage in that setup.
well, in pd in general, [list foo bar( is not exactly the same as [foo bar(, unless I'm missing something (if so, please, feel free to enlighten me ;)).
why not change also the behavior of [route] (and tons of other objects) to make life easier for a lot of people ??
I don't really see the point.. [routeOSC] expects an OSC path, [list /foo/bar 666( is obviously not one.
my 20 COP anyway.
I personally think it would be great to get rid of the separation between lists and non-list messages (i.e. lists of atoms that start with a symbol other than "list"). But that's a big project that will break backwards compatibility.
Changing specific objects to ignore the difference can be done now without compatibility concerns.
I don't believe that getting rid of the separation in general is a good goal.
But I do agree, that ignoring the difference in some objectclasses can be a useful time saver without introducing nasty side-effects.
Some examples:
In the rj library most objects use the last inlet solely for control messages, i.e. special meta-messages to set the object's state. This inlet starts with a [list trim] as its first operation effectively making list-messages with the parameter name as first element the same as meta-messages where the parameter name is the selector. "list frequency 440" is treated the same as "frequency 440". The only disadvantage here is, that the object's inlet can not react in a special way to real "list"-messages. So what? I designed the objects so I could make sure none of them wants to do that, of if they want to, they can be designed to use a different, often more memorizable selector like "notelist 60 62 64". (This is different from the general case in Pd where many objects actually *do* special things with list-messages, most notably all message boxes).
The whole [list] object family except [list trim] (and the [list]-abs collection as well) internally convert everything the other way around, into "list"-messages and they output "list"-messages. This makes manipulating lists much less error-prone.
[routeOSC] obviously has worked fine in the past with the same approach, so I don't think, it's of much use to force users to insert their own [list trim] suddenly. It's not like in [route] where [route list] is indeed needed sometimes (or was needed before [list trim] appeared). One could just as well define [routeOSC] as an objectclass that routes pure OSC-messages as well as OSC-messages that are embedded in a "list"-message. Control messages like "verbosity 1" could still be used and the check, if a path is a proper OSC-path would just be applied to the first element of a list-message if necessary.
So I'm not convinced. :)
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
On Tue, 2012-03-13 at 09:11 +0100, Frank Barknecht wrote:
Hi,
On Mon, Mar 12, 2012 at 06:36:25PM -0400, Hans-Christoph Steiner wrote:
On 03/12/2012 06:06 PM, yvan volochine wrote:
On 03/12/2012 02:54 PM, Hans-Christoph Steiner wrote:
IMHO, [routeOSC] should accept these two as the same thing:
[/bla/1/blabli 0.437( [list /bla/1/blabli 0.437(
It'll make life easier for a lot of people, and I can't see any disadvantage in that setup.
well, in pd in general, [list foo bar( is not exactly the same as [foo bar(, unless I'm missing something (if so, please, feel free to enlighten me ;)).
why not change also the behavior of [route] (and tons of other objects) to make life easier for a lot of people ??
I don't really see the point.. [routeOSC] expects an OSC path, [list /foo/bar 666( is obviously not one.
my 20 COP anyway.
I personally think it would be great to get rid of the separation between lists and non-list messages (i.e. lists of atoms that start with a symbol other than "list"). But that's a big project that will break backwards compatibility.
Changing specific objects to ignore the difference can be done now without compatibility concerns.
I don't believe that getting rid of the separation in general is a good goal.
But I do agree, that ignoring the difference in some objectclasses can be a useful time saver without introducing nasty side-effects.
Some examples:
In the rj library most objects use the last inlet solely for control messages, i.e. special meta-messages to set the object's state. This inlet starts with a [list trim] as its first operation effectively making list-messages with the parameter name as first element the same as meta-messages where the parameter name is the selector. "list frequency 440" is treated the same as "frequency 440". The only disadvantage here is, that the object's inlet can not react in a special way to real "list"-messages. So what? I designed the objects so I could make sure none of them wants to do that, of if they want to, they can be designed to use a different, often more memorizable selector like "notelist 60 62 64". (This is different from the general case in Pd where many objects actually *do* special things with list-messages, most notably all message boxes).
The whole [list] object family except [list trim] (and the [list]-abs collection as well) internally convert everything the other way around, into "list"-messages and they output "list"-messages. This makes manipulating lists much less error-prone.
[routeOSC] obviously has worked fine in the past with the same approach, so I don't think, it's of much use to force users to insert their own [list trim] suddenly. It's not like in [route] where [route list] is indeed needed sometimes (or was needed before [list trim] appeared). One could just as well define [routeOSC] as an objectclass that routes pure OSC-messages as well as OSC-messages that are embedded in a "list"-message. Control messages like "verbosity 1" could still be used and the check, if a path is a proper OSC-path would just be applied to the first element of a list-message if necessary.
So I'm not convinced. :)
You're not convinced of what now? The proposal is actually what you describe above. Currently it _does_ make a separation between 'list' selector and 'OSC path' selector (it disregards messages with 'list' selector). Did you mean to say: 'Yeah, I'm convinced of the proposal to change [routeOSC]s behaviour to make it also messages with the 'list' selector'?
Hans proposed to generally get rid of the separation between 'list' selector and 'any' selector messages in all parts of Pd. Personally, I'm undecided whether this is a good idea, but if it would be done, I'd consider it a bad approach to do it in every (external and internal) class separately. Rather should Pd's message system be changed.
In this particular case, [routeOSC]'s behaviour is consistent with its brothers and sisters, since [unpackOSC] also outputs only messages with an OSC path as selector. Also for the documentation it's much more concise to state 'the selector of the incoming message is considered the OSC path' than 'the selector of the incoming messages is considered the OSC path, unless the selector is "list" where the first element of the message is considered the OSC path'.
Roman
Hi,
On Tue, Mar 13, 2012 at 10:02:01AM +0100, Roman Haefeli wrote:
You're not convinced of what now?
Sorry for the unclarity: I'm not convinced of the recent change in [routeOSC], I think, it would work fine accepting list-messages as well as proper OSC-meta-messages.
The proposal is actually what you describe above. Currently it _does_ make a separation between 'list' selector and 'OSC path' selector (it disregards messages with 'list' selector). Did you mean to say: 'Yeah, I'm convinced of the proposal to change [routeOSC]s behaviour to make it also messages with the 'list' selector'?
Yes.
Hans proposed to generally get rid of the separation between 'list' selector and 'any' selector messages in all parts of Pd.
That's what I'm not convinced of: When designing a new language, one may consider a different approach. But I don't see a need to change this system in Pd now, it works fine in general.
undecided whether this is a good idea, but if it would be done, I'd consider it a bad approach to do it in every (external and internal) class separately. Rather should Pd's message system be changed.
Well, the whole list-/any-/float-/...-messages *are* Pd's message system. It's a very flexible system, that allows differentiating between all kinds of messages. In the end it's up to the author of a patch/external/abstraction to decide which distinctions should be used. Not everything that is allowed has to be done all the time.
In the [list]-objects (minus trim) the distinction between "list"-messages and "meta"-messages is not necessary, because lists are all these objects deal with. So it makes sense that these objects treat meta-messages like list-messages.
That's very different from for example [pipe s s 1000] which will delay a [list x y( or a [symbol S( for one second, but can still be flushed with a "flush" meta-message.
In this particular case, [routeOSC]'s behaviour is consistent with its brothers and sisters, since [unpackOSC] also outputs only messages with an OSC path as selector.
So what? [routeOSC] will continue to work fine with what it gets from [unpackOSC], but additionally users constructing their own OSC-messages with [list]-operations could skip the final [list trim].
Also for the documentation it's much more concise to state 'the selector of the incoming message is considered the OSC path' than 'the selector of the incoming messages is considered the OSC path, unless the selector is "list" where the first element of the message is considered the OSC path'.
"The first element in the incoming message is considered the OSC path." :) No mentioning of selectors, list-message, meta-messages needed to document it here, unless one is a language lawyer.
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
Hi Frank
Though I lack to see the necessity to change [routeOSC]'s current behaviour, I agree that it most likely wouldn't cause any harm.
Roman
On Tue, 2012-03-13 at 11:17 +0100, Frank Barknecht wrote:
Hi,
On Tue, Mar 13, 2012 at 10:02:01AM +0100, Roman Haefeli wrote:
You're not convinced of what now?
Sorry for the unclarity: I'm not convinced of the recent change in [routeOSC], I think, it would work fine accepting list-messages as well as proper OSC-meta-messages.
The proposal is actually what you describe above. Currently it _does_ make a separation between 'list' selector and 'OSC path' selector (it disregards messages with 'list' selector). Did you mean to say: 'Yeah, I'm convinced of the proposal to change [routeOSC]s behaviour to make it also messages with the 'list' selector'?
Yes.
Hans proposed to generally get rid of the separation between 'list' selector and 'any' selector messages in all parts of Pd.
That's what I'm not convinced of: When designing a new language, one may consider a different approach. But I don't see a need to change this system in Pd now, it works fine in general.
undecided whether this is a good idea, but if it would be done, I'd consider it a bad approach to do it in every (external and internal) class separately. Rather should Pd's message system be changed.
Well, the whole list-/any-/float-/...-messages *are* Pd's message system. It's a very flexible system, that allows differentiating between all kinds of messages. In the end it's up to the author of a patch/external/abstraction to decide which distinctions should be used. Not everything that is allowed has to be done all the time.
In the [list]-objects (minus trim) the distinction between "list"-messages and "meta"-messages is not necessary, because lists are all these objects deal with. So it makes sense that these objects treat meta-messages like list-messages.
That's very different from for example [pipe s s 1000] which will delay a [list x y( or a [symbol S( for one second, but can still be flushed with a "flush" meta-message.
In this particular case, [routeOSC]'s behaviour is consistent with its brothers and sisters, since [unpackOSC] also outputs only messages with an OSC path as selector.
So what? [routeOSC] will continue to work fine with what it gets from [unpackOSC], but additionally users constructing their own OSC-messages with [list]-operations could skip the final [list trim].
Also for the documentation it's much more concise to state 'the selector of the incoming message is considered the OSC path' than 'the selector of the incoming messages is considered the OSC path, unless the selector is "list" where the first element of the message is considered the OSC path'.
"The first element in the incoming message is considered the OSC path." :) No mentioning of selectors, list-message, meta-messages needed to document it here, unless one is a language lawyer.
Ciao
Hi Roman,
On Tue, Mar 13, 2012 at 12:19:59PM +0100, Roman Haefeli wrote:
Though I lack to see the necessity to change [routeOSC]'s current behaviour, I agree that it most likely wouldn't cause any harm.
As I understand it, this topic only came up because apparently the behaviour has been changed in the newest release to not allow list-messages containing OSC-messages as first item anymore, breaking some old patches without any urgent necessity.
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
On 03/13/2012 07:12 AM, Frank Barknecht wrote:
Though I lack to see the necessity to change [routeOSC]'s current behaviour, I agree that it most likely wouldn't cause any harm.
As I understand it, this topic only came up because apparently the behaviour has been changed in the newest release to not allow list-messages containing OSC-messages as first item anymore, breaking some old patches without any urgent necessity.
IMHO it's really a user mistake to send [list /what/ever 123( to [routeOSC].
this recent change looks more like a (accidental!) bugfix than a regression to me (whether it breaks old code or not.. breaking faulty code should not count, oder? =).
cheers, y
-- yvan.volochine@gmail.com http://yvanvolochine.com
Well it was simple enough to implement. The newest [routeOSC] in svn should handle lists and messages the same, even though you shouldn't be using lists ;) Also any non-OSC messages will be sent through the rightmost outlet.
Martin
On 2012-03-13 12:14, yvan volochine wrote:
On 03/13/2012 07:12 AM, Frank Barknecht wrote:
Though I lack to see the necessity to change [routeOSC]'s current behaviour, I agree that it most likely wouldn't cause any harm.
As I understand it, this topic only came up because apparently the behaviour has been changed in the newest release to not allow list-messages containing OSC-messages as first item anymore, breaking some old patches without any urgent necessity.
IMHO it's really a user mistake to send [list /what/ever 123( to [routeOSC].
this recent change looks more like a (accidental!) bugfix than a regression to me (whether it breaks old code or not.. breaking faulty code should not count, oder? =).
cheers, y
-- yvan.volochine@gmail.com http://yvanvolochine.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Great, thanks for the clear and concise explanation. I thought I must have been wrong :)
M
- was I doing something wrong before?
I think so. [routeOSC] expects messages whose selector is an OSC path. If it worked before with list selector it was by accident, because routeOSC used to have a list method but now there is an anything method.
- is this a new feature?
I suppose it must be new that it ignores lists, but it's not really a feature.
- should [routeOSC] tell me something if it can't parse the message?
It tells you if the path is not a valid OSC path (no slash) only if you send it a [verbosity 1( message.
Martin
-
Frank Barknecht -
Hans-Christoph Steiner -
Jonathan Wilkes -
Marco Donnarumma -
Martin Peach -
Mathieu Bouchard -
Roman Haefeli -
yvan volochine