[gmpi] Re: Item 0: Agenda

  • From: RonKuper@xxxxxxxxxxxx
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Thu, 13 Feb 2003 09:49:16 -0500

I've taken all of the feedback, and made another pass at the list.  As
suggested by a few on the list, I think the next step should be determine
the order in which we tackle these items.  I've taken a stab at that, too.
Feel free to suggest changes.

1.      Audience for and users of plugins
Who are our target users/customers?  Who are our target developers?  What
kinds of plugins do people use today, and what will they want to use in the

2.      Plugin flavors
Audio and/or MIDI processors, sure, but what about driver plugins,
controllers, visualization plugins, MIDI editors?

3.      Cross-platform
What processors, O/S, addressing models and programming languages do we need
to support? Level of heterogenity on u-controller+DSP systems?

4.      Host interface
In-process or out-of-process?  What kinds of special needs are there in
events to/from a plugin?  Is the host a plugin too?  Can the host be a chain
of simpler plugins (sequencer, timeline, automation)?  Transport control, UI
updates, track information?

5.      Time representation
Samples or "ticks" or both/neither?  How are discontinuities expressed?

6.      Audio packaging
What do we prefer for interleave, audio sample data types, allocation,
timestamping?  Are compressed formats like MP3 permitted? 

7.      Parameter representation
What data type for values, for names?  How do we support validation, value

8.      The role of MIDI
How important is it?  How do we ensure something new is still backwards

9.      Signal routing
How is audio and control data communicated between objects?  Can plugins
produce more/less data than they consume?  Do plugins work in "pull" or
"push" model?  Do we allow plugins inside plugins, full multirate
synchronous data flow graph, etc.?

10.     DSP state
When and how does a plugin reset?  How to respond to format changes?  What
formal "states of life" has a plugin? Are there different levels  of
initialization? When does which information/functionality exist?

11.     Threading
What kind of realtime guarantees?  Does the host provide some kind of
threading environment?

12.     Scalability
Transport layer + optional protocols, or something more monolithic?   What
can and cannot be optional for plugins and hosts? Can certain protocols be
handled through reusable host side "support modules"?  Plugin SDK emulation
features for non-optional protocols?

13.     Persistence
Whose reponsibility?  How do we deal with endian issues?  What formats are
required for data interchange?

14.     Localization
How does the host specify its language?  Logical vs. human-readable names?

15.     Component packaging
Is there a "base level" possible that's still cross platform?  How do we
support all target platforms?

16.     Enumeration (creation, discovery, etc.)
Create for use vs. query, what can a plugin do at creation time, RT safety?
What kind meta-data does the plugin reveal?

17.     GUI
Can GUI be avoided at this point?  What does the interface boundary to the
GUI need to be?

18.     Copy protection
How should plugins address DRM streams?  How to sign OpenSource plugins?

19.     Source code
How are headers and host libraries/source licensed?  What kind of sample
code is required?  What coding conventions do we use?  What languages is
sample code written in?

20.     Version Control
How do we manage the versioning of GMPI?  How do we manage versioning issues
with plugins?   When a new release of a plugin comes out should it be
backwards compatible with earlier versions? i.e. Should DSP binary
compatibility in the strict sense be a requirement?  Should plugin
parameters be compatible across versions? How do we handle enhancements to
parameter ranges, etc.  What model should be used for version control?

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: