[gmpi] Re: +++ RESET +++

  • From: <mo@xxxxxxxxxxxxxxxxxx>
  • To: <gmpi@xxxxxxxxxxxxx>
  • Date: Wed, 12 Feb 2003 11:34:52 +0100

Good work Laurent!

However, before starting to discuss these features in detail, I really suggest 
it is discussed where to go... Looking at the discussion so far, this could 
turn out to be a huge standard, which I feel would stop a lot of people from 
implementing it (myself included).

Or to put it another way... Before we know what to design we cannot design it.


Michael Olsen

> Guys (and ladies ?), the amount of posts is really huge
> and it's hard to follow, note or even to understand
> everybody's suggestions.
> I suggest for this first discussion :
> - We stay on topic, I mean we only make an organized
> list of suggestions and points.
> - We name a secretary (or is it you, Ron ?) to make notes,
> organize them, and provide up-to-date reports.
> - I don't have seen too much people from big plug-ins or
> host companies bere, are they on the list ? I think it's
> important to take into account their own considerations,
> if we want to interest the plug-in market...
> - Maybe we reduce the flow: content size as well as number
> of posts. We don't need to argue much now, since we'll do
> it later, when precise points will be discussed.
> Otherwise I have bad feelings about these discussions,
> turning into endless trolling...
> Below, I summed up what I found in +++RESET+++ posts.
> Actually I just copy/pasted provided information to keep
> the list clean and quick to read. However there may remain
> redudant information, I haven't sorted much. I hope I
> respected everyone's ideas - if not, please correct. I
> also added my own suggestions.
> 1.  Cross-platform
>    a. Different processors
>    b. Different operating systems, including Windows, Mac,
>       Linux, PDA's, embedded
>    c. Write once, compile many
>    d. At the level of standard C or STL
>    e. cross-platform DSP vs cross-platorm GUI
>    f. which languages are supported? do we support bindings
>       from others?
>    g. ability to resolve accross address spaces or not
>    h. define limits of cross-platform specifications
> 2.  Kinds of plugins we seek to build
>    a. Audio processors
>    b. MIDI processors
>    c. Audio processors with MIDI control
>    d. No codecs (no changing sample format)
>    e. Kinds of plugins matrix.
>    f. Driver plugins. Wraps MIDI and audio APIs for GMPI
>       hosts to use intead of directly supporting all APIs
>       on a platform. Related to 3f, I think.
>    g. controllers - designed to control other knobs (LFP,
>       envelope, peak-follower)
>    h. Anaylsers, visualisation (Cthugha-like)
> 3.  Interface to hosts
>    a. In-Process and/or Out-of-Process execution model?
>    b.1 Future work: define a layer for out of process.
>    b.2 Future work: recommend protocol for networked
>        communication (several good ones emerging, the
>        design + implementation of which are orthogonal
>        to our issues, i believe)
>    c. Parameters and state changes are all kinds of "events"
>    d. Events are sent on a non-blocking FIFO
>    d.2 ...or as structs in linked list queues, where events
>        are fixed allocated from a host managed pool.
>    e. Events are timestamped (or not...<G>)
>    f. Hosts can provide sources and sinks for disk and
>       soundcard
>    f.2 ...or 2e; hosts can use (or provide built-in) Driver
>        plugins.
>    f.3 Support for source and sinks representing other
>        applications (as in ReWire, JACK, DirectConnect etc.)
>    g. sources and sinks should certainly be able to be
>       plugins. hinted audio ports and controls - to make
>       automatic connections easier
>    h. property listeners and parameter listeners vs. polling
> 4.  Audio packaging
>    a. Interleaved or multiple mono
>    b. One assumed data type for audio, defined at compile
>       time per CPU/OS
>    c. Buffers allocated by the plugin at defined points in
>       object lifetime. This depends a great deal on what
>       you mean by "buffers".
>    d. Buffers allocated by host, perhaps, rather than plugin
>    e. Facilitate streaming to external DSP hardware
>    f. A method for the host to specify memory alignment of
>       a particular audio buffer, and to guarantee a minimum
>       buffer alignment. Same for plug-ins
>    g. Are audio buffers timestamped? (rationale: should
>       plugins be able to work on anything except "the
>       current buffer" ?) AU says yes, most other say no.
>    h. denormals (plugin concern or host concern or CPU state
>       concern)
> 5.  Time representation
>    a. Audio wants samples, MIDI/music wants ticks,
>       measures, beats
>    a.1 Define and justify "tick"
>    a.2 Define units of measures and beats
>    b. Timecode would be nice
>    c.1 Plugin has access to a host's sample rate, PPQN and
>        tempo map / "conductor track"
>    c.2 support for "conductor track" per <something>. many
>        experimental composers like this (e.g. one CT per
>        track, with different tracks running at different
>        tempos/meters)
>    d. Host-defined 64 bit integer tick per second value
>       required to be constant during run-time. All times
>       and sample rates are represented in this tick's units.
>    e. handling non-linear transport motion (e.g. host is
>       looping) (most (all?) existing APIs don't do this well)
>    f. "Pre-buffer markers" or other means of telling HDRs
>       and the like about target points for which zero
>       latency skipping at any time must be possible. (For
>       looping, conditional jumps in interactive compositions
>       and the like.)
> 6.  Parameter representation
>    a. Define data types, or data type definition mechanism.
>    b. BLOB parameters permitted
>    b.2 Reading and writing of BLOB files for plugins running
>        in a real-time host.
>    b.3 Automation or user/GUI triggered loading of BLOBs.
>    b.4 BLOB data should be platform independent, as far as
>        possible.
>    c. Parameter names in Unicode
>    c.2 Symbolic parameter names in US ASCII.
>    c.3 Internationalization performed by gettext() style
>        system and separate translation files, either host
>        or plugin side.
>    d. Helpers for display formatting and data entry validation
>    e. Create categories to substitute "like with like" parameters
>    f. String parameters, hinted as file names, paths, scripts etc.
>    g. Transmission of large string blocks, using fixed size
>       memory blocks, managed by the host.
>    h. Natural param vs normalized, conversion functions
>       between both.
>    i. value distribution curve (none or enum and/or
>       custom function)
>    j. min, max, default values
>    k. unit type (enum or custom string)
>    l. all one type or support for multiple types
>       (intgeger, decimal, boolean; union, struct)
>    m. read/write/visible/invisible attributes
>    n. randomizable
>    o. hard ranges or soft ranges
> 7.  Persistence
>    a. Persisted data = a snapshot of all parameter values
>    b. BLOB parameters (eg sample sets) require asset management
>    c. handle multiple state sets internally in plugin or
>       handled by host
>    d. presets are static or volatile
>    e. settings storage format (single or multiple states,
>       endian, defined/opaque/mix)
> 8.  Threading
>    a. Thread management is up to the host
>    b. Plugin API should have no O/S dependent synchronization
>       primitives
>    c. A thread identifier passed by the host in selector
>       calls, and required for callbacks.
>    d. Real time guarantees or only soft real time?
>    e. Worker Calls? (Send off a function to run where the
>       host finds appropriate. Host posts return value as
>       event.)
>    f. host should provide simple threading support - plugin
>       can run background tasks, possibly with a priority (1-10?)
>    g. Well specified threading for each API functions
> 9.  GUI
>    a. We've got enough work just to create a headless API
>    b. Once parameter interface is nailed down, another
>       group can do GUI
>    c. thread/process (non-)specification for GUI/DSP
>    d. Issues related to complex plugins (samplers) if GUI
>       is separated from host
> 10.  The role of MIDI
>    a. MIDI should be an event type
>    b. SysEx challenge: events with buffers
>    c. Support multitimbral software synths
>    d. we should leave MIDI out except as to note how to
>       make it compatible.
> 11.  Packaging issues
>    a. Base: Static object libraries
>    b. O/S specific: dynamic libraries (sample code wrappers)
>    c. As new platforms emerge, how to specify the packaging?
>    d. How to support all targeted platforms? Or how to
>       reduce the amount of support necessary?
> 12.  Enumeration (Creation, Discovery, etc.)
>    a. define and provide enumeration OS independent API.
>    b. Simpler is better
>    c. plugin discovery (standard location, registration)
>    d. different levels of creation (just enough for host to
>       inquire about properties plus another level to prepare
>       resources for audio processing  [for more efficient
>       scanning, and other issues], or only one simply level
>       of creation)
>    e. defined rules for plugin behavior at each creation
>       stage. For instance, no user interface allowed during
>       capability queries.
>    f. Dealing with operations that are not RT safe.
>    g. Factory stuff
> 13.  Copy protection
>    a. Leave it to the plugin, but provide guidelines
>    b. Plugins need to be aware of DRM in the streams they
>       process
>    b.1. DRM aware plugins should not convert a stream to
>         DRM just to be safe.
>    b.2. DRM aware plugins on a non DRM capable host, should
>         allow processing of non DRM streams.
>    d. How to sign OpenSource plugins?
> 14. Localization
>    a. A well defined method for the host to specify the
>       current language.
>    b. Separation of logical and "human readable" names for
>       controls, ports and the like. (Related to 6c.)
>    c. Up to the plug-in
> 15. DSP state:
>    a. when to reset
>       1. and what to reset (different types or resetting?)
>    b. handle multiple stream formats or not
>       2. single plugin can handle multiple i/o configs
>       3. single plugin instance can handle multiple sample
>          rates
>       4. how does the plugin react to any changes in stream
>          format (destroy and reinstantiate, DSP state reset,
>          higher level DSP resources constructor/destructor
>          [see Creation b. above])
> 17. License for headers and host libraries/source?
>    a. LGPL
> -- 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

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: