[gmpi] Re: 3.15 MIDI
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 16 Jun 2004 01:08:06 -0700
On Wed, Jun 16, 2004 at 08:54:34AM +0100, Steve Harris wrote:
> On Tue, Jun 15, 2004 at 11:30:55 -0700, Tim Hockin wrote:
> > The proposal:
> > * Each parameter may (optionally) expose a CC-map. Exposing a CC-map
> > means that the host can take incoming MIDI and automatically convert it
> > to GMPI events.
> > * Each plugin may (optionally) expose a receive_midi() hook. Exposing
> > this hook means that the host can route you MIDI input directly. The
> > host will call the plugin's receive_midi() hook when there is new MIDI
> > data to process, in some thread that might not be the DSP thread. THIS
> > MEANS RE-ENTRANCY. The receive_midi() hook does whatever processing it
> > needs to do, and if the MIDI data has changed any parameters, it must
> > must pass GMPI events to the host for arbitration. This is very similar
> > to the "Parameter Preprocessor".
>
> Hmm... sorry, but I think is the worst of both worlds.
>
> It adds no extra funcitonality over the "MIDI conversion at edge of graph"
> and adds a hell of a lot of complexity.
It adds two bits of functionality:
1) do anything you like with raw MIDI, even interpret the bytestream as
audio samples.
2) make people not flip-out about "OMG! Where's the MIDI!?!"
> > This idiom is extensible later, if/when a new MIDI protocol comes along,
> > we can add a similar entry point. And maybe the same for raw OSC?
>
> And raw... I think we should pick one adequate API for sending data
*I* agree, but I'm trying to reach something that is doable. Your plugins
don't ever need to provide the receive_midi() hooks, they can just use the
CC-map. Your hosts don't need to handle sending raw MIDI to plugins, they
will only get GMPI events.
So the impact on you, the entrenched MIDI detractor, is almost nil.
> around inside GMPI and stick with it. Fundamentally, if that /has/ the be
> MIDI then it /has/ to be MIDI. I doubt I would bother writing any GMPI
> plugins in that case (there are MIDI based APIs in linux allready), but
If it *HAS* to be MIDI, then we suck. Hosts can already do better than
this with their own private plugin APIs. Loading a VST into these hosts
results in a plugin that is crippled as compared to a "native" plugin.
It *could* be something bigger and better than MIDI. Rework MIDI to be a
real superset, with all the stuff we need. If such a thing existed, it
would be really good. It doesn't. We're not here to define it, Martijn
is dead-on about that.
This model allows us to support MIDI2 should it ever come about.
What about OSC for everything. That got shot down - why?
> sometimes thats the price you pay for consensus.
Well, isn't this hybrid better than just plain MIDI? You at least get all
the benefits of not having MIDI, while corraling the raw-MIDI cruft into
ONLY those plugins/hosts which care to deal with it.
> I still haven't seen a cogent argument from the pro internal MIDI camp, as
> to why. They have pointed out (quite rightly) that MIDI is in heavy use
> for external communications elsewhere, but theres not been a single
> explanation as to why it should be the comms API inside GMPI.
Well, there is that. I'm not really holding my breath though.
Ron, Martijn, VB? Have any real reasoning?
----------------------------------------------------------------------
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
Other related posts:
