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

  • From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Tue, 11 Feb 2003 12:10:53 -0500

[ + indicates an additional item ]

>1.  Cross-platform

+ which languages are supported? do we support bindings from others?

>3.  Interface to hosts
>a. In-Process execution model

a. In-Process and/or Out-of-Process execution model?

>b. Future work: define a layer for out of process / networked communication

b.i.  Future work: define a layer for out of process.
b.ii. 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
>e. Events are timestamped (or not...<G>)
>f. Hosts can provide sources and sinks for disk and soundcard

+ Support for source and sinks representing other applications
     (as in ReWire, JACK, DirectConnect etc.)

>4.  Audio packaging
>c. Buffers allocated by the plugin at defined points in object lifetime

c. (append "?", since this depends a great deal on what you mean by "buffers".

+ Are audio buffers timestamped? 
    (rationale: should plugins be able to work on anything except
       "the current buffer" ?) AU says yes, most other say no.

>5.  Time representation
>a. Audio wants samples, MIDI/music wants ticks, measures, beats

a.i  Define and justify "tick"
a.ii Define units of measures and beats

>b. Timecode would be nice
>c. Plugin has access to a host's sample rate, PPQN and tempo map /
>"conductor track"

+ 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)

>6.  Parameter representation
>a. One assumed data type, defined at compile time per CPU/OS

the single data type seems very unlikely. very very unlikely. we tried
this in LADSPA and its been a real pain. so:

a. Define data types, or data type definition mechanism.

>10.  The role of MIDI
>a. MIDI should be an event type

a. append "?"

>b. SysEx challenge: events with buffers
>c. Support multitimbral software synths

>12.  Enumeration
>a. Inherently OS specific :-(

a. define and provide enumeration OS independent API.

>13.  Copy protection

not clear if this relates to copy protection of plugins or of audio
and other data.

>a. Leave it to the plugin, but provide guidelines
>b. Plugins need to be aware of DRM in the streams they process

b. append "?"

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: