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

[Roman Haefeli]

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