[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
simple.
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:
