[gmpi] Re: 3.15 MIDI (What does it mean to be a plugin)
- From: "Ron Kuper" <RonKuper@xxxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Fri, 18 Jun 2004 09:29:47 -0400
Very lucidly put. Especially for one sleep deprived. Do you have
kids?<g>
I would advocate creating a special data type for MIDI.
>>>
- If we support MIDI and GMPI control data as separate types, then we
dilute the potential compatibility of GMPI hosts and plugins. Some
people will choose to write plugins which only take MIDI control, not
because of inherent MIDI bytestream characteristics, but just because it
is familiar. Some will write plugins that only handle GMPI control data
because it is more flexible or easier to understand than MIDI or
whatever their reason is. These plugins will not be able to exist in the
same graph without translation (host-based or other plugin based).
<<<<
It's true, without translation these things can't coexist. So let's
make the standard GMPI kit include 2 "glue" components, both plugins
which have a single control input and single control output. One maps
GMPI to MIDI, the other vice-versa. If a GMPI host wants to run MIDI
plugins, it can add the glue.
But more importantly, if a host that knows about raw MIDI wants to talk
MIDI to a plugin that knows it, it can.
>>>
So here is my question for the whole group. Can you give me
real-world examples of plugins whose functionality REQUIRES knowledge of
the MIDI bytestream?
<<<
As Vincent said, hardware implementations of GMPI. To that I'll add,
hardware synths that have been repurposed into software. I know of
specific synths (some of the ones we did with Roland) which were
originally hardware/ROM based and are now host based. Their engines
were coded with specific awareness of MIDI.
-----Original Message-----
From: gmpi-bounce@xxxxxxxxxxxxx [mailto:gmpi-bounce@xxxxxxxxxxxxx] On
Behalf Of Mike Berry
Sent: Friday, June 18, 2004 5:41 AM
To: gmpi@xxxxxxxxxxxxx
Subject: [gmpi] Re: 3.15 MIDI (What does it mean to be a plugin)
I have changed the thread name here to start a new thread
because I believe that this discussion really gets down to the core of
what being a plugin means. So here goes my shot (please bear with me, as
this is a little long).
Being a plugin means that your entire view of the world is
mediated by your host. You tell the host: I can recieve such and such,
and in response I can generate such and such. For GMPI, we have
previously determined that there are two fundamental types of data in a
GMPI graph:
audio data and control data. Each has a set of attendent rules.
During the audio format discussion, we talked about encoded
audio where the host does not know the encoding. For example, lets say
your plugin wanted to operate on a MPEG-1 compressed bitstream, to
decompress it into PCM. We decided that this plugin is outside of the
scope of GMPI.
GMPI would only be plugins that were able to operate on PCM audio. Does
this make a MPEG-1 decompressor invalid in any way? No. It simply means
that it is not a GMPI plugin.
So this brings us to control data. I believe that exactly the
same reasoning that led us to disallow non-PCM audio formats to "tunnel"
through the GMPI graph to be handled by specific plugins should lead us
to disallow specific control data formats from tunnelling as well.
MIDI is one of a number of formats for musical control data to
be passed between components. It is a popular one, but it is also not
appropriate to be the sole control data format inside GMPI (without
extension, that is). No one, to my knowledge, has argued that MIDI, as
is, should be the sole control data format in GMPI.
I believe that it is a fundamental rule necessary to the success
of GMPI that the host be able to understand, completely, all forms of
data passing between plugins. This is because only the host knows the
context in which a particular plugin exists. Without completely
understanding the data flow, the host will never be able to properly
place plugins in the graph.
So where does this leave a plugin which transforms MIDI data? I
currently believe that it leaves it outside of GMPI, but bear with me
for a minute while I defend that, and I will give you a chance to change
my mind.
Processing GMPI control data into different control data output
or audio output is a completely reasonable task for a GMPI plugin. But
the plugin can never know where that data came from other than "it came
from the host." It is the host's job to be the arbiter between the
complex outer world, where many control formats exist, and the clean
inner world, where just GMPI-intelligible formats exist. The whole
reason that an author is writing a plugin instead of a host is that they
want the host to handle that complexity for them, so that they can focus
on a specific, specialized task not provided by the host.
So there have been a number of questions about "how would I
write this or that MIDI processor inside GMPI." I think that it comes
down to a simple distinction. One possibility is that you are writing a
control processor, which could operate on data that was originally MIDI,
but could also operate on data that was originally OSC, or hand-drawn in
a host UI, or another plugin's UI. In other words, you are a GMPI
control data processor.
The second choice is that you only process MIDI data, because of
some intrinsic MIDIness of the data. This could be a reasonable plugin,
but only in a system whose purpose was to process MIDI data (go back to
my compressed MPEG example). So if I was a host which supported MIDI, I
could host your plugin in the MIDI path.
So the fundamental question for me is whether or not it is
within the scope of GMPI to support MIDI-specific plugins. I.e., is MIDI
a priviledged data type like two we have currently agreed upon, PCM
audio and GMPI control data. I think that this is an interesting
potential discussion to have, but not exactly the discussion that we
have been having.
One upshot of elevating MIDI to a fundamental type is that it
makes possible a MIDI->MIDI processor plugin that is otherwise
impossible. It is otherwise impossible because it explicitly must
operate on the MIDI byte stream to have meaning. A trivial but
functional example would be a plugin which replaced running status bytes
with complete messages. This plugin has no meaning for non-MIDI control
data.
Another example would be a MIDI note number to frequency map. It
takes in MIDI note-ons and produces a GMPI control output of a pitch. A
third example would be any plugin that handled SysEx of any kind.
So is MIDI is an important enough format to be elevated to
fundamental status inside GMPI? My host (Premiere) currently operates
without MIDI of any kind. We do audio data and control data only. So it
is completely possible to write a GMPI application without MIDI. But
this is not a reasonable argument for us to not have MIDI as a type.
Premiere also does not have "instrument" plugins or a tempo system, but
I can recognize that GMPI requires both of these to be a successful
architecture. Premiere will simply not host the full set of GMPI
plugins, because the functionality is not relevant to our task, and we
could also not host plugins requiring MIDI inputs or outputs.
So in order to make my personal decision on whether MIDI is a
worthwhile fundamental format, let me expose what, to me, are the two
counterbalancing arguments:
- If we have MIDI as a format, then plugins can be written which
explicitly exploit the MIDI byte stream in some way.
- If we support MIDI and GMPI control data as separate types, then we
dilute the potential compatibility of GMPI hosts and plugins. Some
people will choose to write plugins which only take MIDI control, not
because of inherent MIDI bytestream characteristics, but just because it
is familiar. Some will write plugins that only handle GMPI control data
because it is more flexible or easier to understand than MIDI or
whatever their reason is. These plugins will not be able to exist in the
same graph without translation (host-based or other plugin based).
Right now, I think that the second consideration outweighs the
first. I am more worried about the matrix of complexity and
compatibility that results from having 3 fundamental types instead of 2,
than for the lost possiblity of writing MIDI bytestream specific
plugins. But I am willing to remain open minded here.
So here is my question for the whole group. Can you give me
real-world examples of plugins whose functionality REQUIRES knowledge of
the MIDI bytestream? I have given two trivial examples, but I want to
hear the real meaty examples which will sway me to say "Wow, if we leave
that functionality out of GMPI then we will have failed." So strummer
plugins or requantizer plugins in and of themselves are not examples of
what I am asking for. While these could operate on MIDI data, they could
also operate on GMPI control events. I want to know about the plugins
that could only exist if ew elevate MIDI to a fundamental type.
Thanks for reading this far on a long post which got me out of
bed at 3 in the morning to write it because I couldn't sleep otherwise.
--
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
----------------------------------------------------------------------
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:
