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