[OSC_dev] SYNoscopy (or something like it)

[Jeff Glatt]

>midi message format (type tag "m")

Right. I saw that. But this just imposes the limitations/hacks of MIDI
upon OSC. For example, if you want to change a patch, you need to
send one or two Bank Select controller messages and then a Program
Change. If you want greater than 7-bit resolution in controllers, then
you need to use both the MSB and LSB controllers. If you want to
adjust a setting that doesn't have a specific controller number defined
for it, then you need to use RPN (or NRPN) controllers along with
Data Slider (or Inc or Dec) controllers. If you want to adjust master
volume you need to send a system exclusive message (which isn't even
supported by the "m" datatype). And I'm not even sure if the "m"
datatype requires you to always supply a MIDI status byte. (The OSC
spec doesn't spell this out). For example, if it allows you to send a
message with running status, then you have to resolve that upon receipt.
You have to "unpack" the 14-bit pitch wheel value into 2 8-bit bytes
when you send it, and then repack the 2 bytes into one short upon
receipt. Ditto with other messages such as Song Position Pointer.
MIDI Time Code is a horrible hack. You still have the 16 channel
limitation, which is really, really inadequate today. And there's more
about MIDI that is antiquated, largely due to the fact that all
messages (except system exclusive) _must_ be limited to containing
at most 2 data bytes. There's not a hell of a lot you can do with
that.

Don't get me wrong. I'm a big MIDI guy (and my web site
at http://home.roadrunner.com/~jgglatt has proven a popular
destination for people who want to know all about MIDI).

But today, all these MIDI limitations/hacks need to go. It was a
mistake for OSC to endorse this "m" datatype, rather than a real
standardized set of OSC messages to offer the sort of control that
MIDI does. I mean, if you're going to call it Open Sound Control,
don't you think it ought to define/standardize something that actually
and specifically controls some aspect of sound???

But, "m" datatype is just an "optional" datatype not supported
in a number of the OSC dev libs (which is yet one more obstacle).

So, there needs to be additional standardization done with OSC.

>standard on where to send the midi information

I took a brief look at the oscit proposal. Although this could
be something that is useful, and should be standardized, it's not
really what I'm talking about. I'm talking about a standardized set
of OSC messages to specifically control a synth. (ie, a message to
turn a note on or off, move the pitch wheel, change the patch,
etc). Every OSC-supported synth would support these messages
so that a controller would not need to assume that every synth had
its own set of proprietary messages which must be "queried" (using
something like oscit) before the controller could do something
useful. (And that's assuming that a given controller _could_
intelligently map out any, potentially incompatible set of messages
to its own hardware features without lots and lots of user
intervention. ie, Like asking "What button/slider/wheel/whatever do
you want me to map this "/Something/Blort" parameter to?". Not
very useful when a musician has gotten used to attaching his MIDI
controller's MIDI Out to the MIDI In of his synth, pressing a few
keys and instantly hearing sound, pressing patch buttons and
hearing the sound change, moving the pitch wheel and hearing the
pitch go up and down, etc. All without the controller needing to
ask him what keys/buttons/sliders/etc spit out what OSC
messages).

But in regards to oscit specifically, I do have a question that I'll
ask in the other thread about it.