In deference to Ron's hold-off request, my last replies on MIDI for
now. I think it's converging. Replies to Steve, Koen, & Tim all
included below.
-- Chris G
I. Replies to Steve
Steve said:
I think we have the same goals (broad and extensive MIDI support) but see different ways of achieving that.
Chris Grigg wrote: > But is this really viable across the board? An in-graph note index> 1? This is a source of error.of 40.5 converting to a MIDI wire note of 40 or 41? An in-graph sustain pedal value of 0.5 converting to a MIDI wire CC value of 0 or
... Given some extra information it would be possible for a host to convert outging float accurate pitch information to note on + pitchbend like guitar midi controllers do.
The trick is to support MIDI unambigiously and losslessly without it impinging on the design or complexity of plugins (that dont need to care about low-level MIDI/OSC things). I think thats possible.
> C) If GMPI forces conversion of integer control surface values intoreal values to occur at the GMPI graph bounds (by the host), then it eliminates the possibility of allowing more than one plug destination to respond to the integer messages in different ways. Compared with existing plug formats, this is a loss of functionality.
I dont think thats right:
----------------------------- | GMPI Graph | | | MIDI | control .----------. | ------+----------| Plugin A | | |\ '----------' | | \ .----------. | | '------| Plugin B | | | '----------' | -----------------------------
The MIDI CC can be mapped in different ways at the boundary to meet the needs of A and B.
> If I understand correctly, all > y'all propose GMPI graphs contain & route only 'natural value'parameters, i.e. frequency in hz, maybe filter Q as a coefficient,
pitch in octaves/semitones, rather than freq in Hz, but yes.
> level in dB, etc. Whereas MIDI speaks in terms of integer controlvalues with in many cases no predefined mapping from control value to represented real value. So my question is: what is your proposal for where and how such conversions on incoming events from MIDI controllers (incl. control surfaces) are performed?
They are performaed individually for each control input that takes data from external MIDI sources.
These are all limitations that we have to respect when exporting control data from the GMPI graph to serial MIDI land, but we shouldn't feel bound by them internally and we shouldn't make people (who want to support MIDI) have two seperate event handlers inside thier plugin.
> >obviously if I use high resolution data values inside of the GMPI graph,>when it get exported to serial MIDI that extra res will be lost, but at> >least I had the oportunity to use it in the first place. >But if the external device unexpectedly responds with a different behavior than plugs in the graph do, then the extra res can also be seen as (and many users would experience GMPI as) a generator of wrongness.
I doubt it, people are used to MIDI CC's being a bit steppy.
My concern is that if you require explicit support for MIDI, you also require explicit support for OSC, or whatever future control protocol comes along.
OSC support is much easier as it comes from the natural valued, named parameter world and plugin can generate/receive it natively...
Porting a plugin with an explcit MIDI parser to a system when MIDI is preparsed is easy - I've done it - you just remove the byte parser.
> Because it's completely new and nothing that currently exists will beable to work within it in a reasonable timeframe? I think it's not enough to get a working system, we need a working system with a reasonably efficient entry path for existing plugs in other formats. (This is a requirement we already agreed on, isn't it?)
MIDI parsing is not new (every VSTi does it internally and there are nmumerous systems that do it in the engine).
We also probably should handle MIDI at the byte level so as not to rule out systems like DMIDI http://standards.ieee.org/announcements/p1639app.html
> Couldn't agree more, wish we had a time machine to go back and fixMIDI in the cradle. But it's a reality and we have to deal with it. One consolation: when you look closely at MIDI in GMPI, at least there are some things we get a chance to improve.
I think there was very little worng with MIDI (possibly it should have been bidirectional), but it was limited to some extent by the technology of the time.
> >A needs good, lossless representation of the MIDI data, it doesnt need any>particular scaling hints or whatever, as MIDI doesnt have them.
This is only true if plugs are free to receive notes as indexes and not frequencies. Are you saying you're OK with notes as indexes?
No, but GMPI can seperate pitch from index internally and only remap them externally. Again this would be lossy when you went to external, serial MIDI systems, but DMIDI and MIDI-over-OSC will handle it well.
> If you let a plug have a MIDI In control port then all the individualcontroller routing for that plug is handled automatically within the plug, with no host load and no host GUI needs to be written by the host author nor played with by the user. Lots and lots of popular plugs already work this way.
Yes, but IMHO hosts that also allow you to bind controls at the host level are very convienient: less mucking about with virtual midi connections and a consistent binding UI.
> Maybe we can find a way for you to get what you want without alsoputting walls up for the authors of such existing plugs.
I think so. I am 100% against blocking any existing functionality, but I'm also 100% against requireing people to have to add expitict support in every plugin for what is a very widly used, and easy to use protocol.
- Steve, "make the 95% common case easy and the 5% hard case possible"
Tim Hockin wrote: > Chris Grigg said: > > Limiting the use of MIDI messages in GMPI to just the > > standardized meanings would kind of suck IMHO. MIDI was never meant> to be limited in that way.> Oh, no, no such limit needs to exist. That would be bad bad bad.
Disagree, MIDI is complex and we probably dont want to ecapsulate every variation on it (eg. all the forms of SYSEX), so just let people blash out known-typed blobs that will be sent out at the edge of the graph as midi bytes and used as blobs internally.
> > think we also have to take seriously the fact that MIDI parser> writing has already been done at least hundreds of times in existing
And is a waste of memory and CPU, and is a waste of programmer time for new plugins.
And a big source of bugs.
Chris Grigg said: >...what is your proposal for > where and how such conversions on incoming events from MIDIcontrollers (incl. control surfaces) are performed?
I would think the best place would be in the receiver (probably the plugin) that knows how to interpret/convert the values, but possibly with the help of the host in the form of standard MIDI messages to real value conversion routines.
Well, at least one of the bigger players that apparently saw the usefulness of OSC is Native Instruments: they are using OSC in Reaktor.
It's not that we don't want support for MIDI, but just not as the base within the GMPI graph, so that the limits are not baked in from the start.
> If sysEx communication between external devices and plugs > is going to be supported (needed for some control surfaces), thenyou'd need actual MIDI byte sequences to be able to move around inside GMPI graphs.
I think one of the GMPI parameter types was some kind of opaque blob of bytes, so if you need to move sysEx things in the graph, that will not be impossible.
Personally, I would think converting from internal "conceptual messages" into "MIDI bytes" is only done in the wrapper for the plugin format it's being used in. So, if the code is written that way, the MIDI handling is not done directly and can be exchanged for something else, right?
Tim said: > ...I don't want to know what CC# each knob > in SynthX is. I don't want to figure out MIDI learn on each Synth Ibuy. I want to right-click->link-to-MIDI and then waggle a knob. On EVERYTHING. The same way. I want to be able to write plugins that can be controlled by MIDI without writing a MIDI parser and building it into each plugin.
I fully agree with this. This *is* probably as user-friendly as it can get.
SysEx, yeah. I meant just unnamed CC numbers should still work.
---------------------------------------------------------------------- Generalized Music Plugin Interface (GMPI) public discussion list Participation in this list is contingent upon your abiding by the following rules: Please stay on topic. You are responsible for your own words. Please respect your fellow subscribers. Please do not redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe