On Thu, Oct 09, 2003 at 06:14:51PM +0200, Marco Ballini wrote: > I'd like also to understand the exact goals of this API (for example if > you could add, remove plugins or change connection between them while > others are running). To retain all the functionality of all the current plugin APIs, while adding a healthy dose of sanity, cleaniness, and modernness. > Here are some questions (forgive me): I can answer all of these in two ways: The GMPI answer and my own ideas. > - How multiple voices are handled in a synth plugin? GMPI: We're not there yet. We're gathering requirements. Do you have a requirement in this area? ME: Voices are not really part of the API. They are internal to the synth. > - Is there an agreement on what a "channel" is? GMPI: We're not there yet. We're gathering requirements. Do you have a requirement in this area? ME: 'Channel' is so overloaded. What do you really mean? > How would you handle a mixer with arbitrary inputs? (I use channels for > that) I've envisioned something akin to channels being used for this, too. I called them modules. Each plugin can define N module templates. Upon request, it can instantiate those modules. You can use a module for each MIDI channel. You can make a mixer that has mono, stereo, and 5.1 module types, and load as many of each as you want. But we're not NEARLY there yet. > - Will network plugins be allowed (plugin that contain other plugins in > a graph. in that case the host could be a thin layer around a network > plugin)? GMPI: Nothing stops that from happening. ME: It should be easy to take the GMPI SDK and make a plugin that is a GMPI-host. It should also be easy enough for a host to store a sub-graph of plugins as a preset and re-load that. We may decide to formalize such a subgraph preset as part of GMPI. > - Will sequencer plugins be allowed (on the same graph level of the > plugins it controls)? GMPI: Nothing stops that from happening. ME: That is the 'right' way to do it. > - Will shared resources be allowed (for example a wave, an envelope, a > song or a graph-configuration shared between many plugins)? I don't understand the question - explain? > - Will developers have to write many plugins (as in LADSPA) to allow a > control (example: cut-off, resonance, volume) to be handled both with > single events or with a stream of values (for example from an audio > output from another plugin)? Will have the user to destroy and recreate > the plugin to change the type of connection? Two questions here. First control stream vs events. GMPI: This has not been totally addressed. Do you have a requirement in this area? ME: I don't think audio-rate controls need to be supported. Generic controller plugins should be outputting events. If you want a side-chain in your plugin, you can code it as such, but it is important to note the difference between a control stream and a data stream. It is also possible to write a side-chain generic controller that takes audio in, and spits out events. 2nd: Connection changing GMPI: We're not there yet. We're gathering requirements. Do you have a requirement in this area? ME: We're not there yet. I personally think you should be able to change all that on-the-fly, but it doesn't REALLY matter. > - Is the distiction between audio data and control data realy needed? > (I consider audio and control just *hints* for a parameter) > - How will memory be available to a plugin (a function, an event, > or...)? We hadn't argued this tooo much yet. It's very paradigmatic. If audio and control are essentially indistinguishable, you have some advantages and some disadvantages. Ditto for the reverse. I think everyone has tentatively agreed that event-driven, just-in-time delivery of atomic (and maybe ramped) control changes is the sanest approach TODAY. -- Notice that as computers are becoming easier and easier to use, suddenly there's a big market for "Dummies" books. Cause and effect, or merely an ironic juxtaposition of unrelated facts? ---------------------------------------------------------------------- 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