[gmpi] Re: a little order?

  • From: <mo@xxxxxxxxxxxxxxxxxx>
  • To: <gmpi@xxxxxxxxxxxxx>
  • Date: Tue, 11 Feb 2003 19:13:50 +0100

> since the purpose of the discussion is to frame the requirements for a
> "unified" plugin API, i'd humbly suggest that we start by listing
> things that we specifically do or do not like about existing plugin
> APIs. no solutions, no new designs - just list the things that are
> either problematic and need replacing/providing, or things that are so
> great you wouldn't want them to go away. remember non-audio/MIDI
> plugin APIs as well, if that seems relevant.

Sure. I will refrain from commenting om some of the more exotic =
architechtures I've worked with (Creamware SCOPE, Mackie UAD), since =
they probably don't make too much sense in this context. I do however =
have comments on the Mackie/Soundscape API. Also, since I'm under a NDA =
I cannot speak about Digidesign architechtures.

VST cons:
The general problem is VST is documentation and lack of standards. =
Besides this, it's not the worst architechture around. However, there's =
a few problems:

Normalised parameters: This is a big problem, since if you want to =
update the parameter range in a later version of the plug, old presets =
will be invalid.

No in-place processing (in and out is same buffer).

No format negotation (for non-32bit float operation).

No defined rules about multi-threading

No support for keying ("side-chain").

The accumulated process, which you have to support, is rather useless =
IMO.

No support for tail (not sure about VST offline though, but anyway, you =
should be able to use regular non-offline destructively also).

No error handling


VST pros:
Automation is done by setting parameters in between buffers. Most people =
would disagree, but I tend to see this as a pro, since it basically =
cannot fail. As long as the buffer size is low enough, I don't see the =
"discreetness" as a problem.

Fairly simple



DirectX cons:

Automated parameters are, because of subtle technicalities, basically =
forced to be normalised. Besides the problems that VST also have on =
this, the user will always see the parameters as 0..1 instead of "real" =
values (ms, %, whatever).
Also the automation system is much too (unneccasarily) complex, thus not =
ensuring smooth operation (lots of bugs).

No support for keying ("side-chain").

No proper support for latency compensation.

Extremely difficult to host



DirectX pros:

Uhm, can't think of any.. It's not that it's so bad, there's just =
nothing that strikes me as excellent : )



Mackie/Soundscape API

I think this is the only API I've ever worked with that got the =
parameters right(!). They're not normalised, but instead you give the =
range and the type and the curve. The system could have been better, but =
the basic idea is correct.


General:

All of the above lacks:

Proper information about hosting.

(Optional) guarantee about memory alignment (address and size). This is =
great for SIMD optimizations, and would remove the latency current =
plug-ins suffer (which has this optimization).

Guarantee about order of processing (usefull for synths where several =
instances share the same voice allocation):



Rgds,

Michael Olsen
mo@xxxxxxxxxxxxxxxxxx


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