[gmpi] Requirements
- From: "Laurent de Soras [Ohm Force]" <laurent@xxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 11 Feb 2003 15:20:23 +0100
Hello everybody,
RonKuper@xxxxxxxxxxxx wrote:
>
> The initial meeting didn't actually get very far into technical detail. The
> consensus seemed to be that as a first step we need to determine what this
> plugin needs to do/provide, before getting into implementation detail. It
> was also suggested that we discuss how various existing plugin technologies
> address the requirements for a common platform.
We (Ohm Force) worked for a long time on a new plug-in
standard called PTAF. We made PTAF using several requirements
based on our own experience on plug-in dev, along with some
suggestions or complaints about existing standards, emitted
by developers on various mailing lists, forums or IRC
channels.
At NAMM meeting Jérôme Noël 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.
General design
--------------
- C-like interface: to be easily ported on various platforms
and languages. Can be wrapped later into any OO API.
Plug-in factory
---------------
- 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
Audio plug-in
-------------
- Real-time oriented, focused on musical applications
- Instruments, effects or hybrid.
- Optimized for mid to high-level building blocks
- Multi-pin and multi-channel.
- May adapt to various audio configurations.
- Process only PCM audio data (not FFT-based nor compressed
data).
- Process efficiency
- Handling of disconnected pins and unused data
- Identification of silent input and output for CPU
saving
- Buffer address alignment for SIMD processing
- Unlimited number of parameters
- Normalized values for communication with the host,
floating point data.
- Optional type specification for internal use by plug-in
and complementary use by the host
- Support for discrete-time or discrete-value parameters
- Decent string support, for GUI-less plug-ins.
- Can receive or send parameter changes
- Optional ramp support for automations: smoother changes
- Sample-accurate automations.
- Locking : token system designed to handle conflicts
between host and plug-in for parameter changes.
- Abstract note support
- Note identification not based on pitch.
- Not restricted to MIDI limitations (microtonal pitches
for example)
- Full customizable set of parameters per note
- Note tracking after Note Off event.
- Internal opaque state loading and saving.
- Accurate synchronization with host playback.
- Preset support
- On the host side.
- Static factory presets.
- Notification-style API to avoid constant polling overhead.
- Specified threading and plug-in states.
- 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.
Feel free to comment/add/approve/critisize. Recently, PTAF
has been extensively discussed on the LAD mailing list and
interesting features and concepts were suggested.
Full PTAF doc can be downloaded from here :
<http://freezope2.nipltd.net/ldesoras/ptaf-2003.01.23.pdf>
(doesn't include results of the LAD discussion)
-- Laurent
==================================+========================
Laurent de Soras | Ohm Force
DSP developer & Software designer | Digital Audio Software
mailto:laurent@xxxxxxxxxxxx | http://www.ohmforce.com
==================================+========================
----------------------------------------------------------------------
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:
