[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 14:54:54 -0600



Chris Grigg wrote:

So by that logic, presuming the exceptions are acceptable (which they seem to be at least within this group), all of MIDI .could. be converted to pure GMPI messages at the graph boundaries, using OSC-style addressing and the current list of parameter datatypes, so long as we simply encapsulate sysex messages, probably as blob, or else by inventing a new dataype morally equivalent to blob. So we can know it would fundamentally work.

However:

A) For inherently MIDI-MIDI connection cases such as studio routing (or perhaps early ports or unhip plugs not interested in using OSC-style addressing), the only reason that has been offered for requiring MIDI->pure-GMPI conversion is easing Absolute Rewind. There does not seem to be any other reason supporting mandatory conversion. (FWIW, I remain open to any that may exist.) Whereas...

Absolute Rewind is certainly not the only thing that would be subverted. Automation would be impossible. Unless as part of A you are suggesting setParameterAutomated() again.



B) Several factors work against the basis of the NMiG argument:

B.1) As soon as MIDI sysex or GMPI blob is permitted in the GMPI graph, Absolute Rewind is no longer guaranteed, since the plug state change caused both these message types is not bounded and therefore not guaranteed trackable by the host.

I do not think that this is true as a general rule. If the plugin states which SysEx messages it is interested in them, then the host has a chance to record them as they go by. True, the semantics of the messages are unknown (i.e. exactly how many messages backwards one must go to restore state), but for many SysEx messages simply stepping back one message would work. Also, plugins could be intelligent about this and separate semantically unrelated messages to different SysEx parameters. So there woudl certainly be some SysEx messages with uncertain undo, but not all.



B.2) As soon as GMPI blob is permitted in the GMPI graph, plugs and hosts cannot be prevented from sending and receiving MIDI messages or raw MIDI bytes, packaged as GMPI messages. In this case, Absolute Rewind is not guaranteed, and only conceivable with some sort of Actor-fu.

Without host-plugin collusion, I do not see how this would be true. The plugin declares an opaque blob. How would the host know how to send MIDI to that blob? How woudl the host know to route the blob output of one plugin to the blob input of another. I don't think that just because two plugins have blobs that the host shoudl ever assume that they are compatible blobs.
So the only case I see this in is if a host manufacturer and a plugin manufacturer teamed up to create a subliminal MIDI channel (my crypto background showing its face :) inside the GMPI blob system. Plus some secret way to identify these blobs while filtering other blobs. So of course we can't prevent this. But I also don't really worry about it.



B.3) Even for ordinary pure GMPI messages, there is no guarantee that plug authors will observe the no-param-interaction-without-an-Actor rule, so Absolute Rewind is not guaranteed for any plug.

Plugins have to obey it. There is no setParameterAutomated(). So they can pretend that they are changing multiple parameters when one arrives, but the host is going to send down different values for those other parameters anyway.
If what you are saying is that some plugins will be poorly written and not follow the spec, well, what's new. But any plugin with a decent-sized audience which fails to operate consistently under automation in any GMPI hosts is likely to face some customer backlash.




So, my discussion-logic objection to excluding MiG is mainly that a thing that we don't genuinely have in the first place (Absolute Undo) is being used as the sole basis for forbidding MIDI in Graph.

Outlawing MIDI in Graph wouldn't be so bad if it weren't for the fact that it forces otherwise unnecessary (therefore inefficient) conversions at runtime*, plus probably even more importantly all the messy extra glue steps (actor, MIDI implementation expression, etc.) that would make MIDI excessively painful for developers. I don't see that dismissing plugs whose authors choose not to accept the burdens of total parameter independence or else Actors as broken really addresses their existence as factor to consider in the analysis.


I don't buy the inefficiency argument. Written properly, promotion to and from GMPI to MIDI should be nearly as efficient as creating local variables for processing. It certainly should get lost in the noise for most plugins. And since having both MIDI and GMPI in the graph simply pushes the exact same conversions into the host, I see no net benefit.
Some of the "messy extra glue steps" are required whether or not there is MIDI in the graph, i.e. the actors if you want linked parameters.
Let me ask different question. Are you unhappy with the group's requirements surrounding actors? It seems to me to be a separable issue from MIDI handling.

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

  1. Home
  2. gmpi
  3. Archive
  4. 06-2004