The Akai video switch is a video-bandwidth crossbar switch, which can switch large numbers of video and audio ports into each other. It has separate input and output ports (ie. input port 16 is on a different connector from output port 16). Many output ports can be fed from a single input port, but obviously each output port must have a unique input port.
Throughout this document, Input port shall mean a port feeding into the switch from an external source such as a video camera, and Output port shall mean a port feeding out of the switch into an external sink, such as a video monitor.
Video and audio ports are switch separately: video ports are numbered from 16 to (16+(ports-1)) and audio ports are numbered from 0 to (ports-1). Input ports and output ports are numbered in different address spaces, so input port 12 and output port 12 are on completely different connectors.
The switch we have has 32 (16+16) video and 32 (16+16) audio ports, so the audio ports are internally numbered from 0..15 and the video ports from 16..31 (note that on the outside of the switch ports are, confusingly, numbered from 1 rather than from 0. Score one for the Stupid team...).
The Akai switch considers the MIDI link to pass integers between 0 and 255 (ie. bytes) in both directions. It requires only simplex connection.
The video switch considers itself to assign input ports to output ports, and you are expected to know in advance how many ports it has (there is apparently no way of reading it).
The protocol is command-response: you send a command (typically as an integer), followed by an operand, and optionally read an integer reply from the board. Each command is therefore between one (eg. DUMMY) and three (eg. SOURCE_PORT) bytes long. Typical code to send commands is of the form:
sendInt(SOURCE_REQUEST); sendInt(15+2); // Port 2 (marked as 3 externally) in = readInt();The following commands are defined. Those marked `follow with dummy' must be followed by a DUMMY command. A return value of (ignore) means that a value is returned, but I don't know what it is, so you should read it and then throw it away. A return value of Nothing, however, means that no value is returned, and you should not attempt to read the return value, because the video switch will make demons fly out of your nose if you do.
| Constant | Purpose | Value (hex) | Operand | Returns |
| CHANGE_DEVICE | ORed with the device number (0-F) and sent to select device. | 0xF0 | DUMMY | (ignore) |
| ALL_RESET | Reset. | 0x97 | DUMMY | (ignore) |
| BANK_REQUEST | ? | 0xA0 | DUMMY | ? |
| OUT_PORT_SET | Set the output port for this connect operation (?). | 0x82 | Output port number. | ? |
| SOURCE_PORT_SET | Set the input port for this connect operation. | 0x83 | Input port number. | Nothing |
| SOURCE_REQUEST | Request the number of the input port feeding the operand port. | 0xA3 | Output port number. | Input port number. |
| DUMMY | A space-filler for commands with no operand. | 0x01 | Has no operand. | Nothing |
Additionally, whenever a port is requested, supplying NO_PORT_AT_ALL (0x20) will cause the video-switch equivalent of /dev/null to be used: data from input ports will be thrown away and output ports will recieve nothing.
Detailed instructions are available on how to:
Finally, repeat your request for the source of B. QSF does this, but I'm not sure if it's necessary, except to check that the operation has in fact happened.
You can send NO_PORT_AT_ALL (0x20) as A to disconnect B from its current input channel.