[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=
=20
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=
=20
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=
=20
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
APIs...
> - 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=
=20
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=
=20
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=
=20
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." ;)
Marc
----------------------------------------------------------------------
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:
