[OSC_dev] SYNoscopy (or something like it)

[Gaspard Bucher]

PS: in my last message, it's

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

sorry for the typo.

On Wed, Jan 28, 2009 at 8:46 AM, Gaspard Bucher <gaspard at teti.ch> wrote:
> 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
>>
>