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

[Frank Barknecht]

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__