438 lines
16 KiB
Plaintext
438 lines
16 KiB
Plaintext
|
|
! title Non Mixer User Manual
|
|
! author Jonathan Moore Liles #(email,male@tuxfamily.org)
|
|
|
|
-- Table Of Contents
|
|
|
|
: User Manual
|
|
|
|
:: The Mixer
|
|
|
|
/ Mixer
|
|
< non-mixer-complex.png
|
|
|
|
The Non-Mixer is a stand-alone audio mixer, utilizing JACK as an
|
|
audio subsystem. At the time of writing, the architecture of
|
|
Non-Mixer is unique. By making the mixer stand-alone, concepts such
|
|
as busses, sends, and inserts are eliminated, as the same goals can
|
|
be achieved by simply adding more strips to the mixer.
|
|
|
|
Start by creating a new project (menu item `Project\/New`).
|
|
|
|
/ New Project
|
|
< new-project.png
|
|
|
|
After the project has been created. Hit `a` or choose `Mixer\/Add
|
|
Strip` from the menu to add a new strip to the mixer.
|
|
|
|
::: Display Options
|
|
|
|
The display options, found in the `Options\/Display` submenu may be adjusted
|
|
to suit your needs. Set the color scheme, widget style, and other graphic
|
|
options to your liking. These options are global and affect all projects.
|
|
|
|
::: Mixer Groups
|
|
|
|
Groups serve several purposes. Firstly, they allow for some
|
|
organization of strips. Groups also allow parallel relationships of
|
|
mixer strips to be made explicit. This has important performance
|
|
implications in JACK2. Non Mixer supports an unlimited number of
|
|
groups, each of which can contain an unlimited number of mixer
|
|
strips.
|
|
|
|
:::: How to Choose Groupings
|
|
|
|
All strips in a group should be completely parallel with no feedback
|
|
loop connections. A typical group might be named 'Input' and contain
|
|
all input strips (strips that accept input from Non Timeline and
|
|
have outputs all connecting to some master bus).
|
|
|
|
To put it another way, if you have 100 inputs strips with identical
|
|
output configurations (e.g. stereo or B-Format), that all connect to
|
|
a master bus, then you have a candidate for a group.
|
|
|
|
:::: Considering JACK Overhead
|
|
|
|
JACK provides immense flexibility. But, as in most situations, that
|
|
flexibility comes with a cost. In JACK the cost is a context switch
|
|
per client. This applies /even for many clients which belong to the
|
|
same process/, as in Non Mixer. Various factors go into determining
|
|
the price of a context switch on any given system. It's not very
|
|
expensive, but it does add up. It becomes problematic in sessions
|
|
involving many clients (think 100s), each of which having a small
|
|
DSP load (often smaller than the cost of JACK's context context
|
|
switch). JACK *could* be smart enough to recognize that some clients
|
|
belong to the same process and could be executed serially without
|
|
requiring a context switch, but at the time of writing neither JACK1
|
|
nor JACK2's scheduling is that smart.
|
|
|
|
If you're mixing a normal song (couple of dozen tracks) at low
|
|
latency, this overhead will probably account for less than 1% of the
|
|
total DSP load. If you're mixing an entire orchestra at ultra-low
|
|
latency, then it might account for a quarter or more of the total
|
|
DSP load.
|
|
|
|
Groups mitigate this cost by reducing the number of JACK clients
|
|
required for a mix. Strips in a group will execute serially without
|
|
context switches or thread synchronization--reducing the total JACK
|
|
overhead. However, if you have several groups, then they may all by
|
|
run in parallel by JACK2.
|
|
|
|
A mixer which uses a single JACK client (which is basically the way
|
|
everything other than Non Mixer has been designed) is not a viable
|
|
solution by this author's definition, because such a mixer cannot be
|
|
from/to any other JACK clients without introducing an extra period
|
|
of latency.
|
|
|
|
To illustrate this point here are some figures from an actual song
|
|
session including the whole Non suite plus a sampler, a synth and an
|
|
ambisonics convolution reverb with a total of 13 strips in 4 groups
|
|
in different configurations on the same system.
|
|
|
|
JACK's DSP load figures are interpreted thus: if at a 2.7ms software
|
|
latency setting the average time a proces cycle takes to complete is
|
|
2.7ms, then the DSP load is 100%. The usable ceiling on DSP load is
|
|
80%. This is true for both JACK1 and JACK2. The difference is that
|
|
JACK2 may use all available CPU cores to execute the graph \(if
|
|
there are enough clients in parallel signal flow\).
|
|
|
|
32-bit Intel Core2 Duo @1.6Ghz -r 48000 -p 256 -n 2 (5.3ms)
|
|
|
|
[[ JACK Ver, Groups, DSP Load
|
|
[[ JACK1, N, 39%
|
|
[[ JACK1, Y, 27%
|
|
[[ JACK2, N, 24%
|
|
[[ JACK2, Y, 31%
|
|
|
|
AMD FX-8350 @ 4.2Ghz 64-bit -r 48000 -p 256 -n 2 (5.3ms)
|
|
|
|
[[ JACK Ver, Groups, DSP Load
|
|
[[ JACK1, N, 28%
|
|
[[ JACK1, Y, 12%
|
|
[[ JACK2, N, 12%
|
|
[[ JACK2, Y, 11%
|
|
|
|
AMD FX-8350 @ 4.2Ghz 64-bit -r 48000 -p 128 -n 2 (2.7ms)
|
|
|
|
[[ JACK Ver, Groups, DSP Load
|
|
[[ JACK1, N, 29%
|
|
[[ JACK1, Y, 17%
|
|
[[ JACK2, N, 17%
|
|
[[ JACK2, Y, 17%
|
|
|
|
AMD FX-8350 @ 4.2Ghz 64-bit -r 48000 -p 32 -n 2 (0.7ms)
|
|
|
|
[[ JACK Ver, Groups, DSP Load
|
|
[[ JACK1, N, x
|
|
[[ JACK1, Y, x
|
|
[[ JACK2, N, 43%
|
|
[[ JACK2, Y, 41%
|
|
|
|
As you can see, for multiprocessor systems, JACK2 clearly has an
|
|
advantage even without grouping.
|
|
|
|
Of course, results will vary depending on the system and the mix. On
|
|
the dual core system, performance actually degraded with JACK2 when
|
|
using groups--this is because the number of parallel flows that
|
|
JACK2 detected was reduced and the second core was being under
|
|
utilized. Similarly, the performance of the 8-core AMD system
|
|
doesn't seem that great even in the ungrouped mode--this is because
|
|
the DSP load of each individual client is around the same as the
|
|
cost of the context switching. It's a wash either way (if each strip
|
|
had more or more complex modules on it, then the ungrouped mode
|
|
would probably perform better). Since JACK1 cannot take advantage of
|
|
more than 1 CPU core, there is no benefit to parallelism and grouped
|
|
mode always outperforms ungrouped mode.
|
|
|
|
So, for maximum capacity the combination of a multicore CPU with
|
|
JACK2 and mixer groups is best.
|
|
|
|
# All strips in a group *MUST* have the same output configuration. All
|
|
# outputs will be mixed together by identity. That is, the 'AUX \(A\)'
|
|
# outputs of each strip will be mixed together into a single 'AUX \(A\)'
|
|
# output of the group. A strip within a group whose output
|
|
# configuration differs from the group configuration will be marked as
|
|
# invalid and will not be executed.
|
|
|
|
:::: Creating a New Group
|
|
|
|
Groups can be created by selecting the group dropdown on any mixer
|
|
strip and choosing 'New Group'. A window will popup asking for a
|
|
group name. Group names must be unique. The group will then be
|
|
created and the selected strip added to it.
|
|
|
|
:::: Adding a Strip to an Existing Group
|
|
|
|
To add a strip to an existing group, simply select a group name from
|
|
the group dropdown on the strip.
|
|
|
|
:::: Removing a Strip from a Group
|
|
|
|
Select '---' from the group dropdown. The strip will be removed from
|
|
the group and will run in an independent JACK client.
|
|
|
|
:::: Removing a Group
|
|
|
|
Groups are destroyed automatically as soon as they contain zero
|
|
strips.
|
|
|
|
::: Mixer Strips
|
|
|
|
/ Mixer Strip
|
|
< single-strip.png
|
|
|
|
Each mixer strip has a name and color, each of which may be defined
|
|
by the user. Names, but not colors, must be unique. In addition,
|
|
each strip has controls to move it left or right (the arrows) in the
|
|
display and to remove it entirely (the 'X').
|
|
|
|
Strips start out in /narrow/ mode, with the /fader/ view
|
|
enabled. Click the desired button to toggle the mode or view.
|
|
|
|
Each strip has a context menu which lists the available options
|
|
and their associated key-bindings. To bring up the context menu, `Right
|
|
|
|
The fader view comprises a large gain control and digital peak meter
|
|
indicator. These are automatically connected to the default gain and
|
|
meter modules of the strip's signal chain.
|
|
|
|
To see how an audio signal traveling through this strip will be
|
|
processed, switch to its /signal/ view.
|
|
|
|
:::: Navigation
|
|
|
|
A strip is focused when you click on it. Focus can be moved among
|
|
strips with the `Tab` and `Shift-Tab` keys.
|
|
|
|
:::: Control
|
|
|
|
The focused strip can be moved in the display order via the `[` and
|
|
`]` keys. `Delete` removes a strip (with confirmation dialog). `n`
|
|
and `w` set the focused strip's width to /narrow/ or /wide/,
|
|
respectively, and `f` and `s` switch between /fader/ and /signal/
|
|
views. The strip's context menu can be invoked without the mouse by
|
|
hitting the `Menu` key (assuming your keyboard has one).
|
|
|
|
:::: Signal Chain
|
|
|
|
The signal chain view of a mixer strip provides a way to view and
|
|
manipulate the signal processing of a mixer strip.
|
|
|
|
::::: Modules
|
|
|
|
/ Modules
|
|
< modules.png
|
|
|
|
All signal processing in Non Mixer occurs in /Modules/. Modules are
|
|
signal processing abstractions providing ports for audio and control
|
|
I\/O and, in addition, some simple user interface. Sink and source
|
|
modules carry audio out of and into JACK.
|
|
|
|
Modules are displayed as named blocks. Some modules (e.g. the Meter
|
|
module) may have additional GUI components.
|
|
|
|
Each module has zero or more audio I\/O ports and zero or more
|
|
control ports. Audio routing between modules is handled
|
|
automatically. Modules with mono audio configurations (one channel
|
|
in, one channel out) can be automatically adjusted to support any
|
|
number of discrete channels. Modules with more (related) channels,
|
|
however, introduce restrictions on the order in which modules can be
|
|
chained.
|
|
|
|
An indicator in the upper left-hand corner of each module block
|
|
indicates whether the module has any parameters bound to controls.
|
|
|
|
Non Mixer has several built-in modules. They are:
|
|
|
|
= JACK
|
|
= Performs JACK I\/O
|
|
= Gain
|
|
= Applies gain in dB
|
|
= Meter
|
|
= Digital Peak Meter
|
|
= Mono Pan
|
|
= Performs intensity panning of a mono signal into a stereo signal.
|
|
= Plugin
|
|
= Hosts a LADSPA plugin
|
|
|
|
:::::: OSC Control
|
|
|
|
The input parameters of all modules are controllable via OSC,
|
|
regardless of whether the parameter is set as controllable.
|
|
|
|
The format of the automatically generated OSC path names is as follows:
|
|
|
|
> /strip/[STRIP_NAME]/[MODULE_NAME]/[PARAMETER_NAME]
|
|
|
|
The UDP port that the OSC server binds to can be set by providing
|
|
the `--osc-port` command-line option. Without this option, a random
|
|
port will be bound automatically (the exact OSC URL will always be
|
|
printed to the console as a line beginning with "OSC: ").
|
|
|
|
The default path accepts a float value between 0.0 and 1.0 (a
|
|
Control Voltage like signal) which will be automatically scaled to
|
|
the allowable range of the control.
|
|
|
|
A path ending in \/unscaled is also available, which accepts exact values,
|
|
which will be clamped to the allowable range. For example:
|
|
|
|
> /strip/[STRIP_NAME]/[MODULE_NAME]/[PARAMETER_NAME]/unscaled
|
|
|
|
If same module\/plugin is used twice in a signal chain
|
|
(e.g. multiple Gain stages), then a position dependent sequence
|
|
number will be appended to the module name. For example, a path
|
|
might look like the following:
|
|
|
|
> /strip/Foo/Gain.1/Gain_(dB)
|
|
|
|
For the second instance of the Gain module on the strip named 'Foo'.
|
|
|
|
Non-DAW accesses these same signals via a more advanced signal
|
|
routing layer on top of OSC. Any module parameter is easily
|
|
controlled via Control Sequences in Non-DAW without the need to
|
|
specify an OSC URL.
|
|
|
|
:::::: Manipulation
|
|
|
|
Left-clicking on a module brings up a Module Parameter Editor window
|
|
for the selected module.
|
|
|
|
Right-clicking on a module brings up a context menu allowing you
|
|
manipulate the module, as well as to pick a new module to insert
|
|
before the selected one in the chain.
|
|
|
|
Middle-clicking on a module toggles its activation state (the audio
|
|
signal will bypass inactive modules).
|
|
|
|
Control+Right-clicking on a module causes it to be removed from the
|
|
chain (modules added by default cannot be removed).
|
|
|
|
The focused module may also be controlled via the keyboard. `Menu`
|
|
brings up the context menu for the focused module. `Space` opens the
|
|
module parameter editor, `b` toggles the bypassed state, and
|
|
`Delete` removes the module from the chain (without confirmation!).
|
|
`Control-X`, `Control-C` and `Control-V`, cut, copy, and paste
|
|
modules, respectively. Modules may be copied within or across chain
|
|
boundaries. The normal module I\/O constraints also apply to pasted
|
|
modules.
|
|
|
|
:::::: Module Parameter Editor
|
|
|
|
/ Module Parameter Editor
|
|
< gverb-parameters-knobs.png
|
|
|
|
The Module Parameter Editor is used to alter the values of a
|
|
module's parameters, and in addition, to bind its parameters to
|
|
controls. A menu button in the upper left-hand corner allows you to
|
|
select between knob, vertical slider and horizontal slider controls.
|
|
|
|
/ Horizontal Sliders
|
|
< gverb-parameters-hsliders.png
|
|
|
|
/ Vertical Sliders
|
|
< gverb-parameters-vsliders.png
|
|
|
|
Underneath each control is a bind button. Clicking adds a new
|
|
control to the chain's /Controls/ view and binds it to the parameter
|
|
in question. For simplicity, only one control at a time may be bound
|
|
to a given parameter.
|
|
|
|
:::::: Controls
|
|
|
|
/ Control View
|
|
< controls.png
|
|
|
|
The control view of a chain groups together all of the controls
|
|
bound to parameters of modules in that chain. The default mode of
|
|
controls is /Manual/. Right click on a control to bring up a menu
|
|
which will allow you to select one of the available control I\/O
|
|
methods to use. When /Control Voltage/ (CV) is selected, a CV input
|
|
port will be created on the containing mixer strip's JACK
|
|
client. The control will now accept values from that input. A
|
|
control bound and configured in this way can then be connected to
|
|
the output of a Non-DAW control sequence using your favorite
|
|
connection manager.
|
|
|
|
{ NOTE:
|
|
{ All knob and slider controls respond to mousewheel
|
|
{ events. Hold down the `Ctrl` key while scrolling the mousewheel to
|
|
{ achieve finer resolution.
|
|
|
|
::::::: Control Voltages
|
|
|
|
The control voltage concept should be familiar to anyone who has
|
|
experience with analog modular synthesizers. MIDI, while having
|
|
definite advantages in many respects, multiplexes control data in
|
|
such a way as to make connecting one MIDI control to a parameter
|
|
involve a significant inconvenience, usually requiring the
|
|
adjustment of settings on both ends of the connection in order to
|
|
separate the control data streams.
|
|
|
|
Control Voltages, on the other hand, provide a simple 1:1 source to
|
|
sink relationship and offer much higher resolution, both in time and
|
|
value, than can be natively expressed through MIDI. The chief
|
|
advantage of CV in the context of Non-DAW is the ease with which an
|
|
control sequence can be connected to a mixer module parameter. If
|
|
you have a MIDI controller that you'd like to use to control
|
|
parameters of Non-Mixer, consider /jm2cv/, a JACK MIDI to Control
|
|
Voltage daemon which was written by Peter Nelson specifically for
|
|
use with Non-Mixer. jm2cv can be acquired by:
|
|
|
|
> git clone git://fuzzle.org/jm2cv.git
|
|
|
|
|
|
{ NOTE:
|
|
{ The use of Control Signals (OSC) should be preferred for most types
|
|
{ of parameter automation, as LADSPA plugins are incapable of
|
|
{ processing Control Voltage signals at full audio resolution anyway.
|
|
|
|
:::::: Spatialization
|
|
|
|
/ Spatialization Control on a Strip
|
|
< spatialization-on-strip.png
|
|
|
|
Non-Mixer supports Ambisonic spatialization via the excellent amb-\*
|
|
LADSPA plugin set and others. Whenever a LADSPA plugin is added to a
|
|
strip whose set of parameters include parameters named Azimuth and
|
|
Elevation, Non-Mixer will detect this and automatically attach a
|
|
Spatializer control to these parameters. The Spatializer will be
|
|
displayed at the bottom of the mixer strip. A larger version of the
|
|
control may also be found in the Module Parameter Editor.
|
|
|
|
/ Larger Spatialization Control
|
|
< spatialization-in-mpe.png
|
|
|
|
The spatialization control may be visualized as moving the sound
|
|
source across the surface of a hemispherical dome enclosing the
|
|
listener.
|
|
|
|
The output of the spatializing plugin may be routed into a decoding
|
|
plugin following it the same strip or, more usefully, the output of
|
|
a number of Ambisonic panning plugins on different strips may be
|
|
routed (through JACK) into a single master decoder instance on a
|
|
final strip.
|
|
|
|
::: Projects
|
|
|
|
A Non-Mixer project is a directory where Non-Mixer keeps the strip
|
|
settings, project specific settings, and some meta-data. A project
|
|
is completely self-contained. You can rename a project as simply as:
|
|
|
|
> $ mv Project-A Project-B
|
|
|
|
:::: JACK I/O
|
|
|
|
Each mixer strip is presented as a separate JACK "client". This
|
|
helps to avoid the necessity of internally duplicating JACK's
|
|
routing logic and, with JACK2, permits the possibility of parallel
|
|
execution of mixer strip signal chains.
|
|
|
|
The JACK client name of each strip will correspond to the name of the strip.
|
|
|
|
{ NOTE:
|
|
{ The JACK API makes implementing this far more difficult and kludgey than it should have to be.
|
|
{ Please petition your local JACK developer to accept jack_client_set_name() into the API.
|
|
|
|
/ Patchage
|
|
< non-mixer-and-non-daw-in-patchage.png
|