[PD] mrpeach routeOSC behaves differently then its previous release?

[Frank Barknecht]

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__