[OSC_dev] SYNoscopy (or something like it)

[Gaspard Bucher]

Sorry for my first post on "m", you obviously know your midi.

For what you need, I think "oscit" can be the first step. It handles :

1. getting applications to talk with user intervention
2. get "schema" for specific protocols supported

The "schema" definition for a Midi replacement is yet to be written.
If you would like to endorse such a task (which would be really
great!), then it has to overcome the actual limitations of Midi
without making it too complicated for hardware vendors to support it.
Some things on my midi-replacement wish list:

1. replace note values by floats with a logarithmique notation: 60.50
(Middle 'C' + 50 cents = quarter tone). This notation is backward
compatible and seems much better for musicians then raw frequencies.
It also means that musical structures can be easily transposed (by
adding a value).
2. possibility to use named channels/ctrls (should keep numbers for
low cost hardware without big display).

If you want to join the discussion on "oscit", you are welcome: it's
still a draft so lots of things can be changed if it's for the better
(faster, better design, easier for end user).

Gaspard

On Wed, Jan 28, 2009 at 3:58 AM, Jeff Glatt <jgglatt at roadrunner.com> wrote:
>>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.
> _______________________________________________
> OSC_dev mailing list
> OSC_dev at create.ucsb.edu
> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
>