14 May
2005
14 May
'05
12:23 a.m.
On Fri, 2005-13-05 at 20:22 +0200, Fons Adriaensen wrote:
On Sat, May 14, 2005 at 03:31:08AM +1000, Dave
Robillard wrote:
Well, for the clients it's there because there's no particular reason a
client can't be talking to numerous apps at once, so having a prefix for
each app's incoming messages is necessary.
For the engine, I didn't really have any particular reason. I figured
maybe it would prove useful down the road to separate things. Better
safe than sorry..
-DR-
If by <channel> you mean MIDI style channel
number - dear god no. :)
Note numbers are debatable (but frequency is better in most cases), but
channel numbers definitely don't belong in OSC. Maybe an open-ended
string identifier (which could represent a channel, a patch, a certain
synth... whatever)
There's no need to have confusing overloading with <voice> being zero or
non-zero - just make different commands. Have one note on command to
allocate the most appropriate voice (MIDI style), and one to start a
note on a specific voice. In Om I've made seperate commands for global
or voice-specific controls, and it works great.
Ability to control individual voices specifically is one of the things I
love about OSC. Death to MIDI. :)
Agreed 100% - I was not proposing an OSC format, just I a hypothetical
variaton of MIDI that would have allowed client side voice control.
I see you consistently start all your OSC paths with /om, while SL doesn't
do this. Any pros/cons ? It seems essential only when multicasting.