Re: [linux-audio-dev] Plugin APIs (again)

So if we support multi-timbral (multi-part, multi-channel - too many words) instruments, then yes, this is true. Aside: I propose the following for naming stuff: * Plugin: a chunk of code, loaded or not, that implements this API (a .so file or a running instance). * Instrument: an instance of a plugin that supports the instrument API bits (analogous to a chunk of hardware from Roland). * Channel: a 'part', 'channel' or 'instrument' from MIDI. Instruments have 1 or more Channels. * Control: a knob, button, slider, or virtual control withing a Channel or Instrument. Controls can be master (e.g. master volume), per-Channel (e.g. channel pressure) or per-Voice (e.g. aftertouch). * Preset: a stored or loaded set of values for all Controls in a Channel * Voice: a playing sound within a Channel. Channels may have multiple voices. * Port: an input/output connection on a Plugin. Audio data goes over ports. I agree with that IF we say you have to have a separate control struct for per-voice and per-part controls. If we define a control and say it has a flag which identifies it as MASTER, PART, VOICE, then we do need to suggest a relationship. I like defining a control once, but it's becoming more obvious to NOT do that. They range of valid values may be wildly different. Do we want to provide a suggested range of values for MIDI compatible controls. For example Controls that are labelled CONTROL_AFTERTOUCH should expect values between 0 and 1.0, and the host can map MIDI onto that? Or 0 and 127, like MIDI? or 0 and MAX_INT and let the synth blow up when you pass a VELOCITY of 10000, and it expects 127? umm, speed == velocity, no? But I get your point, and I concede this point. Velocity is an event. I had been assuming a single event-queue per instance. Two questions: why would a plugin (assuming not multi-timbral for now) have more than one event-queue? Assuming we do support multi-timbral synths, is there an advantage to having events per-channel event-queues? Do you envision each Channel getting the ->run() method seperately, or does ->run() loop? If it is looping anyway, is there an advantage to multiple event-queues? I know you've done some exploring - do we really want one event-queue per voice + one for each channel + one for master? or is one per instance simpler? I can see controller plugins (It's another extension to this API, perhaps) which deal with sending events to other plugins. And I guess an arppegiator plugin could be a controller.. you don't send just ANY integer, you get the integer to id a voice FROM the plug. But if VOICE_ON is an event, it gets much uglier. Do let me see if I get this right: Host allocates the VVID pool (perhaps a bitmask or some other way of indicating usage) Host wants to send a VOICE_ON: allocates an unused VVID sends VOICE_ON with that VVID when it sends a VOICE_OFF or receives a VOICE_OFF it can mark that VVID as unused again. Plugin wants to send a VOICE_ON: calls host->get_vvids(32) host allocates it 32 VVIDs sends VOICE_ON with any of those, and must manage them itself (alternatively, management is simpler if it just allocates one VVID at a time and frees it when it is done) Or does the HOST ask the INSTRUMENT for VVIDs? If so, why? Explain? :) I agree - this is the host's job, not the plugin's I meant threading sync issues. Host can't just pass one event-queue to all plugins in a multi-thread environment. But again, that is the HOSTs problem. So the host can pass the address of it's event-queue during activate(), or the plugin can make a host->send_event() callback.