MixerChannelDef
Contains the definition for a control structure for a MixerChannel.
Every MixerChannel must have a definition. Default definitions are provided for stereo and mono MixerChannels.
This provides better support for multichannel applications. The MixerChannel's structure depends on the spatialization technique used--therefore, the user is encouraged to design her own channel definitions as needed.
MixerChannelDef objects are stored in the global Library, under the keys (\mixerdefs, myMixerDefName).
The format for mixer controls has changed as of Feb. 23, 2008.
Creation:
*new(name, inChannels, outChannels, basicFader, postSendReadyFader, controls, guidef)
Creates a new instance and stores it in the library.
name: The name by which the definition will be retrieved. The standard format, to allow backward-compatibility with MixerChannel's default new method, is 'mix' ++ inChannels ++ 'x' ++ outChannels, e.g., 'mix1x2' for a mono-to-stereo channel. You may, however, use any name you like, and create the mixer channels using MixerChannel.newFromDef().
inChannels: The number of channels to be input into the fader.
outChannels: The number of channels the fader will output.
fader: A synthdef that defines the fader operation. See the example below.
controls: An IdentityDictionary of specifications for mixer controls.
guidef: The MixerGUIDef object that defines how a mixer using this template will appear in a MixingBoard. See the MixerGUIDef help file. The guidef may be set after creation by myDef.guidef = myMixerGUIDef;
The controls dictionary lists the name by which each control will be accessed, and gives its default value and ControlSpec, e.g. (name: spec, name1: spec1) where spec may be any of the following:
number -- The control's default value. The default ControlSpec (0..1, linear) is assumed.
(default: number, spec: aControlSpec) -- Specify a ControlSpec and override its default.
aControlSpec -- Anything that responds to asSpec. The spec's default will be the MixerControl's starting value.
The default MixerChannelDefs use this as the controls dictionary:
(level: (spec: \amp, value: 0.75),
pan: \bipolar)
Accessing:
*at(name)
Retrieves the mixer definition with the given name from the global library.
Example:
Following is the definition for the default mono-to-stereo mixer channel.
MixerChannelDef(\mix1x2, 1, 2,
fader: SynthDef("mixers/Mxb1x2", {
arg busin, busout, level, pan;
var in, out;
in = In.ar(busin, 1);
out = Pan2.ar(in, pan, level);
// so that mixerchan bus can be used as postsendbus
ReplaceOut.ar(busin, out);
Out.ar(busout, out);
}),
controls: ( level: (spec: \amp, value: 0.75),
pan: \bipolar)
);
The synthdefs must have two arguments at minimum: busin and busout. MixerChannel manages these inputs internally. The other synthdefs inputs should correspond to the entries in the controls dictionary.
Note that there are two output UGens. Out.ar(busout, out) mixes the output signal on the target bus, while the ReplaceOut retains a copy of the processed signal on the channel's own bus. Whatever your fader control structure and whatever operations take place in the fader synthdefs, you must include both output UGens. If you don't, post-fader sends, mixer recording, MixerScope, PeakMonitor and perhaps other features will not work.
The control names (the keys of the dictionary) should correspond to the synthdef argument names except busin and busout. If they don't, the controls will not be mapped correctly and your MixerChannel won't work.