[gmpi] +++ RESET +++ (was RE: a little order?)

  • From: RonKuper@xxxxxxxxxxxx
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Tue, 11 Feb 2003 11:33:24 -0500

Paul Davis [mailto:paul@xxxxxxxxxxxxxxxxxxxxx] wrote:
>>>
can i suggest that we perhaps follow a slightly more orderly approach,
at least to start?
<<<

To exercise my moderator and working group chairman muscle (that feels
good!<g>) I heartily agree.  I would even suggest we take a step further
back, and not even say things "I like feature <x> in API <y>".

The first step I would like us to focus on as a group, is to identify the
topics that we want to discuss and debate.  I've taken a stab at the initial
list, below.  What I would like to is first clean up this list.  That could
mean turning a statement such as 3/a "In-process execution model" into a
question, 3/a "Q: In-process or out of process?"  It could also mean adding
items.

If possible, let's try to do this without actually debating the issues yet.
It's not time to argue in- vs. out- of process or MIDI vs. no MIDI.
Rather, it's time to establish the debating points.

Here is version 0.01 of the list:


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

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)

3.  Interface to hosts
a. In-Process execution model
b. Future work: define a layer for out of process / networked communication
c. Parameters and state changes are all kinds of "events"
d. Events are sent on a non-blocking FIFO
e. Events are timestamped (or not...<G>)
f. Hosts can provide sources and sinks for disk and soundcard

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
d. Facilitate streaming to external DSP hardware

5.  Time representation
a. Audio wants samples, MIDI/music wants ticks, measures, beats
b. Timecode would be nice
c. Plugin has access to a host's sample rate, PPQN and tempo map /
"conductor track"

6.  Parameter representation
a. One assumed data type, defined at compile time per CPU/OS
b. BLOB parameters permitted
c. Parameter names in Unicode
d. Helpers for display formatting and data entry validation
e. Create categories to substitute "like with like" parameters

7.  Persistence
a. Persisted data = a snapshot of all parameter values
b. BLOB parameters (eg sample sets) require asset management

8.  Threading
a. Thread management is up to the host
b. Plugin API should have no O/S dependent synchronization primitives

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

10.  The role of MIDI
a. MIDI should be an event type
b. SysEx challenge: events with buffers
c. Support multitimbral software synths

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?

12.  Enumeration
a. Inherently OS specific :-(
b. Simpler is better

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


----------------------------------------------------------------------
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: