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

[Roman Haefeli]

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