[gmpi] Re: Requirements

  • From: Marc Poirier <marc@xxxxxxxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Tue, 11 Feb 2003 15:42:08 +0100 (CET)

> At NAMM meeting J=E9r=F4me No=EBl proposed to use PTAF work to
> design GMPI. Below are some requirement we used to make
> PTAF, some of you may already have got the printed copy
> at the NAMM.

I had to leave a little early and didn't get a copy.  Is it available=20
online somewhere?

My first reactions are that this reminds me a lot of the Audio Unit=20
interface.  Which I like, because AU is by far my favorite interface that=
I've worked with.  :)

> - Supports many plug-ins per library unit with the help of a
>   factory
> - Protocol to update the factory on the fly
> - Plug-ins can share data through the factory
> - Designed to implement wrappers easily

I'm not sure I understand this, but it sounds like it might be something=20
like the AUGraph stuff in AU, am I right?

> - Process only PCM audio data (not FFT-based nor compressed
>   data).

I personally would *love* a spectral plugin interface, but I could=20
understnad if other folks didn't want to add that degree of flexibility=20
into this project...

>    - Identification of silent input and output for CPU
>      saving
>    - Normalized values for communication with the host,
>      floating point data.

I don't know about x86 chips, but with PowerPC it's very simple to just=20
turn off denormals mode and then you have no chance of getting denormal=20
values.  If this is also possible with other chip architectures, then I=20
think that it would be much nicer to have the interface specify that hosts=
are required to disable denormals before audio processing begins, rather=20
than requiring that every host do denormal detection all through the=20
signal path, which wouldn't even really work anyway since it wouldn't=20
catch all of the denormals that I plugin might generate within a=20
processing frame.

>    - Optional type specification for internal use by plug-in
>      and complementary use by the host

What does this mean?

>    - Decent string support, for GUI-less plug-ins.

What do you think of AU's solution to this?  I really like it.  Because=20
you can specify unit types and real value ranges for parameters, you only=
need to specify strings for special cases, which is done by providing an=20
array of ValueStrings.

>    - Locking : token system designed to handle conflicts
>      between host and plug-in for parameter changes.

This is one thing is one thing that always seems to be missing from=20

> - Abstract note support

Again, what do you think of AU's solution to this?  It is a clearer and=20
more flexible musical event system which can wrap MIDI and optionally=20
supports straight MIDI.

> - Internal opaque state loading and saving.

Personally I think that totally opaque is not so good.  I like AU's=20
solution with a non-opaque XML settings structure with standard keys and=20
values which can easily be extended to include any personalized opaque or=
non-opaque data.

> - Preset support
>    - On the host side.
>    - Static factory presets.

Sorry to sound so redundant, but again, what do you think of AU's solution=
to this?  I think it's great, presets really are static, non-volatile=20
presets and since the settings format is XML, any configuration and=20
hierarchy of single or multiple preset storage is very straight-forward,=20
with all of the burden of management falling on the host, since the plugin=
only manages a single user state.

> - Notification-style API to avoid constant polling overhead.

Yes, this is sooo important and useful!  I recommend checking out AU's=20
property listener and parameter listener systems for example.

> - GUI
>    - Independent window at system level: host does not have
>      to dispatch and filter events.
>    - Resizable window.
>    - Communicates with the DSP part via the host, which is
>      an arbiter for concurrent access to parameters.

I think that the OS would be a better arbiter.  This would allow running=20
the GUI and DSP components in separate address spaces, computers, etc.

Anyway, these are just my reactions.  Anything that I didn't respond=20
specifically got an implicit "yup."  ;)


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: