[gmpi] Re: gmpi Digest V1 #5
- From: "Angus F. Hewlett" <amulet@xxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Fri, 14 Feb 2003 05:09:12 -0500 (EST)
A few comments on Ron's latest schedule...
On Fri, 14 Feb 2003, FreeLists Mailing List Manager wrote:
>
> 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
> future?
>
> 2. Plugin flavors
> Audio and/or MIDI processors, sure, but what about driver plugins,
> controllers, visualization plugins, MIDI editors?
I would like to add "synthesis components (implying, possibly, unit
generators and/or true polyphony awareness)", and "audio editors" to the
list of things we MIGHT want to include.
> 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?
These two go more or less together under the broader context of "stream
representation"... do we prefer a flexible OO-packaged stream like
DirectShow, or a simpler and less CPU-expensive but perhaps less powerful
raw stream as used by VST and others? We should also discuss how much
consistency is needed across different possible types of stream data.
> 7. Parameter representation
> What data type for values, for names? How do we support validation, value
> distribution?
Also whether or not a more comprehensive parameter navigation model is
needed. A flat parameter model a la VST is great for simple plugs, but it
breaks horribly when you're looking at possible multitimbrality and
suchlike, or multiple subcontexts within a plug. Also the possibility of
supporting "note parameters".
> 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.?
Linked to 5 and 6.
> 13. Persistence
> Whose reponsibility? How do we deal with endian issues? What formats are
> required for data interchange?
And, how are factory settings handled?
> 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?
Also, consider plugin grouping and subtypes, and mechanisms for plugs to
discover each other (either existing instances, or available for
instanciation) as well as for the host to discover the plugs.
> 17. GUI
> Can GUI be avoided at this point? What does the interface boundary to the
> GUI need to be?
Also, whether or not to isolate the GUI entirely from the plug (mediating
all plug<->GUI communications via host.. optional or mandatory?); whether
one:many, many:one or many:many plug<->GUI relationships are needed.
Regards,
Angus.
----------------------------------------------------------------------
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:
- » [gmpi] Re: gmpi Digest V1 #5
