[gmpi] Re: R: Re: Topic 1: Audience for and users of plugins

  • From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Sun, 2 Mar 2003 18:12:23 -0800

David wrote: 

On Sunday 02 March 2003 01.37, Koen Tanghe wrote:
[...]

 The GMPI indeed stands for "Generalized Music Plugin Interface
 (GMPI)" (note the word "music").

 But on the other hand, I personally would be very pleased to see
 image sequences (video) incorporated in a plugin interface. I read
 other people's opinions about why not just specify a plugin as
 having a certain number of inputs and a certain number of outputs
 of potentially different data types, and I liked it.

I used to like that idea myself, but...


 There are
 differences however in types with respect to asynchronous /
 synchronous behavior.


...it seems to have severe implications. Doing asynchronous processing
in the context of a low latency audio engine is going to be very
complicated. The only "easy" way would be to assume that every such
plugin runs the asynchronous processing in a separate thread, using
the "actual" plugin only as an interface. At that point, it starts to
look ridiculous, IMHO. Video plugins and the like belong in their own
net in a separate thread.


 But I think it is important to agree on this when defining the
 goals. If possible, I would like to see audio, MIDI (or something
 similar), images and control signals as the four basic types that
 flow around between hosts and plugins.

Koen Tanghe

 PS
 About MIDI: one could in fact maybe think about this as a special
 kind of "control signal"


Yes, if even that. I think you're making MIDI more special than it is.
The only thing that makes it relevant at all in this context is the
fact that it's the industry standard wire protocol. It might be handy
to be able to pipe it as is through the API, but there are no logical
motivations, and only weak technical/practical motivations, IMHO.

//David Olofson - Programmer, Composer, Open Source Advocate


Couple points here, neither I think particularly OT for the 'audience' thread.

1- I think we should be looking a little more closely at the assumption that not using MIDI is the best thing to do. If the host app is a MIDI sequencer, including a MIDI+Audio sequencer -- and I think this is pretty much the typical use case for GMPI -- then yes, MIDI -is- a somewhat special data type, in that many sequencers do use MIDI (or at least extend MIDI) as their native music event representation, in part in order to make driving MIDI wires as efficient as possible. From that POV, using something other than MIDI for the music data type could reduce overall efficiency, even if they might simplify life for some plug-in developers somewhat, since a host that uses MIDI natively would need to convert into and out of the alternative representation in its GMPI framework.

2 - There is a distinction to be made between what in & out data types GMPI will support at first, vs. what types it will eventually be able to support as (and if) it grows in the future. I am confident that we can find a way to express audio and music and control ins & outs now, that leaves room for expressing other data types in the future, without requiring the hosts now to do anything very different from what they already do at runtime with audio and MIDI lines. If coded correctly, this generalized approach need not be a big complication for the plug developer, and remember, most of the I/O negotiation stuff will happen at setup/instantiation time, and so won't impact the normal operating/processing load. On the other hand, if we get married to only audio and music now, without an extensible type framework, then GMPI will most likely never be able to grow in that direction, and so will likely eventually be replaced -- which would kind of defeat a significant part of the basic purpose of GMPI, no?

So, I would prefer to see GMPI use a type-agnostic, efficiently designed plug I/O framework, and would expect that only audio and music would be defined for v1.0, with tight implementations (maybe control too, depending on how those discussions go).

-- Chris

----------------------------------------------------------------------
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. 03-2003