non/mixer/doc/MANUAL.mu

! 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