back to Index
SAMPLE AS_CONFIG.JSON FILE FOR AUDIOSWITCHER SERVER:
Refer to the comments in the below sample as_config file for details.
begin as_config.json
--------------------------------------------------
// Single-line comments work
/* Multi-line comments
work as well */
{
// ---------------------
// channelMapping block:
// ---------------------
// The channelMapping block maps hardware inputs and outputs to software inputs and outputs
// and defines bus amounts.
"channelMapping" : {
// ON ENABLING DELAYS AND/OR SAMPLE-RATE LEVEL-CHANGE INTERPOLATION:
// Adding ':d' after any input, bus, or output channel, or range of channels,
// will enable delays for the respective channels.
// Adding ':s' after any input, bus, or output channel, or range of channels,
// will enable sample-rate smoothing on all level changes for the respective channels.
// ON INPUT AND OUTPUT CHANNEL MAPPINGS:
// The written order of input and output channels determines it's software to hardware mapping.
//
// For example:
// "inputChannels" : ["1-5"]
// -creates 5 software input channels, assigning
// software input 1 to hardware input 1,
// software input 2 to hardware input 2, and so on.
//
// "inputChannels" : [1, 3, 5, 7]
// -create 4 software input channels, assigning
// software input 1 to hardware input 1,
// software input 2 to hardware input 3,
// software input 3 to hardware input 5,
// software input 4 to hardware input 7.
//
// You can assign the same hardware input or output to multiple software inputs or outputs
// For example:
// "outputChannels" : [1, 2, 1, 2]
// -create 4 software output channels, assigning
// software output 1 to hardware output 1,
// software output 2 to hardware output 2,
// software output 3 to hardware output 1,
// software output 4 to hardware output 2.
// ON VIRTUAL INPUTS AND OUTPUTS:
// Any input or output that contains a non-numeric character will create a 'virtual' input or output channel.
// A virtual input or output is actually a Max receive~ or send~ with the name being the symbol provided.
// When running AudioSwitcher Server as a standalone application, creating a virtual input and virtual output
// with the same name creates a signal path "loopback", passing the signal from the output back to the input.
//
// If the virtual input or output channels begins with an integer, the shortcut below is possible:
//
// "inputChannels" : ["1-10vi"]
// -creates 10 software input channels containing receive~s of 1vi through 10vi respectively.
//
// "outputChannels" : ["1-10vo"]
// -create 10 software output channels containing send~s of 1vo through 10vo respectively.
// ON BUS CHANNEL DEFINITIONS:
// Bus channels are defined more simply. Always start with 1, and specify as many as you want.
// When busChannels is set to 'null', all buses as well as the Bus Matrix will be removed from the signal flow.
// In this case, Input Masters will send directly to Output Masters via the Output Matrix,
// and all bus-related areas below, as well as bus-related subcue types, will be ignored.
"inputChannels" : ["1-16", "65-96"],
"outputChannels" : ["1-16", "65-96"],
"busChannels" : [null]
},
// ---------------------
// vGroupMapping block:
// ---------------------
// The vGroupMapping block associates Input Masters, Bus Masters, or Output Masters to various Virtual Groups.
// Virtual Group names should be integers, starting with 1.
// Only one type of master channel (input, bus, or output) may be associated to any one virtual group.
// The first element of the array specifies the type of master channel that a virtual group will control ("in", "bus", or "out").
// ON SPECIFYING CONTROLS POINTS THAT A VGROUP WILL BIND TO:
// You can explicitly specify the types of controls a virtual group will bind to: trim, level, mute, and/or solo.
// Adding ':t' after the channel type (i.e. "in:t"), will enable control over the associated input channel trims.
// Adding ':l' after the channel type (i.e. "in:l"), will enable control over the associated input channel level.
// Adding ':m' after the channel type (i.e. "in:m"), will enable control over the associated input channel mute.
// Adding ':s' after the channel type (i.e. "in:s"), will enable control over the associated input channel solo.
// Any combination of the above bindings is possible, listed in any order:
//
// For example:
// "1" : ["in:t:l:s", "1-16"]
// -vGroup 1 controls trim, level, and solo on input channels 1-16.
// "2" : ["bus:l:m", "1-16"]
// -vGroup 2 controls level and mute on bus channels 1-16.
// etc...
//
// If no control types are specified, control over all types is assumed.
// For example:
// "1" : ["in", "1-16"]
// - vGroup 1 controls trims, level, mute, and solo on input channels 1-16.
"vGroupMapping" : {
"1" : ["in:l:m:s", "1-16"],
"2" : ["in:l:m:s", "65-96"],
"3" : ["out", "1-16"],
"4" : ["out", "65-96"],
// ---------------------
// clients sub-block:
// ---------------------
// The clients sub-block defines the vGroups that will be exposed to 'AudioSwitcher Control' client software.
// Client-controlled vGroups will bind to the same control types as defined above.
"clients" : {
"vGroups" : [1, 2, 3, 4],
"vGroupNames" : ["in1", "in2", "out1", "out2"]
}
},
// ---------------------
// networkMapping block:
// ---------------------
// The networkMapping block creates and defines network i/o. Here you define network receivers and senders
// and then 'bind' those receivers and/or senders to different control points in the software.
// An OSC-style url string will be associated with each control point, both incoming and outgoing,
// according to the heirarchical block name structure as follows:
// /as/<blockname>/<subblockname>/... ending with the <value>
"networkMapping" : {
// Define as many network receivers as are necessary
"netReceivers" : {
"recv1" : { // unique receiver name
"protocol" : "tcp", // network protocol (tcp, udp, osc-udp, or multicast)
"port" : 16000 // receiving port
},
"recv2" : {
"protocol" : "udp",
"port" : 16001
},
"recv3" : {
"protocol" : "osc-udp",
"port" : 16003
},
"recv4" : {
"protocol" : "multicast",
"port" : 16004,
"ip" : "224.0.0.1" // multicast ip (expected only if protocol == multicast)
}
},
// Define as many network senders as are necessary
"netSenders" : {
"send1" : { // unique sender name
"protocol" : "osc-udp", // network protocol (tcp, udp, osc-udp, or multicast)
"ip" : "127.0.0.1", // destination ip
"port" : 21001, // sending port
// url_prefix optionally inserts a string in front of all outgoing messages.
// When set to 'null', this feature is ignored.
//
// Examples:
// if url_prefix == null, /as/vGroups/1/level -6.
// if url_prefix == /AM, /AM/as/vGroups/1/level -6.
"url_prefix" : null
}
},
// Bind network senders and receivers to various AudioSwitcher controls
"cues" : {
"receivers" : ["recv1", "recv2", "recv3", "recv4"], // list all receivers that will pass on to cues
// expects OSC structure of /as/cues <cue id>
"senders" : ["send1"] // list all senders that cues will pass on to
// sends OSC structure of /as/cues <cue id>
},
"subcues" : { // formatted like cues above
"receivers" : ["recv1", "recv2", "recv3", "recv4"],
"senders" : ["send1"],
"manual" : {
"receivers" : ["recv1", "recv2", "recv3", "recv4"],
// expects OSC structure of /as/subcues/manual <subcue command>
"senders" : ["send1"]
// sends OSC structure of /as/subcues/manual <subcue command>
}
},
"inputs" : { // formatted like vGroups below
},
"buses" : { // formatted like vGroups below
},
"outputs" : { // formatted like vGroups below
},
"vGroups" : {
"1" : { // vGroup id number
"level" : {
"receivers" : ["recv1", "recv2", "recv3", "recv4"], // list all receivers that will pass on to vGroup level
// expects OSC structure of /as/vGroups/1/level <dB>
"senders" : ["send1"] // list all senders that this vGroup level will pass on to
// sends OSC structure of /as/vGroups/1/level <dB>
},
"trim" : {
"receivers" : ["recv1", "recv2", "recv3", "recv4"],
"senders" : ["send1"]
},
"mute" : {
"receivers" : ["recv1", "recv2", "recv3", "recv4"],
"senders" : ["send1"]
},
"solo" : {
"receivers" : [],
"senders" : []
}
},
"2" : { // vGroup id number
"level" : {
"receivers" : ["recv1", "recv2", "recv3", "recv4"],
"senders" : ["send1"]
},
"trim" : {
"receivers" : ["recv1", "recv2", "recv3", "recv4"],
"senders" : ["send1"]
},
"mute" : {
"receivers" : ["recv1", "recv2", "recv3", "recv4"],
"senders" : ["send1"]
},
"solo" : {
"receivers" : [],
"senders" : []
}
},
"3" : { // vGroup id number
"level" : {
"receivers" : ["recv1", "recv2", "recv3", "recv4"],
"senders" : ["send1"]
},
"trim" : {
"receivers" : ["recv1", "recv2", "recv3", "recv4"],
"senders" : ["send1"]
},
"mute" : {
"receivers" : ["recv1", "recv2", "recv3", "recv4"],
"senders" : ["send1"]
},
"solo" : {
"receivers" : [],
"senders" : []
}
},
"4" : { // vGroup id number
"level" : {
"receivers" : ["recv1", "recv2", "recv3", "recv4"],
"senders" : ["send1"]
},
"trim" : {
"receivers" : ["recv1", "recv2", "recv3", "recv4"],
"senders" : ["send1"]
},
"mute" : {
"receivers" : ["recv1", "recv2", "recv3", "recv4"],
"senders" : ["send1"]
},
"solo" : {
"receivers" : [],
"senders" : []
}
}
},
"system_output" : { // formatted like vGroups above
"level" : {
"receivers" : ["recv1", "recv2", "recv3", "recv4"], // list all receivers that will pass on to system_output level
"senders" : ["send1"] // list all senders that system_output level will pass on to
},
"mute" : {
"receivers" : ["recv1", "recv2", "recv3", "recv4"],
"senders" : ["send1"]
}
}
},
// ---------------------
// midiMapping block:
// ---------------------
// The midiMapping block creates and defines MIDI i/o. Here you define MIDI devices and then 'bind' those devices, as well as
// specific MIDI note or control messages to different control points in the software.
"midiMapping" : {
// Define as many MIDI devices as are connected
"bcf2000" : "BCF2000 Port 1", // <unique device alias> = <actual device port name>
// ---------------------
// NOTES on cues and subcues:
// ---------------------
// For MIDI you cannot globally assign receivers and senders, like you can in networkMapping.
// Here you need to configure for each cue/subcue individually
// ex. "bcf2000" : ["ctl", 48, 127, 1, "in", "out"] // <device alias> : "ctl" <ctl number> <ctl val> <MIDI channel> <"in"> <"out">
// ex. "bcf2000" : ["note", 60, 1, "in", "out"] // <device alias> : "note" <pitch number> <MIDI channel> <"in"> <"out">
// "in" and "out" elements define how the message binds to a control point:
// "in" only == incoming message updates control point in software
// "out" only == control point update within software cause MIDI message to pass to device
// "in" and "out" == bi-directional communication... both of above are true
// Format for ctl messages in cues and subcues blocks is slightly different from ctl messages in other midiMapping blocks.
// Here a ctl value is required, functioning as a target. Only an incoming ctl value == <ctl val> will trigger the cue.
// Likewise, if output is activated, the cue will send the specified ctl value to the MIDI device.
// For note messages, any non-zero velocity value will trigger the cue. Note off messages are ignored.
"cues" : {
"1" : { // cue number
"bcf2000" : ["ctl", 92, 127, 1, "in", "out"]
// ctl number 92 with ctl value of 127 on channel 1 will trigger cue 1
// triggering cue 1 in the software causes ctl message to be sent to the specified device
},
"2" : { // cue number
"bcf2000" : ["note", 60, 1, "in", "out"]
// any note on message for note 60, channel 1, will trigger cue2
// triggering cue 2 in the software causes note message (with velocity of 127) to be sent to the specified device
}
},
"subcues" : { // formatted like cues above
},
// ---------------------
// NOTES on inputs/buses/outputs/vGroups/system_output:
// ---------------------
// All other control point bindings are defined as follows:
// ex. "bcf2000" : ["ctl", 81, 1, "in", "out"] // <device alias> = "ctl" <ctl number> <MIDI channel> <"in"> <"out">
// ex. "bcf2000" : ["note", 60, 1, "in", "out"] // <device alias> : "note" <pitch number> <MIDI channel> <"in"> <"out">
// Level and Trim bindings:
// For note messages bound to level controls, note velocity will scale the level.
// For ctl messages bound to level controls, clt value will scale the level.
// Mute and Solo bindings:
// For note messages bound to mute and solo controls, any non-zero velocity will set control to "on".
// Note off messages (i.e. velocity of zero) will set control to "off".
// For ctl messages bound to mute and solo controls, any non-zero ctl value will set control to "on".
// Ctl value of 0 will set control to "off".
"inputs" : { // formatted like vGroups below
},
"buses" : { // formatted like vGroups below
},
"outputs" : { // formatted like vGroups below
},
"vGroups" : {
"1" : { // vGroup number
"level" : {
"deviceName1" : ["ctl", 81, 1, "in", "out"]
},
"trim" : {
},
"mute" : {
},
"solo" : {
}
},
"2" : { // vGroup number
"level" : {
"deviceName1" : ["ctl", 82, 1, "in", "out"]
},
"trim" : {
},
"mute" : {
},
"solo" : {
}
},
"3" : { // vGroup number
"level" : {
"deviceName1" : ["ctl", 83, 1, "in", "out"]
},
"trim" : {
},
"mute" : {
},
"solo" : {
}
},
"4" : { // vGroup number
"level" : {
"deviceName1" : ["ctl", 84, 1, "in", "out"]
},
"trim" : {
},
"mute" : {
},
"solo" : {
}
}
},
"system_output" : { // formatted like vGroups above
"level" : {
},
"mute" : {
}
}
},
// ---------------------
// onStart block:
// ---------------------
// The onStart block controls software behavior on startup.
"onStart" : {
"callCue" : 1, // enable/disable the calling of a cue on start (default is 0)
"startDelay" : 10, // set startDelay to the value in seconds the cue will be delayed after start
"startCue" : 1, // set startCue to the cue id that will be called
"inputMonitor" : 1, // set signal level input monitoring on/off in Input Masters window (default is 1)
"busMonitor" : 1, // set signal level bus monitoring on/off in Bus Masters window (default is 1)
"outputMonitor" : 1 // set signal level output monitoring on/off in Output Masters window (default is 1)
}
}
--------------------------------------------------
end as_config.json
to AS_CUES FILE