[gmpi] Re: 3.15 MIDI (What does it mean to be a plugin)

  • From: Mike Berry <mberry@xxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Mon, 21 Jun 2004 12:22:39 -0600



Tim Hockin wrote:

It comes down to who owns the authoritative value for a parameter. In order to implement automation and undo, the host must keep an accurate value for all parameters (unless every plugin implements these functions themselves, which is completely impossible). So the host must have an authoritative value for each parameter. But if the plugin is the ultimate authority on the value of parameters (like in the VST model), then you have a competition. At best, you have a painful time keeping the values in sync. At worst, you end up with irreconcilable errors in the stored values in the host.


Playing devil's advocate:

Many hosts have reasonably good undo and automation of VSTs already.  In
fact, just about everything that I do with a VST is undoable today.  Using
this mechanism.

What if we had something like the following (again, devil's advocate):

 The plugin is the owner of parameters.  Whenever a parameter is changed,
 the plugin notifies the host.  Notifications are timestamped and include
 the old value and the new value.

 The host can build it's undo stack that way, and can keep UIs in sync.
 The host can arbitrate GMPI event sources, but not things like MIDI input
 (should we choose to allow it).  The host *can* undo MIDI (or whatever)
 input because it got notification.

 Plugins that do not do notification are "broken", just like they are in
 VST-land.

How does that sound?

It's just a few steps away from "host manages everything, plugin tells
host about MIDI and sends events (actor)".  Both involve the plugin
notifying the host of changes via MIDI.

What I *don't* get is why anyone would do this.  If you already wrote GMPI
parameter support, why would you want MIDI input directly?  It's more
work.  I can understand the argument of only wanting MIDI input, and not
wanting to deal with GMPI parameters, but I really don't want plugins
doing that :)

If the question is CAN it be done with the plugin holding the values, then the answer is yes. We do it now with VST, and pretty much everything is undoable. However, having written it, I can say that it is a conglomeration of godawful hacks and a cesspool of bugs. And certain things, like plugin randomization, will simply not work.
If the question is SHOULD it be done, then my answer is definitely no.


I also completely agree that it is unnecessary to do it and I have yet to see a use case which requires it. The closest we have is a commercial imperative that some companies will not port their MIDI plugins to GMPI unless MIDI is in the graph, because of the extra work. I personally think that this argument holds no weight, particularly if we do allow SysEx, because the plugin translating a GMPI event into its own representation is something that ALL plugins have to do. If that internal representation is MIDI, it is no more difficult than if it is OSC, or float filter coefficients, or whatever. There will always be a translation from storage parameters to runtime parameters in anything but the most trivial plugin.


-- Mike Berry Adobe Systems


---------------------------------------------------------------------- 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: