the conception of JackMix
usage
The basic concept of a mixer is rather easy: You have a number of inputs (n) which you want to route and mix into a number of outputs (m). So there is a (n,m)-matrix and the elements define the mixingvalues.
A harder part is to find a decent, easy-to-use graphical user interface (gui) for this mixing process. Especially as there can be such features as adding and removing inputs and outputs, hiding channelstrips, coupling controls, etc.
The new concept of JackMix (as of version 0.1) allows you to put controls as you like onto the routing points of the matrix as you like. By default every point has a simple one-to-one control on it, meaning one input is mixed to one output. You can select multiple controls and replace them by a matching multi-in-multi-out control. And these ones can be replaced too.
By using the controls you need for the channels you need it is for example possible to have several in-channels mixed on 6 out-channels in 5.1 mode and several other in-channels mixed in stereo mode onto the first and second pair of the same outputs.
inside JackMix
For the internals I am trying to make JackMix as multitalented as possible. One point of this is to create factories for all groups of controls (inside libraries) to create these controls. Another thought, currently not implemented, is to make the backend-interface abstract so one can use for example the jack-backend with variable numbers of in- and out-channels or an alsa-backend with ins and outs in fixed number representing the channels of the soundcardmixer. Or an backend for dmix, aRts, gstreamer...
Thinking about it I could also imagine to support several mixers (and backends) in one instance of JackMix.
classes around controls
There are several classes needed to get a control: JackMix::Matrix::Widget, JackMix::Matrix::Element and JackMix::Matrix::ElementFactory (all in mixingmatrix.h) and JackMix::Matrix::Global (in mixingmatrix_privat.h). Lets discuss these classes in detail:
JackMix::Matrix::Element
This abstract class represents a control of variable size. It contains the basic functions to detect selected neighbors, to identify the control and (in the future) to have and announce controllable and controlling properties (like faders).
JackMix::Matrix::Widget
This is the main mixingdesk getting a list of in- and out-channel names and filling the matrix with controls. Handles the adding, replacing and removing of controls and channels.
JackMix::Matrix::ElementFactory
For the elements to be creatable even from loadable libraries, there needs to be a factory which knows them. ElementFactory is used for this. Every group (group by what-so-ever) has to have an ElementFactory which has to be created inside the c-file without external action. It automaticly contacts the Global object and is then used to create Elements.
JackMix::Matrix::Global
This is a non-public class for a singleton. All the ElementFactories register at this global and every Widget uses the global to create Elements.
One thing to do in long-term is a mechanism to load libraries dynamicly to make third-party-controls possible.
the backend
Currently the backend is one static thing. My thought for the future are to make it pluggable (without restart?) and provide several(?) backends with different features and possibilities. For example a jack-, aRts- or gstreamer backend can provide a configurable number of channels whereas an alsa-backend representing the hardwaremixer is fixed size and my not have general per-channel preamplification. Or someone invents a faster mixing algorithm optimized for a fixed number of channels...
These could be made loadable from libs like the controls.
random future ideas
making full use of OSC
One idea which came to me after reading some of the "audio-apps-without-gui"-threads on la[ad] was to split JackMix into a deamonlike non-gui server doing the real mixing and a gui with all those nice features like automation, coupling, controlling several mixers in one window, etc...
The communication between these two programs could be done via OSC. One advantage would be that JackMix would be usable also by blind people or could be used to control the output of none-OSC synths or direct input from an OSC-controller in these freaky-spacy-events.
Feedback from the server to the gui would then also happen via OSC-messages since OSC doesn't seem to support direct feedback or return values. Again there is an advantage: The gui would also be updated if changes where done by other programs. So there could be two instances of the JackMix-gui controlling one server each one showing the correct state. These two instances wouldn't need to run on the same computer. Of course the server could be on a third computer...