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__