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__ _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
