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

  • From: "Laurent de Soras [Ohm Force]" <laurent@xxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Wed, 12 Feb 2003 10:39:32 +0100

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

Other related posts: