There's still a lot of odds and ends to tidy up, but I am pleased to announce that ardour's mixer is now more or less complete. Lets take a quick look at the feature list. As a brief summary, just think "slightly better than ProTools 5.0" :) Screenshot at http://www.op.net/~pbd/ardour-mixer.png Features --------- * 32 internal busses (can be changed by a simple redefinition in the source) * unlimited number of auxiliary inputs * unlimited number of tracks * each aux input can have: input: off, mono, stereo, surround (5.1) internal bus or physical channel output: off, mono, stereo, surround (5.1) internal bus or physical channel * each track can have recorded input: off or mono internal bus or physical channel playback input: disk output: off, mono, stereo, surround (5.1) internal bus or physical channel * each track or aux can have: - unlimited number of inserts - unlimited number of sends * inserts are LADSPA plugins (physical channel support soon) * sends are: - stereo or mono - internal bus or physical channel - individual gain level - individual pan for stereo sends * edit groups allow fader-control + solo/mute/monitor input to follow group assignments * GUI: - all tracks can be displayed or removed from the mixer UI as desired, and the track order can be rearranged with the mouse. shortcuts for "hide all tracks" and "show all tracks". - ditto for auxiliary inputs. * "live passthru" mode allows the use of Ardour as a multichannel FX box. All tracks (and soon all aux inputs) are run with the full insert chain, but no data is written to or retrieved from disk: tracks/aux's just process data from their inputs and send to their outputs. NOTE: of course, "unlimited" means "subject to the capabilities of your CPU and other hardware". But there are no intrinsic limits within the software. Software Design background: -------------------------- Ardour now makes extensive of the AudioEngine object, which is a full implementation of the "RT Audio Server" that we've spoken of often here. When Ardour is running, there are two AudioEnginePlugin's attached to the engine: * the session (containing tracks based on disk material) * the mixer (containing auxiliary inputs for bus routing) The session is optional, of course :) The Engine can run any number of plugins. These plugins are *not* LADSPA plugins. They do *not* use the LADSPA/VST port model. The reason why is fairly simple. First of all, there is data conversion necessary, since the Engine makes it possible to write directly into the DMA buffer of the audio h/w (which is pretty much guaranteed not use the LADSA_Data or ARDOUR::Sample types present throughout the rest of the code). So a conversion function must be called to write the data, but we want to do this without an extra buffer, which means we have to know if we are writing additively ("+=") or by direct assignment ("="). Figuring out whether to use a run_adding()-like method or a run_replacing()-like method for each plugin is too computationally complex/costly. It varies dynamically depending on how many plugins are using a bus or physical channel. So instead, the Engine provides two methods: - read_from_channel (channel_id_t, Sample *, guint32 nsamples, guint32 offset); - write_to_channel (channel_id_t, Sample *, guint32 nsamples, guint32 offset, gain_t gain) the channel_id identifies the channel as either a physical channel or an internal bus. these methods are updated per-channel/per-bus as the numbers of writers changes for that bus (read is the same, always). Since this changes infrequently, we can avoid the "figure out which method to use" for each iteration of the engine main loop. plugins use these functions to move data to and from the channels/busses during a call to their process() method. --p
