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

  • From: David Olofson <david@xxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Tue, 18 Feb 2003 12:12:12 +0100

On Tuesday 18 February 2003 08.38, Bram - Smartelectronix wrote:
> I don't really understand why we need to specificaly quantify the
> different types of plugins. Why not just let the writer of the
> plugin decide what I/O he needs ("3 audio in, 2 audio out, 1
> musical-data out") and let the host decide what plugins work in
> it's inside ("this host only supports 2audio_in 2audio_out"

I completely agree with you, but I think you might be missing the 
point with this discussion. The reason for looking at different 
"kinds" of plugins is that we want to consider the *feature set* they 
require to be implemented. In some cases, it might actually be 
*required* that plugins are treated differently, but the preferred 
way is to just provide these features as optional protocols built on 
top of a common transport layer.

Audio, control, variable rate streaming, raw data blocks, video, ... 
Basically just data formats - but in real life, it's not quite that 

Some examples:

Driver plugins requires features that allow hosts to find out or 
dictate which driver plugins will block on I/O. Some drivers will 
need a way to do the real work in one plugin, while another is just 
an interface to a shared buffer. (Some APIs cannot open audio in and 
audio out independently.)

Converter and CODEC plugins need support for different input and 
output sample rates. Some even need variable rate streaming of some 
form through some form of pull model.

Video input and output plugins need formats with low frame rates and 
extremely large frames, compared to audio. They also need a more 
sophisticated data format negotiation API. While float32, int32 and 
fixp 8:24 might cover raw audio frame formats, I doubt people would 
be happy with just 320x240x16, 640x480x24 and 800x600x24; "frame 
format" needs to be a struct rather than an enum.

To warrant off-line plugins as anything but RT plugins running in a 
non-RT thread, they need the ability to seek in input and/or output 
streams, so they cannot rely completely on the callback/block driven 
model. They may also want to know about editor files, undo and 
whatnot. (Check out the VST off-line extension.)

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

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
   --- http://olofson.net --- http://www.reologica.se ---

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: