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