[gmpi] Re: +++ RESET +++ (was RE: a little order?)
- From: David Olofson <david@xxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 11 Feb 2003 23:55:20 +0100
[My additions, some of which build on other posts in the thread, all=20
mergede into one post:]
On Tuesday 11 February 2003 17.33, RonKuper@xxxxxxxxxxxx wrote:
> 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)
e. Driver plugins.
(Wraps MIDI and audio APIs for GMPI hosts to use intead of directly=20
supporting all APIs on a platform. Related to 3f, I think.)
> 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
d ii. ...or as structs in linked list queues, where events are fixed=20
allocated from a host managed pool.
> e. Events are timestamped (or not...<G>)
> f. Hosts can provide sources and sinks for disk and soundcard
f ii. ...or 2e; hosts can use (or provide built-in) Driver plugins.
(Are we thinking about the same thing, actually?)
> 6. Parameter representation
> a. One assumed data type, defined at compile time per CPU/OS
> b. BLOB parameters permitted
b ii. Reading and writing of BLOB files for plugins running in a real=20
time host.
b iii. Automation or user/GUI triggered loading of BLOBs.
b iv. BLOB data should be platform independent, as far as possible.
> c. Parameter names in Unicode
c ii. Symbolic parameter names in US ASCII.
c iii. Internationalization performed by gettext() style system and=20
separate translation files, either host or plugin side.
> d. Helpers for display formatting and data entry validation
> e. Create categories to substitute "like with like" parameters
f. String parameters, hinted as file names, paths, scripts etc.
g. Transmission of large string blocks, using fixed size memory=20
blocks, managed by the host.
> 12. Enumeration
> a. Inherently OS specific :-(
> b. Simpler is better
Enumeration of *what*, actually? (Need a bowl of tea...)
> 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
c. Never trust a kli... uh, host! (Of course...)
On Tuesday 11 February 2003 18.30, Mike Berry wrote:
[...]
> > 8. Threading
> > a. Thread management is up to the host
> > b. Plugin API should have no O/S dependent synchronization
> > primitives
>
> c. A thread identifier passed by the host in selector calls, and
> required for callbacks.
d. Real time guarantees or only soft real time?
e. Worker Calls? (Send off a function to run where the host
finds appropriate. Host posts return value as event.)
> 14. Localization
> a. A well defined method for the host to specify the current
> language.
b. Separation of logical and "human readable" names for controls,
ports and the like. (Related to 6c.)
> > 15. (from Marc)
> > a. plugin discovery (standard location, registration)
> > b. different levels of creation (just enough for host to
> > inquire about properties plus another level to prepare
> > resources for audio processing [for more efficient
> > scanning, and other issues], or only one simply level
> > of creation)
> c. defined rules for plugin behavior at each creation stage.
> For instance, no user interface allowed during capability
> queries.
d. Dealing with operations that are not RT safe.
(This includes memory management, wavetable rendering, filter core=20
calculations etc. Require that hosts move plugins out of net before=20
performing operations marked unsafe, or requere that plugins send=20
such operations off to Worker Calls or similar?)
On Tuesday 11 February 2003 21.13, Paul Davis wrote:
> >5. Time representation
>
> + handling non-linear transport motion (e.g. host is looping)
> (most (all?) existing APIs don't do this well)
And...
+ "Pre-buffer markers" or other means of telling HDRs and the
like about target points for which zero latency skipping at
any time must be possible. (For looping, conditional jumps
in interactive compositions and the like.)
//David Olofson - Programmer, Composer, Open Source Advocate
=2E- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
----------------------------------------------------------------------
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:
