[LAD] mixer

fons at kokkinizita.net fons at kokkinizita.net
Sun Aug 29 11:07:57 UTC 2010


Alex, I hope you don't mind quoting part of your message on the list,
as the subject is of general interest.

Alex stone wrote offlist:

> Fons, i've read in the mailing list in the thread concerning mixers,
> that you have something you're working on.
> ...
> More than any other facet of working in software for audio/midi/vid,
> i've been frustrated and tired out by poor navigation options, and i
> don't think i'm on my own.
> The mouse is insufficent for ease, speed, and pain free day in day out
> use, and i ask you to at least consider (or not, as you decide)
> alternatives such as the one above, to make a difference in the way
> users commonly interact with this type of software.

I more than agree with this. Defining the way a user interacts with a
large software mixer is 90% of the work of writing one. Common GUI
methods just don't work for this sort of thing. 

The thing that is slowly taking some form here will observe some
GUI guidelines quite strictly, in particular there will be *NO*
repeat *NO* resizing, scrolling or moving of windows, menus will
be used sparingly and be small, and popup dialogs will be used
only for operations that can be assumed to be infrequent (mainly
setting up things, selecting and connecting plugins, etc.).

When setting up a new session, you define the resources:

- number of channel strips
- number of real groups
- number of control groups
- number of visible sections
- number of strips per section
- number of jack/alsa inputs
- number of jack/alsa outputs

These are more or less fixed afterwards, in the sense that you
can't remove any, but probably I can allow to increase these
numbers (the point here is that all snapshots taken for such
a configuration must remain valid without requiring changes
to the resources). Anyway there is no penalty (apart from a
small amount of memory used) for providing more than you need.

A _section_ is a group of strips, typically 8, 10 or 12.
Normally you should select the section size so you can have
two of them side by side, as this facilitates many operations.

For each visible section there is a control strip, which 
contains e.g. buttons to select which strips are shown.

You will have default sections, e.g. inputs 1-8, 9-16, 17-24,
etc, same for real groups and control groups. There are also
user-defined sections: these can contain copies of any strip
you want in any order you want. For example you could group
all inputs used for drums in a secion, or have a 'master'
section that contains mainly groups and maybe some solo mics.

There is some 'intelligence' in the section selection buttons,
for example, if you select to see inputs 17-24 in the right
section, you click that button (or use a kb shortcut), then
clicking again restores the previous view. Or selecting a 
section that is already visible will swap the two, etc.etc.

Each visible section is vertically divided in two, the bottom
half showing the faders, channel ID, mute, solo etc. most of
the time, while the top half can show parts of the strips, e.g.
EQ, sends or dynamics. Again this layout is configurable to some
extent, you can e.g. select to have some aux sends visible all
the time. The top part of each visible section can also be used
for plugins, metering, 'visual' panning, or whatever extra
functions that would need to be displayed.

All Jack/Alsa ports are generic, each of them can be assigned
to any function inside the mixer. That means e.g. that Jack
connections can remain fixed no matter how you 'rewire' the
mixer, and this in turn means that nothing is lost if you
connect directly to a multichannel Alsa device, e.g. a MADI
card.

The mixer will have its own plugin interface, and it will not
accept any of the existing standards. If someone wants to use
a LADSPA or LV2 I will consider porting it. Condition for this
will be the *quality* of the plugin, and nothing else.

Ciao from very hot Crete (I'll be cooling down 20m below the
water surface in a short time).

-- 
FA

There are three of them, and Alleline.




More information about the Linux-audio-dev mailing list