Unofficial x32 Osc Remote Protocol
Unofficial x32 Osc Remote Protocol
This document regroups data contained in version 1.01 of the OSC protocol for the X32 family of products
released by Behringer in Oct. 2012, and a large number of additional OSC messages for communicating
with the X32, their syntax and use, along with practical examples and explanations as to how and in
which context they should be used. This document should also apply to M32, a product from Midas, very
similar to X32.
Behringer is not associated to the redaction of this document and no support will be provided by the
company.
I have tried to make the information contained here as accurate as possible. A few areas are still prone to
inaccuracies or uncertainties as to how to best use them. Please do not hesitate to provide feedback on
the X32 user forum on errors or inaccuracies. They will be corrected in futures updates.
I want to thank X32 forums well known Paul Vannatto for his invaluable support during the redaction, his
generous time and his advice in reviewing early versions of this document.
As you read through this document, you may like a “hands on” experience with OSC commands, it is
recommend you use a utility to send/read commands to/from the X32. Such utilities ensure the
commands will be properly formatted and offer better support for reading dat back from X32/M32.
X32_Command1 is a terminal based utility running on Windows, Linux, OSX and Raspberry
platforms, supporting batch and interactive modes, timed commands, multi-tag parameters, and
also scenes, snippets, and presets. Download it from
https://sites.google.com/site/patrickmaillot/x32.
X32 Live Toolbox2 is a GUI based utility running in Windows, Linux and OSX. It also offers
additional features such as EQ copy. Download it from
http://sourceforge.net/projects/x32livetoolbox/
With my purchase of an X32 digital mixer and as I started to find out more about OSC and ways to
achieve more with the X32 via programs, I have spent quite some time designing several applications for
the M/X32 family of systems. Late 2015, I decided to open-source the code for the programs I wrote.
These can be found at https://bitbucket.org/pmaillot/pmaillot-git or https://github.com/pmaillot/X32-
Behringer. I’ll continue to add programs as I finally “clean” them before publishing.
Patrick-Gilles Maillot
1
X32_Command: © 2014-2015 Patrick-Gilles Maillot
2
X32 Live Toolbox: © 2014-2015 Paul Vannatto
Contents
DESCRIPTION ...................................................................................................................................................... 5
Client initiated messages (client X32 console) ........................................................................................... 6
Multiple client management .......................................................................................................................... 7
Server replies or server initiated messages (X32 console client)............................................................... 8
X32/M32 OSC Protocol Parameters ............................................................................................................... 8
Type rules (Get/Set parameter) and data formatting .................................................................................... 9
Responses from X32/M32: .......................................................................................................................10
Special considerations for the enum type. ...............................................................................................10
Meter requests .................................................................................................................................................12
List of all Meter IDs: ......................................................................................................................................12
meters/0 ...............................................................................................................................................12
meters/1 ...............................................................................................................................................13
meters/2 ...............................................................................................................................................13
meters/3 ...............................................................................................................................................13
meters/4 ...............................................................................................................................................13
meters/5 <chn_meter_id> <grp_meter_id> .........................................................................13
meters/6 <channel_id> ................................................................................................................14
meters/7 ...............................................................................................................................................14
meters/8 ...............................................................................................................................................14
meters/9 ...............................................................................................................................................14
meters/10 ............................................................................................................................................14
meters/11 ............................................................................................................................................14
meters/12 ............................................................................................................................................14
meters/13 ............................................................................................................................................14
meters/14 ............................................................................................................................................14
meters/15 ............................................................................................................................................14
X32/M32 Client communications .................................................................................................................16
Configuration (/config) data .....................................................................................................................16
Channel (/ch) data ....................................................................................................................................20
Aux In (/auxin) data ..................................................................................................................................23
FX Return (/fxrtn) data .............................................................................................................................25
Bus (/bus) data .........................................................................................................................................26
Matrix (/mtx) data ....................................................................................................................................28
Main Stereo (/main/st) data.....................................................................................................................30
Main Mono (/main/m) data .....................................................................................................................32
DCA groups (/dca) data ............................................................................................................................34
Effects (/fx) data .......................................................................................................................................35
Output sets (/output) data .......................................................................................................................36
Headamp (/headamp) data ......................................................................................................................38
Inserts (/-insert) data................................................................................................................................38
Show, Cue, Scene, Snippet, and Preset Management .................................................................................39
Shows, Cues, Scenes, Snippets (/showdump, /-show) .............................................................................39
Presets (/-libs)...........................................................................................................................................39
X32 & M32 are using a communication protocol that is compatible to standard OSC with some MUSIC Group
specific extensions (e.g. parameter enquiry, subscriptions). OSC packets are received on UDP port 10023 and
replies are sent back to the requester's IP/port3.
In the following, the X32/M32 (rack, console) is also called server, and a connected device or application is
typically called client. Connections to the server take place over Ethernet network, UDP port 10023. The server
replies on the UDP port used by the client when establishing communication.
Due to the nature of UDP communications, buffer overflows situations should be taken into consideration. A
typical example of critical situation is sending a large number of /node requests to an X32 connected to a
2.4GHz/54Mb/s WIFI router. The 100Mb/s link between the X32 and the router will enable the X32 to send a lot
more data than the router will be able to propagate via WIFI to its connected clients, with possibly missing data at
the client level due to UDP packets being silently lost by the router. Indeed no errors will be reported in UDP for
loss of data.
There are different modes of operation for the X32/M32 to communicate OSC protocol:
• Immediate: a client such as a network connected tablet or PC application sends a request with or without
parameters and the server immediately acts or replies with the respective data.
Note: a single request from the client can result in several replies from the server (this is typically the case
with /showdump)
• Deferred: a client such as a network connected tablet or PC application sends a specific request without
parameters (/xremote). When changes take place either from the server UI or from a connected client,
several notification messages are returned for a period of time, until a timeout is reached.
Note: a single action at the server can result in several messages from the server.
X32 internal variables are driving the behavior of the console. These can be read (Get) or written (Set) with OSC
commands mapping variables with addressable parameters. Parameters are internally organized in logical groups,
I will refer to as “X32nodes”. X32nodes are widely used in scenes, snippets, and presets. They can be read using
the /node command presented later in this document4. X32nodes can be written or sent to X32 using the /
command, also presented later in this document. Parameters of an X32node can also be updated as a group
(complete or not) by using the combined (multiple Type Tags) form of OSC Set commands.
The list of <OSC Address Pattern> parameters commands, enabling an interactive control of all features of the
X32/M32 mixer family is listed below:
3
See Appendix for an example of communication program
4
See chapter “X32nodes (/node & /) commands”
A single X32 can manage updates from and to several simultaneous UDP clients.
In order to keep being synchronized with changes happening at the X32 level, either from a change at the desk
itself or requested by another remote client, each client must register for receiving updates from the X32. This is
possible with the /xremote command. After sending /xremote, the X32 will update the client with changes
taking place in the X32, such as fader movements, bank change, and screen update. Some changes or user actions
will not be reported as they do not directly affect the connected clients.
Registering for desk updates with a /xremote command maintains updates for approximately 10 seconds, after
which a new /xremote command should be sent by the client to keep the updating process alive.
Please refer to the examples given at the end of this document on how to use /xremote in client applications
(X32Saver.c (Linux or Windows), X32 data echo in Go)
Note: other commands such as /subscribe, /formatsubscribe, /batchsubscribe also enable receiving
regular updates form the server; details are available in the paragraph “Subscribing to X32/M32 Updates”.
Info request /info <string server_version> Returns names and version numbers, e.g. :
<string server_name> /info~~~,ssss~~~V2.05~~~osc-
<string console_model> server~~X32C~~2.08~~~~
<string console_version> (~ stands for null character)
Status request /status <string state> Returns console status and IP , e.g. :
<string IP_address > /status~,sss~~~~active~~192.
<string server_name > 168.0.64~~~~osc-server~~
(~ stands for null character)
Console <OSC Address <string | int | float> If /xremote is active, the X32 console echoes the
changes Pattern> value of a console parameter in response to a set
command from another client or X32 parameter
change, e.g.
/-stat/solosw/01~~~~,i~~[1]
/-stat/solo~,i~~[1]
/ch/01/mix/01/pan ,f <float>
The table below lists the type and associated characteristics of parameters used for <OSC Address Pattern> and
X32node commands.
• all parameters must be big-endian and 4-byte aligned/padded, as per OSC specification.
• padding is done with null bytes.
• float parameters must be in range 0.0 – 1.0, e.g:
0.0 0x00000000 (big-endian)
0.5 0x3f000000 (big-endian)
1.0 0x3f800000 (big-endian)
• integer and float parameters are signed 32-bit values.
• strings must be null-terminated.
• enum parameters can be sent as strings or integers (see below).
• boolean parameters will map to enum type {OFF, ON} (or OSC integer {0, 1})
• blobs (arbitrary binary data) follow specific rules depending on the section they apply to (see later in this
document)
An OSC command typically consists in a 4-byte padded OSC message, followed by a 4-byte padded type tag string,
and if a non-empty type tag string is present, one or more 4-byte aligned/padded arguments.
The OSC 1.0 specification mentions some older implementations of OSC may omit the OSC type tag string. […] OSC
implementations should be robust in the case of a missing OSC type tag string, which is the case of X32/M32
systems.
Examples:
A simple OSC command, with no tag string and no arguments:
/info~~~,~~~ correct format (OSC 1.0 compliant) command
And the reply from different X32 systems (X32 FW and SW versions may vary):
X32 Standard: /info~~~,ssss~~~V2.05~~~osc-server~~X32~2.12~~~~
X32 Rack: /info~~~,ssss~~~V2.05~~~osc-server~~X32RACK~2.12~~~~
TBV:
X32 Compact: /info~~~,ssss~~~V2.05~~~osc-server~~X32COMPACT~~2.12~~~~
X32 Producer: /info~~~,ssss~~~V2.05~~~osc-server~~X32PRODUCER~2.12~~~~
X32 Core: /info~~~,ssss~~~V2.05~~~osc-server~~X32CORE~2.12~~~~
An OSC command with a more complex tag string and multiple arguments:6
/ch/01/eq/1 ,ifff [2] [0.265] [0.5] [0.4648]
5
Please refer to http:// http://opensoundcontrol.org/ for further information on the OSC full spec.
6
In the case of X32/M32 “node” commands, this only applies to combinations of int or floats (,i or ,f); strings (,s) sent to
a node address (rather than a parameter address) are interpreted differently (internally used for X32-edit). As a result of such
choice, the command /ch/[01..32]/config ,siii [name] [1] [3] [1], although semantically correct and OSC compliant, does not
work on X32/M32 when it does work fine on XAIR series.
Where 3eedfa44 is the hex for a 32bit float, big endian representation of 0.4648, and
where ~ stands for null character (\0)
Sending to port 10023 the UDP request /status~,~~~ will be replied with 52 bytes back to the sender’s UDP
port:
/status~,sss~~~~active~~192.168.0.64~~~~osc-server~~
Sending to port 10023 the UDP request /fx/4/par/23~~~~,~~~ will be replied with 24 bytes back to the
sender’s UDP port, for example:
/fx/4/par/23~~~~,f~~[float 0.5]
or, in hexadecimal:
2f66782f342f7061722f3233000000002c6600003f000000
The setting “GATE” can be enabled for channel 01 by sending either one of the following:
/ch/01/gate/mode~~~~,s~~GATE~~~~
or
/ch/01/gate/mode~~~~,i~~[3]
in hexadecimal:
2f63682f30312f676174652f6d6f6465000000002c7300004741544500000000
or
2f63682f30312f676174652f6d6f6465000000002c69000000000003
Please note this only applies to the “enum” type; for example it does not apply to the key source setting of
dynamics which only accepts an “int” value between 0 and 64.
/ch/[01…32]/dyn/keysrc
Note: The X32/M32 only considers a subset of discrete values of the floating point range [0.0, 1.0], depending on
the destination the float value applies to; a number of steps determines the values “known” by X32/M32.
This is particularly useful to convert text to float values when X32/M32 returns data in the form of text, such as
with the /node commands used in scene and snippets, or when having to send data as text, for example in the
case of OSC data sent over MIDI Sysex commands7.
Tables in appendix to this document list common cases for frequencies, levels, etc. following a log scale.
7
See appendix for section on sending OSC commands over MIDI sysex messages
The /meters OSC command is used for obtaining Meter data, or to get a specific set of meter values. Update
cycle frequency for meter data is 50 ms, and may be variable according to console’s ability to fulfill requests.
Timeout is 10 seconds.
Meter values are returned as floats in the range 0.0 – 1.0, representing the linear audio level (digital 0 – full-scale;
internal headroom allows for values up to 8.0 (+18 dBfs)).
The data returned by the X32/M32 server for /meters is an OSC-blob, an abitrary set of binary data. As a result,
the format differs from what is typically returned by the X32/M32. This is essentially for efficiency/performance
reasons. The format of a returned blob is as follows:
<meter id>: see possible values below (padded with null bytes)
,b~~: indicates a blob format, padded with null bytes
<int1>: the length of the blob in bytes, 32 bits big-endian coded
<int2>: the number of <nativefloats>, 32 bits little-endian coded
<nativefloat>: data or meter value(s), 32 bits floats, little-endian coded
Example:
The following meter request is sent to an X32/M32 server:
/meters~,si~/meters/6~~~16
Where ~ stands for null character, and “16” is actually sent as a big-endian 32bit integer, i.e. 0x00000010.
2f6d6574657273002c7369002f6d65746572732f3600000000000010
/ m e t e r s ~ , s i ~ / m e t e r s / 6 ~ ~ ~[ 16]
The X32/M32 server will returns for approximately 10 seconds and approximately every 50ms the 4 channel strip
meters (pre-fade, gate, dyn gain reduction and post-fade) values of channel 17, in a single blob, as shown in the
reply message below:
2f6d65746572732f360000002c6200000000001404000000fd1d2137fdff7f3f0000803f6ebbd534
/ m e t e r s / 6 ~ ~ ~ , b ~ ~[ int1 ][ int2 ][nfloat][nfloat][nfloat][nfloat]
/meters/0
Returns meter values from the METERS page (not used for X32-Edit):
32 input channels
8 aux returns
4x2 st fx returns
16 bus masters
6 matrixes
returns 70 float values as single binary blob
/meters/2
Returns meter values from the METERS/mix bus page:
16 bus masters
6 matrixes
2 main LR
1 mono M/C
16 bus master dynamics gain reductions
6 matrix dynamics gain reductions
1 main LR dynamics gain reduction
1 mono M/C dynamics gain reduction
returns 49 float values as a single OSC blob
/meters/3
Returns meter values from the METERS/aux/fx page:
6 aux sends
8 aux returns
4x2 st fx returns
returns 22 float values as a single OSC blob
/meters/4
Returns meter values from the METERS/in/out page:
32 input channels
8 aux returns
16 outputs
16 P16 ultranet outputs
6 aux sends
2 digital AES/EBU out
2 monitor outputs
returns 82 float values as a single OSC blob
/meters/7
Returns meter values from the Bus Send meters:
16 bus send meters
returns 16 float values (from Bus sends 1-16) as a single OSC blob
/meters/8
Returns meter values from Matrix Send meters:
6 Matrix send meters
returns 6 float values (from Matrix sends 1-6) as a single OSC blob
/meters/9
Returns meter values from Effect Send and Return meters:
2 effects send and 2 effects return meters for each FX slot (8 slots)
returns 32 float values (4 x FX1, 4 x FX2, … 4 x FX8) as a single OSC blob
/meters/10
Used for some Effects, for example Dual DeEsser, Stereo DeEsser, Stereo Fair Compressor
returns 32 float values
/meters/11
Returns meter values from the Monitor pages
returns 5 float values (Mon Left, Mon Right, Talk A/B level, Threshold/GR, Osc Tone level) as a single OSC
blob
/meters/12
Returns meter values from the Recorder page
returns 4 float values (RecInput L, RecInput R, Playback L, Playback R) as a single OSC blob
/meters/13
Details TBD
returns 48 float values
/meters/14
Used for some Effects, for example Precision Limiter, Combinator, Stereo Fair Compressor
returns 80 float values
/meters/15
Used for RTA and some Effects, for example Dual GEQ, Stereo GEQ
returns 50 32bits values as a single OSC blob.
The 32bits values returned are representing 100 successive little endian coded short ints, in the range
[0x8000, 0x0000]; each short int value provides a floating point RTA db level in the range [-128.0, 0.0],
by dividing the short int (converted to float) by 256.0.
For example a 32bit value of 008000c0 will represent two values, the first one being 0x8000 (or -128.0
after conversion), and the second one being 0xc000 (or -64.0 after conversion). Similarly, a 32bits value
of 40e0ffff will represent two successive RTA values of -31.75db and -0.004db, respectively.
The 100 short ints (or RTA db values) correspond to frequencies listed in the table (values in Hz) below,
respectively.
20 21 22 24 26 28 30 32 34 36
39 42 45 48 52 55 59 63 68 73
78 84 90 96 103 110 118 127 136 146
156 167 179 192 206 221 237 254 272 292
313 335 359 385 412 442 474 508 544 583
625 670 718 769 825 884 947 1.02K 1.09K 1.17K
1.25K 1.34K 1.44K 1.54K 1.65K 1.77K 1.89K 2.03K 2.18K 2.33K
2.50K 2.68K 2.87K 3.08K 3.30K 3.54K 3.79K 4.06K 4.35K 4.67K
5.00K 5.36K 5.74K 6.16K 6.60K 7.07K 7.58K 8.12K 8.71K 9.33K
10.00K 10.72K 11.49K 12.31K 13.20K 14.14K 15.16K 16.25K 17.41K 18.66K
The following tables (a long list) describe communication messages that can be initiated by the client, by the
server as a response to the client or as update data.
8
See Appendix section for detailed values
9
See Appendix section for detailed values
/config/routing/CARD/1-8
/config/routing/CARD/9-16
/config/routing/CARD/17-24
/config/routing/CARD/25-32
10
See Appendix section for detailed values
11
See Appendix section for detailed values
12
See Appendix section for detailed values
13
See Appendix section for detailed values
14
This command is available starting with FW 2.10
15
This command is available starting with FW 2.10
16
This command is available starting with FW 2.10
17
This command is available starting with FW 2.10
18
This command is available starting with FW 2.10
effects fx[5…8]
/fx/[5…8]/type enum int [0…33] representing
{GEQ2, GEQ, TEQ2, TEQ, DES2, DES, P1A, P1A2,
PQ5, PQ5S, WAVD, LIM, FAC, FAC1M, FAC2, LEC,
LEC2, ULC, ULC2, ENH2, ENH, EXC2, EXC, IMG, EDI,
SON, AMP2, AMP, DRV2, DRV, PHAS, FILT, PAN,
SUB}20
/fx/[5…8]/par/[01…64] linf/logf Up to 64 parameters, depending on selected effect type. See
Effect Parameters Chapter
19
See Appendix for table of enum/name/type
20
See Appendix for table of enum/name/type
21
This command is available starting with FW 2.12
22
This command is available starting with FW 2.12
23
This command is available starting with FW 2.12
24
This command is available starting with FW 2.12
25
/node ,s –insert reports 22 inserts in the following order: fx1L, fx1R, fx2L, …, fx8R, aux1, …, aux6
This section covers the /showdump, /-show, /-libs, /add, /copy, /save, /load, /delete,
/rename, and /-undo commands typically used to manage Show, Cues, Scenes, Snippets and Presets.
X32/M32 systems can manage 100 different Scenes and 100 different Snippets, each numbered 0 to 99. Scenes
files consist in a large collection of data resulting from and with a similar format as the output of /node
commands. Snippets are similar in structure but applied to smaller sets, with finer granularity to what can be
controlled (saved or restored).
When restoring Scenes, a series of flags will enable protection of existing (already in place) parameters. These
flags are listed as “Scene Safes” and address rather large groups of elements.
A different set of flags enables what is actually saved with Snippets, controlling the affected areas in a much finer
manner.
A complete list of elements found in Scenes and Snippet files is given in appendix of this document.
Presets (/-libs)
The X32/M32 familly of products can accept 3 different types of presets: Channel, Effects and Routing.
Presets are files which can be loaded in one of the 3 x 100 preset memory slots of the X32/M32. They consist of
X32node like commands dedicated to the domain they address.
• Channel presets contain /node commands used for X32/M32 channels (i.e. beginning with
[/]ch/[01…32]/…)
• Routing presets contain /node commands used for X32/M32 Routing (i.e. stating with
[/]config/routing/…)
• Effects presets contain /node commands used for X32/M32 Effects (i.e. beginning with [/]fx/[1…8]/…)
In the case of Channels and Effects, the corresponding header is not present as Channel and Effect presets are not
dedicated to specific channels or effect slots.
A complete list of elements found in Channel, Effects and Routing preset files is given in appendix of this
document.
Shows, Scenes, Snippets and Presets can be saved to and retrieved from memory or the USB drive with
appropriate controls available on the different systems. They can also be controlled with the OSC commands
below.
The /showdump command can be a way to read from the server all information related to Cues, Scenes, and
Snippets for the current Show.
The /-show/… commands are used to get/set elements and values related to Shows, Cues, Scenes and Snippets.
The /add, /copy, /save, /load, /delete and /rename commands are used to manage or update
internal entities such as cues, scenes, snippets and presets within the X32/M32. A scene will save all data while a
snippet will save small changes made to an existing scene. If the scene, snippet or preset already exists at the
index provided in the command, the element at that given index is updated with new information. Otherwise, a
new internal entity is created at the given index. These operators manage data between the X32/M32 internal
storage (not the USB drive) and the X32/M32 audio engine state or preset libraries in memory.
/add string, Adds a cue element to the current show in the X32/M32
int, internal memory.
26
See Appendix for table of enum/name/type
27
/copy does not enable copying snippets; /load and /save should be sed instead
Channel presets:
The third parameter represents the channel index
the preset is loaded to, in the range [0-71]
Effects presets:
The third parameter represents the effect index the
preset is loaded to, in the range [0…7]
Routing presets:
No additional parameters
/-undo/time string Display/Set [TBV] a time value for changes, for example
in selecting a scene. Time is coded as string, e.g.
Note: It seems there’s only 1 undo 18:36:54
step in X32
If string is empty: there are no more undo
steps available
Note/bug: in FW 2.08, it seems that Scenes and Snippets numbers associated to Cues are not always listed
correctly on the X32 LCD SCENES screen, under home page; they can appear listed on the first line rather than
respective of their associated Cue index. Selecting/Associating Scenes and Snippets to Cues AFTER cues are
created seem to avoid this issue.
Note/bug: in FW 2.08, specifically on X32 CORE, it seems that upon asking to load a show from a USB drive, the
last snippet from the show is not loaded; it is therefore advisable to add an empty snippet at the end of the list of
Note: The OSC data resulting from a /node command does not comply to OSC standard (no leading “/” ); the
returned string is “\n” (a.k.a 0x0a) terminated, which makes it suitable for direct printing or editing with a
standard text editor.
By experience, 54Mbits/s WIFI is not recommended for Shows with more than 20 lines (cues, scenes or snippets)
as there is a high probability of UDP buffer overflow/overrun. Higher data throughput rate are recommended, or
better, a 100Mbis/s wired connection.
Replies to client are formatted as per X32node commands format, as shown in the examples below.
X32/M32 does not have any scene or snippet, the answer to a /showdump request is:
node~~~~,s~~/-showfile/show “MyShow” 0 0 0 0 0 0 0 0 0 0 “2.08”
X32/M32 has a single scene (in scene slot 01, name: AAA, note: aaa) with Routing IO and Output Pach
selected as Scene Safes, no snippet, the answer to a /showdump request is:
node~~~~,s~~/-show/showfile/show “MyShow” 0 0 0 0 0 0 0 0 0 0 “2.08”
node~~~~,s~~/-show/showfile/scene/001 “AAA” “aaa” %110000000 1
X32/M32 has a single scene (in scene slot 01, name: AAA, note: aaa) with all items selected as Scene
Safes, no snippet, the answer to a /showdump request is:
node~~~~,s~~/-show/showfile/show “MyShow” 0 0 0 0 0 0 0 0 0 0 “2.08”
node~~~~,s~~/-show/showfile/scene/001 “AAA” “aaa” %111111110 1
We now add a new scene (in scene slot 02, name: BBB, note: bbb) with Talkback selected as Scene Safes,
no snippet, the answer to a /showdump request is:
node~~~~,s~~/-show/showfile/show “MyShow” 0 0 0 0 0 0 0 0 0 0 “2.08”
node~~~~,s~~/-show/showfile/scene/001 “AAA” “aaa” %111111110 1
node~~~~,s~~/-show/showfile/scene/002 “BBB” “bbb” %000000010 1
Keeping the 2 scenes created above, we create a snippet in slot 00, with name: Aaa, selecting Parameter
Filter Preamp(HA) and Channels Ch. The answer to a /showdump request is:
node~~~~,s~~/-show/showfile/show “MyShow” 0 0 0 0 0 0 0 0 0 0 “2.08”
node~~~~,s~~/-show/showfile/scene/001 “AAA” “aaa” %111111110 1
node~~~~,s~~/-show/showfile/scene/002 “BBB” “bbb” %000000010 1
node~~~~,s~~/-show/showfile/snippet/000 “Aaa” 1 1 0 0 1
Updating snippet in slot 00 with selecting Main/Matrix/Group parameter DCA 8, and saving the snippet to
slot00 with no other changes, the answer to a /showdump request is:
node~~~~,s~~/-show/showfile/show “MyShow” 0 0 0 0 0 0 0 0 0 0 “2.08”
node~~~~,s~~/-show/showfile/scene/001 “AAA” “aaa” %111111110 1
node~~~~,s~~/-show/showfile/scene/002 “BBB” “bbb” %000000010 1
node~~~~,s~~/-show/showfile/snippet/000 “Aaa” 1 1 0 32768 1
Keeping all data unchanged, we create a new cue, name it “Ccc”, at index 1.1, selecting scene 01 and
snippet = -1. The answer to a /showdump request is:
node~~~~,s~~/-show/showfile/show “MyShow” 0 0 0 0 0 0 0 0 0 0 “2.08”
node~~~~,s~~/-show/showfile/cue/000 100 “CCC” 0 -1 -1 0 1 0 0
node~~~~,s~~/-show/showfile/cue/001 110 “Ccc” 0 1 -1 0 1 0 0
node~~~~,s~~/-show/showfile/scene/001 “AAA” “aaa” %111111110 1
node~~~~,s~~/-show/showfile/scene/002 “BBB” “bbb” %000000010 1
node~~~~,s~~/-show/showfile/snippet/000 “Aaa” 1 1 0 32768 1
Selecting “skip” on cue Ccc, the answer to the X32node command appears as:
node~~~~,s~~/-show/showfile/cue/001 110 “Ccc” 1 1 -1 0 1 0 0
Updating cue CCC with snippet 0 (Aaa) selected, the X32node command answer appears as:
node~~~~,s~~/-show/showfile/cue/001 100 “CCC” 0 -1 0 0 1 0 0
Keeping all data unchanged, we create a new cue at index 2, name it “DDD”, selecting scene 02 and
snippet = 03. The answer to a /showdump request is:
/-prefs/remote/enable enum {OFF, ON} set or report X32/M32 remote enable state
/-prefs/remote/protocol int Protocol type for X32/M32 Remote
0: Mackie HCU [MC]
1: Mackie HUI [HUI]
2: Generic CC [CC]
/-prefs/remote/port int Port used for MIDI remote
/-prefs/card
/-prefs/card/UFifc enum Int[0…] representing the card type in the extension slot
0: FW
1: USB
2: … tbd
/-prefs/card/UFmode enum X-UF card settings
0: 32in/32out
1: 16in/16out
2: 32in/8out
3: 8in/32out
28
See Appendix section for detailed values
USB (/-usb)
/-usb/path string Name of the current directory, e.g.:
/-usb/path~~,s~~Dblues 48kHz~~~~
/-usb/title string Name of a file in the current directory of USB stick, e.g.:
/-usb/title~,s~~Candy-DB~~~~
/-usb/dir/dirpos int Current directory entry number
/-usb/dir/maxpos int Number of entries of the current directory in USB stick,
e.g.:
/-usb/dir/maxpos~~~~,i~~<int=16>
/-usb/dir/001…999/type string The name of file at position 000…999 of current directory
in USB stick, e.g.:
/-usb/dir/006/type~~,s~~~~~~
/-usb/dir/001…999/name string The name of file at position 000…999 of current directory
in USB stick, e.g.:
/-usb/dir/006/name~~,s~~Candy.wav~~
The file “candy.wav” is at position 6 in
the current directory
/-stat/geqpos~~~,i~~<0x00000105>
/-stat/aes50/A string
/-stat/aes50/B string
/-stat/aes50/state int
There may be situations when you (or the application you write) may not want to receive all data sent by the
X32/M32 resulting of mainaining a /xremote command active, as this may represent a lot of data to parse.
Besides the /xremote command which enables clients to receive pretty much all X32/M32 changes or updates
resulting from an <OSC Address Pattern> Set parameter command sent from a different client, there are a series
of commands a client can use to manage specific updates from X32/M32: /subscribe, /formatsubscribe,
/batchsubscribe, /renew, and /unsubscribe
The /subscribe command enables getting regular updates for a single <OSC Address Pattern> command. A
typical use would be: /subscribe ,si <command> [tf], where
<command> is an X32/M32 <OSC Address Pattern> parameter command, for example: /ch/01/mix/on
[tf] is an integer which affects the number of updates received over a 10 seconds period:
[tf]: 0 200 updates
2 100 updates
[…]
40 5 updates
80 or more 3 updates
The /formatsubscribe ,ss[s…]iii <name> <command> [<command>…] [i0][i1][tf] goes one step
further and enables receiving regular updates for a series of commands, optionnaly using wildcard ‘*’ characters
to represent variable ranges.
<name> is an alias (string) given to the command, and can be later used for requesting specific renews for
additional rounds of updates.
<command> is an <OSC Address Pattern> command. There can be several commands in a single
/formatsubscribe. Some X32/M32 commands refer to range attributes, such as in a channel number:
[01-32]. Range data characters digits can be replaced by ‘*’ characters. For example /dca/[1-8]/on is
replaced by /dca/*/on, /ch/[01-32]/mix/on will be replaced by /ch/**/mix/on, and so on.
[i0] and [i1] are integers to represent the start and end range numbers, respectively.
[tf] as previously, is an integer affecting the number of updates received over a 10 seconds period.
The next example below starts with Bus 01 & 02 linked, and Channels 09 to 13 being muted. With /xremote
being maintained active, a /formatsubscribe command is issued, requesting 10 updates for buslink/1-2, and
channel [10-12] mutes updates. As the command executes, Bus/1-2 is unlinked, then channels 09 to 13 are
successively unmuted. The command does repeatedly report mute status only for channels 10 to 12, as
requested.
For easier reading, the X32 data resulting of user action reported thanks to the /xremote command being active
is displayed in red, while the data resulting from the /formatsubscribe command is displayed in blue.
/batchsubscribe is a command to display meter data only [TBV]. The format is close to /formatsubscribe:
The command is aliased to a name, and accepts a single meter command followed by two ints for the meter
command parameters (ints are 0 if the meter command does not take arguments); as for the other commands the
last int represents a time factor.
[…]
X->, 124 B: rrr~,b~~27 flts: 000.00 000.00 000.00 000.00 000.00 000.00 000.00 000.00
000.00 000.00 000.00 000.00 000.00 000.00 000.00 000.00 000.00 000.00 000.00 000.00 000.00
000.00 000.00 000.00 000.00 000.00 000.00
Refer to the /meter/5 meters command for the meaning of the two arguments [3] and [1].
As already mentioned, the above subscription commands are valid for 10s. In order to keep receiving data from
the X32/M32, subscriptions have to be renewed with the /renew command. The command takes one optional
argument, a string type to specify the subscription to renew. This will be either ne name of the actual command
or the name of the command alias for renewing /formatsubscribe and /batchsubscribe commands. It is
possible to renew all active subscriptions by not providing any name to the /renew command.
The X32/M32 can manage multiple subscriptions. Data from different subscriptions will be mixed. Shown below, 3
different subscription requests are made for a period of 10s. Commands are in black and the X32 replies are in 3
different colors for easier reading.
[…]
X->, 24 B: /ch/01/mix/on~~~,i~~[ 1]
X->, 24 B: /ch/01/mix/on~~~,i~~[ 1]
X->, 24 B: AAA~,b~~12 chrs: Ç ?
X->, 24 B: /ch/01/mix/on~~~,i~~[ 1]
X->, 32 B: BBB~,b~~4 flts: 000.00 001.00 001.00 000.00
X->, 24 B: /ch/01/mix/on~~~,i~~[ 1]
X->, 24 B: /ch/01/mix/on~~~,i~~[ 1]
At anytime, subscriptions can be stopped using the /unsubscribe command. As several subscriptions can be
active at one time, the command takes a string argument to select which subscription should be stopped. An
/unsubscribe command with no argument will stop all active subscriptions.
The / command is used to send X32node formatted commands (i.e. the resulting form of a /node command) to
the X32/M32, thus updating all parameters of a node at once and using clear text data. The command follows the
standard OSC specification and takes a single string as argument. The data to send should conform to X32/M32
formats and known values, but the X32 will keep the closest value to the one sent if that is not the case; for
example, sending / ,s "ch/01/mix/fader -85.4" will be kept as -85.3, as -85.4 is not one of the 1024
“known values” for faders.
The leading ’/’ of the command to be sent to X32 is not mandatory, i.e. sending / ,s "/ch/01/mix/fader
-85.4" is the same as sending / ,s "ch/01/mix/fader -85.4".
The X32/M32 will echo back the “/” commands it receives enabling a better control of the flowof data and
helping avoid overruns by ensuring an application does read the UDP buffer before sending the next command.
The /node command can be used by clients to request values and data for the X32node provided with the
request. The server returns the full set of data associated to the request in a single string of text, ending with a
linefeed.
X32node commands
/ string Send X32node data passed as a string argument to X32/M32.
Example:
/~~~,s~~-prefs/iQ/01 none Linear 0~~
or
/~~~,s~~/-prefs/iQ/01 none Linear 0~
Example of request:
/node~~~,s~~headamp/124~ !! note: no ‘/’ before the request string
config/chlink
config/auxlink
config/fxlink
config/buslink
config/mtxlink
ch/[01…32]/config
ch/[01…32]/delay
ch/[01…32]/preamp
ch/[01…32]/gate
ch/[01…32]/gate/filter
ch/[01…32]/dyn
ch/[01…32]/dyn/filter
ch/[01…32]/insert
ch/[01…32]/eq
ch/[01…32]/eq/[1…4]
ch/[01…32]/mix
ch/[01…32]/mix/[01…16]
ch/[01…32]/grp
auxin/[01…08]/config
auxin/[01…08]/preamp
auxin/[01…08]/eq
auxin/[01…08]/eq/[1…4]
auxin/[01…08]/mix
auxin/[01…08]/mix/[01…16]
auxin/[01…08]/grp
fxrtn/[01…08]/config
fxrtn/[01…08]/eq
fxrtn/[01…08]/eq[1…4]
fxrtn/[01…08]/mix
fxrtn/[01…08]/mix/[01…16]
fxrtn/[01…08]/grp
bus/[01…16]/config
bus/[01…16]/dyn
bus/[01…16]/dyn/filter
bus/[01…16]/insert
bus/[01…16]/eq
bus/[01…16]/eq[1…6]
bus/[01…16]/mix
bus/[01…16]/mix/[01…06]
bus/[01…16]/grp
mtx/[01…06]/config
main/st/config
main/st/dyn
main/st/dyn/filter
main/st/insert
main/st/eq
main/st/eq[1…6]
main/st/mix
main/st/mix/[01…06]
main/m/config
main/m/dyn
main/m/dyn/filter
main/m/insert
main/m/eq
main/m/eq[1…6]
main/m/mix
main/m/mix/[01…06]
dca/[1…8]
dca/[1…8]/config
fx/[1…8]
fx/[1…8]/source
fx/[1…8]/par
outputs/main/[01…16]
outputs/main/[01…16]/delay
outputs/aux/[01…06]
outputs/p16/[01…16]
outputs/p16/[01…16]/iQ
outputs/aes/[01…02]
outputs/rec/[01…02]
headamp/[000…127]
-insert
-show
-show/prepos
-show/prepos/current
-show/showfile
-show/showfile/inputs
-show/showfile/mxsends
-show/showfile/mxbuses
-show/showfile/console
-show/showfile/chan16
-show/showfile/chan32
-show/showfile/return
-show/showfile/buses
-show/showfile/lrmtxdca
-show/showfile/cue
-show/showfile/cue/[000…099]
-show/showfile/cue/[000…099]/numb
-show/showfile/cue/[000…099]/name
-show/showfile/cue/[000…099]/skip
-show/showfile/cue/[000…099]/scene
-show/showfile/cue/[000…099]/bit
-show/showfile/cue/[000-099]/miditype
-show/showfile/cue/[000-099]/midichan
-show/showfile/cue/[000-099]/midipara1
-show/showfile/cue/[000-099]/midipara2
-show/showfile/scene
-show/showfile/scene/[000…099]
-show/showfile/scene/[000…099]/name
-show/showfile/scene/[000…099]/notes
-show/showfile/scene/[000…099]/safes
-show/showfile/scene/[000…099]/hasdata
-show/showfile/snippet
-show/showfile/snippet/[000…099]
-show/showfile/snippet/[000…099]/name
-show/showfile/snippet/[000…099]/eventtyp
-show/showfile/snippet/[000…099]/channels
-show/showfile/snippet/[000…099]/auxbuses
-show/showfile/snippet/[000…099]/maingrps
-show/showfile/snippet/[000…099]/hasdata
-libs/ch
-libs/ch/[001-100]
-libs/ch/[001-100]/pos
-libs/ch/[001-100]/name
-libs/ch/[001-100]/flags
-libs/ch/[001-100]/hasdata
-libs/fx
-libs/fx/[001-100]
-libs/fx/[001-100]/pos
-libs/fx/[001-100]/name
-libs/fx/[001-100]/flags
-libs/fx/[001-100]/hasdata
-libs/r
-libs/r/[001-100]
-libs/r/[001-100]/pos
-libs/r/[001-100]/name
-libs/r/[001-100]/flags
-libs/r/[001-100]/hasdata
-prefs
-prefs/style
-prefs/bright
-prefs/lcdcont
-prefs/ledbright
-prefs/lamp
-prefs/lampon
-prefs/clockrate
-prefs/rta
-prefs/rta/visibility
-prefs/rta/gain
-prefs/rta/autogain
-prefs/rta/source
-prefs/rta/pos
-prefs/rta/mode
-prefs/rta/option
-prefs/rta/det
-prefs/rta/decay
-prefs/rta/peakhold
-prefs/ip
-prefs/ip/dhcp
-prefs/ip/addr
-prefs/ip/mask
-prefs/ip/gateway
-prefs/remote
-prefs/remote/enable
-prefs/remote/protocol
-prefs/remote/port
-prefs/remote/ioenable
-prefs/iQ
-prefs/iQ/[01-16]
-prefs/iQ/[01-16]/iQmodel
-prefs/iQ/[01-16]/iQeqset
-prefs/iQ/[01-16]/iQsound
-prefs/card
-usb
-usb/path
-usb/title
-usb/dir
-usb/dirpos
-usb/maxpos
-usb/dir/[000…999]
-usb/dir/[000…999]/name
-stat
-stat/solosw
-stat/solosw/[01…80]
-stat/screen
-stat/screen/screen
-stat/screen/mutegrp
-stat/screen/utils
-stat/screen/CHAN
-stat/screen/METER
-stat/screen/ROUTE
-stat/screen/SETUP
-stat/screen/LIB
-stat/screen/FX
-stat/screen/MON
-stat/screen/USB
-stat/screen/SCENE
-stat/screen/ASSIGN
-stat/tape
-stat/tape/state
-stat/tape/file
-stat/tape/etime
-stat/tape/rtime
-action
-action/setip
-action/setclock
-action/initall
-action/initlib
-action/initshow
-action/savestate
-action/undopt
-action/doundo
-action/platrack
-action/newscreen
Note/bug: the response from the Server is “node…” and not “/node…” as one could expect. This is not OSC
compliant.
This section describes the parameters’ list, order, name, type and value range for the different effects available
with the X32/M32. The parameters described here correspond to the up to 64 parameters that can follow a
/fx/[1…8]/par/[01…64] message.
Parameters can be sent one by one, or combined in lists -alternating types as needed-, which is generally more
efficient.
Hall Reverb
Ambiance Reverb
Room Reverb
Effect Name Parameters Parameter Name Type & Range
ROOM ffffffffffffffff Pre Delay linf [0…200]
(room reverb) Decay logf [0.3…29]
Size linf [4…72]
Damping logf [1k…20k]
Diffuse linf [1…30]
Level linf [-12…+12]
Lo Cut logf [10…500]
Hi Cut logf [200…20k]
Bass Multi logf [0.25…4]
Spread linf [0…50]
Shape linf [0…250]
Spin linf [0…100]
Echo L linf [0…1200]
Echo R linf [0…1200]
Echo Feed L linf [-100…+100]
Echo Feed L linf [-100…+100]
4-Tap Delay
Vintage Room
Reverse Reverb
Stereo Flanger
Effect Name Parameters Parameter Name Type & Range
FLNG ffffffffffff Speed logf [0.05…5]
(stereo flanger) Depth L linf [0…100]
Depth R linf [0…100]
Delay L logf [0.5…20]
Delay R logf [0.5…20]
Mix linf [0…100]
Lo Cut logf [10…500]
Hi Cut logf [200…20k]
Phase linf [0…180]
Feed Lo Cut logf [10…500]
Feed Hi Cut logf [200…20k]
Feed linf [-90…+90]
Dimensional Chorus
Rotary Speaker
Sub Octaver
Delay / Chorus
Chorus / Chamber
Modulation Delay
TEQ
(true stereo graphic
eq)
Precision Limiter
Edison EX1
Sound Maxer
Stereo Imager
Wave Designer
This chapter describes the different settings and options linked to User Definable Controls a.k.a OSC command
/config/userctrl .
The User Control section consists of 4 columns composed of a rotary encoder and two buttons. Encoders are
numbered 1 to 4 and buttons are numbered 5 to 12. Question: Are the 8 buttons of the X32/M32 Compact
known as 1 to 8 as labeled on the desk or 5 to 12, as on the X32/M32 Standard and Producer?
Rotary Encoders
Scribbles
Buttons
Layer Selection
A series of 3 buttons at the bottom of the section enables selecting one of 3 layers of user controls layers [A, B
and C]. When addressing user controls to get or set data, the layer name and encoder or button number must be
provided. A small LCD displays the functions the rotary encoders or buttons are assigned to.
Notes:
There are no OSC commands to update the 4 scribbles of the assign section. This and the lack of full user
assignable data limit what can be achieved with the assign section.
There are no OSC commands to set an OSC only mode for the assign section in the current implementation
(FW 2.14).
There are no “NC” (normally closed) push-type buttons in the current implementation (FW 2.10). “NC” push
buttons types can still be implemented but do require a feedback from the receiving program to simulate a
normally closed push button.
Note: TBD if this applies “as is” to Rack, Core, Compact and Producer
The data used to set encoder values is a string made of up to 7 characters. The first character (encoder
assignment) selects the main functionality the encoder controls.
Note: TBD if this applies “as is” to Rack, Core, Compact and Producer
The data used to set buttons values is a string made of up to 7 characters. The first character (button assignment)
selects the main functionality the button controls.
As mentioned earlier in this document, X32 faders implement a 4 linear functions approach with cross points at
-10, -30, -60 dB to emulate the log function one can expect to manipulate volume data. Fader controls typically
follow a log10 function to match the human perception of loudness.
The volume ratio generic formula: dB value = 20 * log (v2/v1) produces a response curve in blue, as below. On the
other hand, X32 faders are using 4 different linear functions with increasing slopes to approximate the dB log
transfer shape; the figure below shows the 4 different X32 line segments in red.
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
20.000
0.000
-20.000
-40.000
-60.000
-80.000
Log function
-100.000
X32 faders
-120.000
-140.000
-160.000
The paragraphs below show a C-like conversion to go from [0.0, 1.0] to dB [-90 ,+10] with value 0 matching –oo,
and vice-versa. This can be useful to map with other programs or tools used, or for programmers who need to
match the float values returned by OSC functions to dB values in their programs.
// float to dB
// “f” represents OSC float data. f: [0.0, 1.0]
// “d” represents the dB float data. d:[-oo, +10]
if (f >= 0.5) d = f * 40. - 30.; // max dB value: +10.
else if (f >= 0.25) d = f * 80. - 50.;
else if (f >= 0.0625) d = f * 160. - 70.;
else if (f >= 0.0) d = f * 480. - 90.; // min dB value: -90 or -oo29.
// dB to float
// “d” represents the dB float data. d:[-90, +10]
// “f” represents OSC float data. f: [0.0, 1.0]
if (d < -60.) f = (d + 90.) / 480.;
else if (d < -30.) f = (d + 70.) / 160.;
else if (d < -10.) f = (d + 50.) / 80.;
else if (d <= 10.) f = (d + 30.) / 40.;
// Optionally round “f” to a X32 known value
f = roundf(f * 1023) / 1023;
29
Note: a forum member reported the X32/M32 have an internal –oo value of -144dB, but this doesn’t appear in any data
reported by X32.
The following table lists the control elements that can be found in a scene file. A scene file “name.scn” is
typically 2070 lines (2054 in FW versions prior to 2.12) of editable data representing the working state of the
X32/M32 and controlling almost all X32/M32 parameters.
This first line contains the name and note associated to the scene and ends with the list of scene safes in the form
of 8 [0/1] characters terminated by a 0: %000000000 and is terminated by a 1. It is then followed by (/node like
commands, or X32nodes) lines from the table above; they are followed by the parameters they control;
A line beginning with ‘#’ is treated as a comment line.
30
Starting with FW version 2.12
The table below lists the control elements that can be found in a snippet file. A snippet file “name.snp” is
variable in size and made of text editable data representing a subset of X32/M32 parameters.
The 4 numerical parameters following the snippet name and followed by ‘1’ are the eventtyp, channels,
auxbuses, and maingrps filters respectively, saved/present in the file.
This first line is then followed by the lines (/node like commands) in the table below; they are followed by the
parameters they control; a line beginning with ‘#’ is treated as a comment line.
31
Starting with FW version 2.12
The table below lists the control elements that can be found in a Channel, Library or Routing preset file.
Preset files are variable in size and consist of subset of X32/M32 parameters in the form of editable text (/node
like commands).
Where
<pos>: preset index value (can be chosen by the user)
<type>: a type number:
• Effects: used for sorting by type or by name and enable loading in FX slots [1…4] or [5…8]
• Channels and Routing: unused
<flags>: a list of 16 digits [0 or 1] representing:
• Channels: if a channel section is present in the preset [digits 0…7] and whether it is active
or not [digits 8…15] (see /-libs/ch[001-100]/flags for details)
• Effects and Routing: unused
This first line is then followed by the lines (/node like commands) in the table below; they are followed by the
parameters they control; a line beginning with ‘#’ is treated as a comment line.
* In the case of Channel and Effect types, the typical /node header (i.e. /ch/nn/ or /fx/n/) is not present as the
file does not apply to a specific channel or effect number.
32
Starting with FW version 2.12
X32/M32 Icons33 are numbered 01…74 and shown in the table below.
01 02 03 04 05 06
07 08 09 10 11 12
13 14 15 16 17 18
19 20 21 22 23 24
25 26 27 28 29 30
31 32 33 34 35 36
37 38 39 40 41 42
43 44 45 46 47 48
49 50 51 52 53 54
55 56 57 58 59 60
61 62 63 64 65 66
67 68 69 70 71 72
73 74
33
The icons have been extracted from the X32-edit application
Additionaly to Behringer’s document/note “X32 MIDI Implementation (06 May 2014)”34 which provides an
overview of the MIDI RX, TX and MIDI assignments applicable to X32/M32 systems, OSC commands can be sent
to the device over MIDI, using Sysex messages. Make sure your MIDI connection or device will support sending
SYSEX messages; some devices do not provide (full) SYSEX support.
The general format for sending OSC commands over MIDI Sysex is:
F0 00 20 32 32 <OSCtext> F7
with <OSCtext> being the OSC command in text hex format, and up to 39 kbtyes in length. The space character
0x20 is used as separator between command and data, as shown below. Parameter data are converted from int
or float to their string equivalent, respecting known X32 values where appropriate. Enums are sent as strings too.
Examples: (~ stands for the NULL character, \0; data within brackets are sent as 32 bits big endian values)
Setting channel 01, EQ 2 frequency to 1kHz (actually 1020Hz, due to known discrete values)
OSC: /ch/01/eq/2/f~~~,f~~[0.57]
Sysex: F0 00 20 32 32 2F 63 68 2F 30 31 2F 65 71 2F 32 2F 66 20 31 30 32 30 F7
Setting User Assign Bank C, button 5 to send MIDI note 3 on MIDI channel 5, as a MIDI push command
OSC: /config/userctrl/C/btn/5~~~~,s~~MN05003~
Sysex: F0 00 20 32 32 2F 63 6F 6E 66 69 67 2F 75 73 65 72 63 74 72 6C 2F 43 2F 62 74
6E 2F 35 20 4D 4E 30 35 30 30 33 F7
As a result, Bank C button 5 will generate the following two MIDI sequences: 94 03 7F and 94 03 00
Please refer to the OSC commands descriptions in this document for command formats and applicable ranges for
their respective parameters types and ranges, and tables in appendix for corresponding floating point data and
X32/M32 known discrete values for different fields (EQ, Dynamics, Gate, etc).
34
Available on Behringer web site, download section – MIDI Protocol
0.0000 20.0 0.2050 82.4 0.4100 339.6 0.6150 1k39 0.8200 5k76
0.0050 20.7 0.2100 85.3 0.4150 351.6 0.6200 1k44 0.8250 5k97
0.0100 21.4 0.2150 88.3 0.4200 363.9 0.6250 1k49 0.8300 6k18
0.0150 22.2 0.2200 91.4 0.4250 376.7 0.6300 1k55 0.8350 6k39
0.0200 23.0 0.2250 94.6 0.4300 390.0 0.6350 1k60 0.8400 6k62
0.0250 23.8 0.2300 98.0 0.4350 403.7 0.6400 1k66 0.8450 6k85
0.0300 24.6 0.2350 101.4 0.4400 417.9 0.6450 1k72 0.8500 7k09
0.0350 25.5 0.2400 105.0 0.4450 432.5 0.6500 1k78 0.8550 7k34
0.0400 26.4 0.2450 108.7 0.4500 447.7 0.6550 1k84 0.8600 7k60
0.0450 27.3 0.2500 112.5 0.4550 463.5 0.6600 1k91 0.8650 7k87
0.0500 28.3 0.2550 116.4 0.4600 479.8 0.6650 1k97 0.8700 8k14
0.0550 29.2 0.2600 120.5 0.4650 496.6 0.6700 2k04 0.8750 8k43
0.0600 30.3 0.2650 124.7 0.4700 514.1 0.6750 2k11 0.8800 8k73
0.0650 31.3 0.2700 129.1 0.4750 532.1 0.6800 2k19 0.8850 9k03
0.0700 32.4 0.2750 133.7 0.4800 550.8 0.6850 2k27 0.8900 9k35
0.0750 33.6 0.2800 138.4 0.4850 570.2 0.6900 2k34 0.8950 9k68
0.0800 34.8 0.2850 143.2 0.4900 590.2 0.6950 2k43 0.9000 10k02
0.0850 36.0 0.2900 148.3 0.4950 611.0 0.7000 2k51 0.9050 10k37
0.0900 37.2 0.2950 153.5 0.5000 632.5 0.7050 2k60 0.9100 10k74
0.0950 38.6 0.3000 158.9 0.5050 654.7 0.7100 2k69 0.9150 11k11
0.1000 39.9 0.3050 164.4 0.5100 677.7 0.7150 2k79 0.9200 11k50
0.1050 41.3 0.3100 170.2 0.5150 701.5 0.7200 2k89 0.9250 11k91
0.1100 42.8 0.3150 176.2 0.5200 726.2 0.7250 2k99 0.9300 12k33
0.1150 44.3 0.3200 182.4 0.5250 751.7 0.7300 3k09 0.9350 12k76
0.1200 45.8 0.3250 188.8 0.5300 778.1 0.7350 3k20 0.9400 13k21
0.1250 47.4 0.3300 195.4 0.5350 805.4 0.7400 3k31 0.9450 13k67
0.1300 49.1 0.3350 202.3 0.5400 833.7 0.7450 3k43 0.9500 14k15
0.1350 50.8 0.3400 209.4 0.5450 863.0 0.7500 3k55 0.9550 14k65
0.1400 52.6 0.3450 216.8 0.5500 893.4 0.7550 3k68 0.9600 15k17
0.1450 54.5 0.3500 224.4 0.5550 924.8 0.7600 3k81 0.9650 15k70
0.1500 56.4 0.3550 232.3 0.5600 957.3 0.7650 3k94 0.9700 16k25
0.1550 58.3 0.3600 240.5 0.5650 990.9 0.7700 4k08 0.9750 16k82
0.1600 60.4 0.3650 248.9 0.5700 1k02 0.7750 4k22 0.9800 17k41
0.1650 62.5 0.3700 257.6 0.5750 1k06 0.7800 4k37 0.9850 18k03
0.1700 64.7 0.3750 266.7 0.5800 1k09 0.7850 4k52 0.9900 18k66
0.1750 67.0 0.3800 276.1 0.5850 1k13 0.7900 4k68 0.9950 19k32
0.1800 69.3 0.3850 285.8 0.5900 1k17 0.7950 4k85 1.0000 20k00
0.1850 71.8 0.3900 295.8 0.5950 1k21 0.8000 5k02
0.1900 74.3 0.3950 306.2 0.6000 1k26 0.8050 5k20
0.1950 76.9 0.4000 317.0 0.6050 1k30 0.8100 5k38
0.2000 79.6 0.4050 328.1 0.6100 1k35 0.8150 5k57
0.0000 20.0 0.2333 100.2 0.4667 502.4 0.7000 2k51 0.9333 12k61
0.0083 21.2 0.2417 106.2 0.4750 532.1 0.7083 2k66 0.9417 13k36
0.0167 22.4 0.2500 112.5 0.4833 563.7 0.7167 2k82 0.9500 14k15
0.0250 23.8 0.2583 119.1 0.4917 597.1 0.7250 2k99 0.9583 14k99
0.0333 25.2 0.2667 126.2 0.5000 632.5 0.7333 3k16 0.9667 15k88
0.0417 26.7 0.2750 133.7 0.5083 669.9 0.7417 3k35 0.9750 16k82
0.0500 28.3 0.2833 141.6 0.5167 709.6 0.7500 3k55 0.9833 17k82
0.0583 29.9 0.2917 150.0 0.5250 751.7 0.7583 3k76 0.9917 18k88
0.0667 31.7 0.3000 158.9 0.5333 796.2 0.7667 3k99 1.0000 20k00
0.0750 33.6 0.3083 168.3 0.5417 843.4 0.7750 4k22
0.0833 35.6 0.3167 178.3 0.5500 893.4 0.7833 4k47
0.0917 37.7 0.3250 188.8 0.5583 946.3 0.7917 4k74
0.1000 39.9 0.3333 200.0 0.5667 1k00 0.8000 5k02
0.1083 42.3 0.3417 211.9 0.5750 1k06 0.8083 5k32
0.1167 44.8 0.3500 224.4 0.5833 1k12 0.8167 5k63
0.1250 47.4 0.3583 237.7 0.5917 1k19 0.8250 5k97
0.1333 50.2 0.3667 251.8 0.6000 1k26 0.8333 6k32
0.1417 53.2 0.3750 266.7 0.6083 1k33 0.8417 6k69
0.1500 56.4 0.3833 282.5 0.6167 1k41 0.8500 7k09
0.1583 59.7 0.3917 299.2 0.6250 1k49 0.8583 7k51
0.1667 63.2 0.4000 317.0 0.6333 1k58 0.8667 7k96
0.1750 67.0 0.4083 335.8 0.6417 1k68 0.8750 8k43
0.1833 71.0 0.4167 355.7 0.6500 1k78 0.8833 8k93
0.1917 75.2 0.4250 376.7 0.6583 1k88 0.8917 9k46
0.2000 79.6 0.4333 399.1 0.6667 2k00 0.9000 10k02
0.2083 84.3 0.4417 422.7 0.6750 2k11 0.9083 10k61
0.2167 89.3 0.4500 447.7 0.6833 2k24 0.9167 11k24
0.2250 94.6 0.4583 474.3 0.6917 2k37 0.9250 11k91
The data is presented as [enum value, enum name, preset flags, preset name] quadruplets
FX1…FX4:
0 "HALL" %000000 Hall Reverb 30 "TEQ" %011001 Strereo TrueEQ
1 "AMBI" %000101 Ambiance 31 "DES2" %101011 Dual DeEsser
2 "RPLT" %000011 Rich Plate Reverb 32 "DES" %101010 Stereo DeEsser
3 "ROOM" %000010 Room Reverb 33 "P1A" %101100 Stereo Xtec EQ1
4 "CHAM" %000001 Chamber Reverb 34 "P1A2" %101101 Dual Xtec EQ1
5 "PLAT" %000100 Plate Reverb 35 "PQ5" %101110 Stereo Xtec EQ5
6 "VREV" %001001 Vintage Reverb 36 "PQ5S" %101111 Dual Xtec EQ5
7 "VRM" %001000 Vintage room 37 "WAVD" %011101 Wave Designer
8 "GATE" %000110 Gated Reverb 38 "LIM" %011110 Precision Limiter
9 "RVRS" %000111 Reverse Reverb 39 "CMB" %111011 Combinator
10 "DLY" %010100 Stereo Delay 40 "CMB2" %111100 Dual Combinator
11 "3TAP" %010101 3-Tap Delay 41 "FAC" %110000 Fair Comp
12 "4TAP" %010110 Rhythm Delay 42 "FAC1M" %110001 M/S Fair Comp
13 "CRS" %001010 Stereo Chorus 43 "FAC2" %110010 Dual Fair Comp
14 "FLNG" %001011 Stereo Flanger 44 "LEC" %110011 Leisure Comp
15 "PHAS" %011011 Stereo Phaser 45 "LEC2" %110100 Dual Leisure Comp
16 "DIMC" %111010 Dimension-C 46 "ULC" %110101 Ultimo Comp
17 "FILT" %101001 Mood Filter 47 "ULC2" %110110 Dual Ultimo Comp
18 "ROTA" %011100 Rotary Speaker 48 "ENH2" %100000 Dual Enhancer
19 "PAN" %101000 Tremolo/Panner 49 "ENH" %011111 Stereo Enhancer
20 "SUB" %111001 Suboctaver 50 "EXC2" %100010 Dual Exciter
21 "D/RV" %010000 Delay+Chamber 51 "EXC" %100001 Stereo Exciter
22 "CR/R" %001110 Chorus+Chamber 52 "IMG" %100111 Stereo Imager
23 "FL/R" %001111 Flanger+Chamber 53 "EDI" %111000 Edison EX1
24 "D/CR" %010001 Delay+Chorus 54 "SON" %110111 Sound Maxer
25 "D/FL" %010010 Delay+Flanger 55 "AMP2" %100100 Dual Guitar Amp
26 "MODD" %010011 Modulation Delay 56 "AMP" %100011 Stereo Guitar Amp
27 "GEQ2" %011000 Dual Graphic EQ 57 "DRV2" %100110 Dual Tube Stage
28 "GEQ" %010111 Stereo Graphic EQ 58 "DRV" %100101 Stereo Tube Stage
29 "TEQ2" %011010 Dual TrueEQ 59 "PIT2" %001101 Dual Pitch Shifter
60 "PIT" %001100 Stereo Pitch
FX5…FX8:
0 "GEQ2" %011000 Dual Graphic EQ 17 "ULC" %110101 Ultimo Comp
1 "GEQ" %010111 Stereo Graphic EQ 18 "ULC2" %110110 Dual Ultimo Comp
2 "TEQ2" %011010 Dual TrueEQ 19 "ENH2" %100000 Dual Enhancer
3 "TEQ" %011001 Strereo TrueEQ 20 "ENH" %011111 Stereo Enhancer
4 "DES2" %101011 Dual DeEsser 21 "EXC2" %100010 Dual Exciter
5 "DES" %101010 Stereo DeEsser 22 "EXC" %100001 Stereo Exciter
6 "P1A" %101100 Stereo Xtec EQ1 23 "IMG" %100111 Stereo Imager
7 "P1A2" %101101 Dual Xtec EQ1 24 "EDI" %111000 Edison EX1
8 "PQ5" %101110 Stereo Xtec EQ5 25 "SON" %110111 Sound Maxer
9 "PQ5S" %101111 Dual Xtec EQ5 26 "AMP2" %100100 Dual Guitar Amp
10 "WAVD" %011101 Wave Designer 27 "AMP" %100011 Stereo Guitar Amp
11 "LIM" %011110 Precision Limiter 28 "DRV2" %100110 Dual Tube Stage
12 "FAC" %110000 Fair Comp 29 "DRV" %100101 Stereo Tube Stage
13 "FAC1M" %110001 M/S Fair Comp 30 "PHAS" %011011 Stereo Phaser
14 "FAC2" %110010 Dual Fair Comp 31 "FILT" %101001 Mood Filter
15 "LEC" %110011 Leisure Comp 32 "PAN" %101000 Tremolo/Panner
16 "LEC2" %110100 Dual Leisure Comp 33 "SUB" %111001 Suboctaver
Would you take on starting programming for the X32/M32 series, below is a small “Hello World” C program to
open a communication stream with X32/M32, send a simple command, an receive an answer back from X32/M32.
HelloX32 (Unix)
//
// HelloX32.c
//
// Simple example of communication setup with an X32/M32
// Uses UDP protocol
// X32/M32 should be set at IP = 192.168.0.64
// Communication takes place on port 10023
//
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <sys/socket.h>
#include <arpa/inet.h>
int
main(int argc, char **argv)
{
char Xip_str[20], Xport_str[8]; // X32/M32 IP and Port
struct sockaddr_in Xip;
struct sockaddr* Xip_addr = (struct sockaddr *)&Xip;
socklen_t Xip_len = sizeof(Xip); // length of addresses
int Xfd; // X32/M32 socket
int rec_len, i;
char rec_buf[256]; // receive buffer
char info_buf[8] = "/info"; // zeroes are automatically added
//
// Initialize communication with X32/M32 server at IP ip and PORT port
// Set default values to match your X32/M32 desk
strcpy (Xip_str, "192.168.0.64");
strcpy (Xport_str, "10023");
// Load the X32/M32 address we connect to; we're a client to X32/M32, keep it simple.
// Create UDP socket
if ((Xfd = socket (PF_INET, SOCK_DGRAM, IPPROTO_UDP)) < 0)
exit (EXIT_FAILURE);
// Construct server sockaddr_in structure
memset (&Xip, 0, sizeof(Xip)); // Clear struct
Xip.sin_family = AF_INET; // Internet/IP
Xip.sin_addr.s_addr = inet_addr(Xip_str); // IP address
Xip.sin_port = htons(atoi(Xport_str)); // server port
// All done. Let's establish connection with X32/M32 server
printf(" HelloX32 – v0.9 - 2014 Patrick-Gilles Maillot\n\n");
printf("Connecting to Console\n");
if (sendto (Xfd, info_buf, sizeof(info_buf), 0, Xip_addr, Xip_len) < 0)
exit (EXIT_FAILURE);
// Receive answer back from X32/M32
if ((rec_len = recvfrom (Xfd, rec_buf, sizeof(rec_buf), 0, 0, 0)) <= 0)
exit (EXIT_FAILURE);
printf("Buffer data from Console: %d bytes,\n", rec_len);
i = 0;
while(rec_len--) {
if (rec_buf[i] == 0) rec_buf[i] = '~'; // handle non-printable chars
putchar(rec_buf[i++]);
}
putchar('\n');
// All done!
exit(0);
}
/*
* X32UDP.c
* (POSIX compliant version, Linux...)
* Created on: June 2, 2015
* Author: Patrick-Gilles Maillot
*
* Copyright 2015, Patrick-Gilles Maillot
* This software is distributed under he GNU GENERAL PUBLIC LICENSE.
*
* This software allows connecting to a remote X32 or XAIR system using
* UDP protocol; It provides a set of connect, send and receive functions.
* The receive mode is non-blocking, i.e. a timeout enables returning from
* the call even if no response is obtained by the server.
*
* Send and Receive buffers are provided by the caller. No provision is
* made in this package to keep or buffer data for deferred action or
* transfers.
*/
#include <stdlib.h>
#include <string.h>
#include <time.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <poll.h>
//
#define BSIZE 512 // MAX receive buffer size
//
struct sockaddr_in Xip;
struct sockaddr* Xip_addr = (struct sockaddr *)&Xip;
socklen_t Xip_len = sizeof(Xip); // length of addresses
int Xfd; // X32 socket
struct pollfd ufds;
//
int r_len, p_status; // length and status for receiving
//
//
int X32Connect(char *Xip_str, char *Xport_str) {
//
// Initialize communication with X32 server at IP ip and PORT port//
// Load the X32 address we connect to; we're a client to X32, keep it simple.
//
// Input: String - Pointer to IP in the form "123.123.123.123"
// Input: String - Pointer to destination port in the form "12345"
//
// Returns int:
// -3 : Error on Sending data
// -2 : Socket creation error
// -1 : Error on polling for data
// 0 : No error, no connection (timeout)
// 1 : Connected (connection validated with X32)
//
char r_buf[128]; // receive buffer for /info command test
char Info[8] = "/info"; // testing connection with /info request (X32, M32)
//char Info[8] = "/xinfo"; // testing connection with /xinfo request (XR series)
//
// Create UDP socket
if ((Xfd = socket (PF_INET, SOCK_DGRAM, IPPROTO_UDP)) < 0) {
////
//// Test purpose only - comment when linking the package to an application
////
//#include <stdio.h>
//int main() {
//
// char r_buf[512];
// char s_buf[] = {"/status\0"};
// int r_len = 0;
// int s_len = 0;
// int status;
//
// status = X32Connect("192.168.1.67", "10023");
// printf ("Connection status: %d\n", status);
//
// if (status) {
// s_len = X32Send(s_buf, 8);
// printf ("Send status: %d\n", s_len);
// if (s_len) {
// r_len = X32Recv(r_buf, 10);
// printf ("Recv status: %d\n", r_len);
// s_len = 0;
// while (r_len--) {
// if (r_buf[s_len] < ' ') putchar('~');
// else putchar(r_buf[s_len]);
// s_len++;
// }
// }
// }
// return 0;
//}
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <time.h>
//
#include <sys/socket.h>
#include <sys/select.h>
#include <arpa/inet.h>
//
#define BSIZE 512 // receive buffer size
#define XREMOTE_TIMEOUT 9 // time-out set to 9 seconds
#define TRUE 1
#define FALSE 0
//
// Macros:
//
#define RPOLL \
do { \
FD_ZERO (&ufds); \
FD_SET (Xfd, &ufds); \
p_status = select(Xfd+1, &ufds, NULL, NULL, &timeout); \
} while (0);
//
#define RECV \
do { \
r_len = recvfrom(Xfd, r_buf, BSIZE, 0, 0, 0); \
} while (0);
//
#define SEND(a,l) \
do { \
if (sendto (Xfd, a, l, 0, Xip_addr, Xip_len) < 0) { \
perror ("Error while sending data"); \
exit (1); \
} \
} while(0);
//
int main(int argc, char **argv)
{
struct sockaddr_in Xip;
struct sockaddr* Xip_addr = (struct sockaddr *)&Xip;
int Xfd; // X32 socket
char Xip_str[20], Xport_str[8]; // X32 IP and port
socklen_t Xip_len = sizeof(Xip); // length of addresses
fd_set ufds;
/*
* X32Ssaver.c
* (Windows environment version)
* Created on: May 7, 2015
* Author: Patrick-Gilles Maillot
*
* Copyright 2015, Patrick-Gilles Maillot
* This software is distributed under he GNU GENERAL PUBLIC LICENSE.
* Changelog:
* Use of select() rather than poll() for unblocking IO
*/
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <time.h>
//
#include <winsock2.h>
//
#define BSIZE 512 // receive buffer size
#define XREMOTE_TIMEOUT 9 // time-out set to 9 seconds
#define TRUE 1
#define FALSE 0
//
// Macros:
//
#define RPOLL \
do { \
FD_ZERO (&ufds); \
FD_SET (Xfd, &ufds); \
p_status = select(Xfd+1, &ufds, NULL, NULL, &timeout); \
} while (0);
//
#define RECV \
do { \
r_len = recvfrom(Xfd, r_buf, BSIZE, 0, 0, 0); \
} while (0);
//
#define SEND(a,l) \
do { \
if (sendto (Xfd, a, l, 0, Xip_addr, Xip_len) < 0) { \
perror ("Error while sending data"); \
exit (1); \
} \
} while(0);
//
int main(int argc, char **argv)
{
struct sockaddr_in Xip;
struct sockaddr* Xip_addr = (struct sockaddr *)&Xip;
int Xfd; // X32 socket
char Xip_str[20], Xport_str[8]; // X32 IP and port
WSADATA wsa;
int Xip_len = sizeof(Xip); // length of addresses
struct timeval timeout;
fd_set ufds;
//
int r_len, p_status; // length and status for receiving
package main
import (
"fmt"
"net"
"time"
)
// Main
func main() {
var n int
var timeold = time.Now().Add(-10000000000) // sets time to 10s before start
var timenow = timeold
var timeout = time.Duration(100000) // ReadFrom() timeout set to 100 microseconds
p := make([]byte, 1024) // 1024 bytes buffer
//
// Change IP and port as needed below
sAddr, err := net.ResolveUDPAddr("udp", "192.168.1.64:10023")
// Validate UDP connection
conn, err := net.DialUDP("udp", nil, sAddr)
if err != nil {
fmt.Printf("Connexion Error %v", err)
return
}
defer conn.Close()
// Dialog with X32
_, err = conn.Write([]byte("/info")) // /info request
n, _, err = conn.ReadFromUDP(p) // Read info data ignoring UDP address
if err == nil {
prints(n, p)
} else {
fmt.Printf("Error %v\n", err)
}
_, err = conn.Write([]byte("/status")) // /status request
n, _, err = conn.ReadFromUDP(p) // Read X32 status
if err == nil {
prints(n, p)
} else {
fmt.Printf("Error %v\n", err)
}
for { // Loop forever echoing X32 changes
timenow = time.Now()
if (timenow.Sub(timeold)).Seconds() > 9 { // every 9 seconds...
conn.Write([]byte("/xremote")) // Maintain X32 notifications
timeold = timenow // update time (use time.Now()
// if need more accuracy)
}
Compile with:
$GOROOT\bin\go.exe install -v -gcflags "-N -l"
/ c h / 0 1 / m i x / f a d e r ~ ~ ~ ~ f ~ ~ ? f f h
2f63682f30312f6d69782f6661646572000000002c6600003f666668
Some floating point values converted to big endian data as sent by/to the X32/M32 console
0.0 00000000
0.1 3dcccccd
0.2 3e4ccccd
0.3 3e99999a
0.4 3ecccccd
0.5 3f000000
0.6 3f19999a
0.7 3f333334
0.8 3f4cccce
0.9 3f666668
1.0 3f800000
Bug in FW 2.08 and 2.10: A Channel preset created from a matrix (mtx) channel does not report the right items:
the preset reports a “LowCut” section flag instead of reporting a “Dyn” section. The /preamp section (which is
not reported with a presence flag) is present but incomplete.
For further information about the OSC protocol please visit http://opensoundcontrol.org
Some text data and Effects pictures in this document: © 2012-2015 MUSIC Group IP Ltd. All rights
reserved.
Additional data, tests, program examples and text by Patrick-Gilles Maillot. © 2014-2016
All information in this document is subject to change without any further notice.