AKAI professional Z4/Z8/MPC4000 MIDI System Exclusive Protocol Specification
Introduction
This document details the specification for the MIDI System Exclusive protocol for the Akai Z4 and Z8
samplers and the sampling engine of the Akai MPC4000 Music Production Centre. System Exclusive (or
SysEx) is a feature of
for a computer (or anything else which can send customised
configure the samplers.
MIDI which allows custom information to be sent to an instrument, making it possible
MIDI SysEx messages) to remotely control and
On the samplers, SysEx messages are decoded on each port independently (A or B), so both ports can be used
at the same time if desired
†
. If the SysEx Manufacturer ID‡ is not AKAI <&47{71}>, the entire SysEx
message is ignored. To allow for feedback from a SysEx message, the out port is used to send SysEx
confirmation back to the controller (port A
received by B
).
in
confirms data received by Ain and port B
out
confirms data
out
The SysEx messages received by the samplers are buffered, so it is possible to send several messages without
pauses. However, if this is done, it is possible that the internal buffers of the samplers will fill up, resulting in
lost data. Therefore, it is recommended that the confirmation messages are used to ensure that data was
received and processed correctly.
In this document, hexadecimal notation is used where appropriate and designated by the “&” symbol. Where
this is used, decimal values are also given as follows: &
HEX{DECIMAL}.
Note: Several functions provided by the System Exclusive specification can take a noticable
amount of time to complete, which may interrupt normal (musical)
MIDI processing. Therefore, it
is recommended that only those functions specifically designed for real-time control (e.g.,
adjustment of some Multi parameters) be used when normal
real-time items are marked with the (
) symbol in this document.
RT
MIDI information is being sent. Such
†.
If ports A and B are used simultaneously for SysEx transmissions, care should be taken to ensure that the function performed
on one port does not depend on the completion of a function on another port.
‡.
The standard format of a SysEx message is “<&F0> <Manufactured ID> … <&F7>”, where the Manufacturer ID is assigned by the
sures that instruments from other manufacturers will ignore SysEx messages not intended for them.
MIDI Manufacturers’ Association. The assigned ID for AKAI is &47{71}. The use of a manufacturer ID en-
•Several additional errors were corrected throughout the document.
†.
AKAI professional M.I. Corp. reserve the right to change this SysEx specification without prior notice. However, such
changes are likely to be minimal, only being implemented to improve the performance of the product. If you encounter
problems, please ensure that you are using the latest SysEx document.
AKAI professional Z4/Z8/MPC4000 MIDI System Exclusive Protocol Specification
System Exclusive Protocol
The System Exclusive feature is used to remotely control and configure the sampler. To provide feedback to
the host (e.g., a
of and after processing of viable SysEx messages. If desired, this confirmation can be turned off via SysEx
commands.
Control Message Format
To allow several devices to coexist on the same MIDI bus used for system exclusive messages, several
identifiers are used by the Z4/Z8/MPC4000 to ensure that it only responds to those messages which are
intended for it. Thus, all system exclusive messages begin with the following bytes:
Where the values of the bytes are:<&F0> <&47> <&5F> <0..&7F> …
AKAI ID <&47{71}> and Z4/Z8/MPC4000 ID <&5F{95}>
The AKAI ID and the Z4/Z8/MPC4000 ID ensure that only AKAI Z4/Z8/MPC4000 samplers respond to
these messages.
PC or MAC) the MIDI out port is used to transmit SysEx confirmation messages upon reception
The user-selectable DeviceID allows more than one AKAI Z4/Z8/MPC4000 sampler to coexist on the same
MIDI bus, but be configured independently via SysEx. The default DeviceID is zero.
The DeviceID has been limited to the range: 0–31. This is because the top 2 bits (bits 5 and 6) are used to
determine the number of User-Ref bytes being sent— bits 0–4 represent the DeviceID. The number of UserRefs expected is as shown in Table 1. This then provides a flexible means of sending User-Ref bytes; zero
bytes to conserve bandwidth, more bytes if required by your application. Moreover, this method allows the
number of User-Refs sent to vary on a per-message basis.
Table 1: Number of User-Refs Being Sent
Device ID bit 6 Device ID bit 5 Num User-Refs
000
011
102
113
Note: If the Z4/Z8/MPC4000 is set to have a user-selectable DeviceID of zero (0), then it will
respond to all SysEx messages regardless of the DeviceID transmitted. Similarly, if a DeviceID
of zero is transmitted by the controller (i.e., bits 0–4 = 0), all Z4/Z8/MPC4000s will respond
regardless of which DeviceID is set.
For non-zero DeviceIDs, the sampler will only respond to SysEx messages if its DeviceID
matches that sent.
User-Refs <0..&7F {0..127}>
The User-Ref parameters can be set to any value. It is only useful when confirmation messages are enabled
(or if a
REPLY is requested) where the User-Ref parameter is echoed with every confirmation message. This
is to allow flexibility in the design of control software where each SysEx message can be stamped with an ID
AKAI professional Z4/Z8/MPC4000 MIDI System Exclusive Protocol Specification
so that the confirmation messages can be matched to the commands sent. This is especially useful if the
control software sends buffered messages out-of-sequence.
Either 0, 1, 2, or 3 User-Refs can be sent with any message. To allow for this, the top 2 bits of the DeviceID
contain a count of the number of User-Refs which will be sent. The default number of User-Refs is 0: see
Table 1 for more details.
In this document, optional User-Refs will be shown as:
<…>.
Checksums
The checksum provides a means of error-detection in the SysEx message. The checksum is a single data byte
sent as the last item before the End-of-SysEx byte <&F7{247}>. By default, checksums are disabled making
sending SysEx messages as simple as possible. Enabling and disabling of checksums can only be done via
SysEx messages.
Note that because the SysEx specification for the Z4/Z8/MPC4000 supports a variable number of parameters,
if checksums are disabled, the calculated checksums may still be transmitted; although they will be ignored.
A checksum calculation begins at the first User-Ref byte (if any) — there is no point in calculating the
checksum earlier than this because if an error occurs in the first bytes, the SysEx message will be ignored
anyway — and the calculation stops before the End-of-SysEx byte.
To calculate the checksum, unsigned 8-bit addition is used, which wraps on overflow (i.e., 255+1 = 0). To
ensure compatibility with the
MIDI data byte specification, the high-bit of the checksum is set to zero (logical
AND with &7F{127}) once the checksum has been calculated.
This allows the selection of various Sections, such as “Multi”, “Sample”, “Program”, “Config”, and the
variable number of data parameters allows the efficient passing of strings (which, for example, are used to
name programs, multis, etc.). The Section numbers are detailed in Table 4.
If extensive use is made of the System Exclusive protocol, it is recommended that checksums are
enabled so that transmission errors can be detected and handled.
The first 6 bytes (or more if <User-Refs> are used) are the same as those transmitted in the original message,
except that the
<Reply ID> item has been inserted. This format ensures that confirmation messages from
different devices can be distinguished, and the insertion of the
messages are not confused with other SysEx messages. Moreover, the
be used by a controlling computer to determine which SysEx message generated the confirmation message.
The values of Reply ID and Data1 … DataN are explained in Table 2. Note that the
sent if checksums are enabled (see Table 6).
Table 2: SysEx Confirmation Messages
Reply IDData1Data2Meaning
&4F{79} ‘O’
&44{68} ‘D’
&52{82} ‘R’Reply TypeReply 1…“
&45{69} ‘E’<
NANA“OK” Valid SysEx has been received and is being processed.
NANA“DONE” SysEx instruction has been completed successfully.
LSB 0–127><MSB 0–127> “ERROR” An error has occurred, Error Number = Data1 + 128×Data2
<DataN> <checksum> <&F7>
<Reply ID> item ensures that confirmation
<User-Ref>, <Section> and <Item> can
<checksum> will only be
REPLY” A variable number of bytes is returned as a reply (data
returned depends on SysEx message sent). Every piece of reply data
is preceded with a single
making it easier to interpret the data received.
The values of these
ID byte indicating the type of data following,
ID bytes are shown in Table 5.
Note that because the user-selectable DeviceID is returned in these messages, a controller can establish the
number of devices and their DeviceIDs connected in a chain by using the “Query” SysEx command with the
DeviceID set to be zero (all devices), which will return an “
the chain. The DeviceID will also have it’s top 2 bits set to show how many
the message (see Table 1 for more information). The number of and the values of
OK” and a “DONE” message from each sampler in
<User-Ref> bytes are included in
<User-Ref> bytes in the
confirmation message will always be the same as those in the message which caused the confirmation
message to be generated.
The normal flow of confirmation messages is that the “
OK” message will be transmitted as soon as a valid
Sysex message (i.e., manufacturer = &47{71}, model = &5F{95}, DeviceID = set value) has been received.
If there is an error in this message, or the message is unsupported, then the “
ERROR” confirmation message
will be returned—possible error numbers are explained in Table 3. If the message is supported, the function
will be performed then, once processing is complete, the “
Alternatively, if a request for information was issued, the “
message with the appropriate data contained within it. Note that it is possible, but unlikely, that a “
message may be followed by an “
ERROR” message if an error occurred during the generation of the reply.
DONE” confirmation message will be transmitted.
DONE” message will be replaced by a “REPLY”
REPLY”
Note: Although “OK”, confirmation messages can be turned on and off via SysEx, the “DONE”
“
REPLY” and “ERROR” messages cannot. This is to ensure that at least one message is returned for
every SysEx message received; thus making synchronisation of a controller easier.
AKAI professional Z4/Z8/MPC4000 MIDI System Exclusive Protocol Specification
Table 3: Error Numbers Returned
Error NumberMSBLSBDescription of Error
&202{514}42WAV format is incorrect
&203{515}43File not found
&204{516}44File already exists
Control Messages
The functions of the Z4/Z8/MPC4000 which can be controlled via SysEx are grouped into Sections. For
example, there is a section to configure a Multi, and a section to change the
Sections then have several functions associated with them, called an Item. Thus each SysEx control message
consists of the appropriate device header:
AKAI professional Z4/Z8/MPC4000 MIDI System Exclusive Protocol Specification
Format of Message Data
The Z4/8 SysEx protocol supports variable-length messages, making it both flexible and adaptable.
Therefore, it is possible to send differently formatted data depending on the function to be performed and in
some cases, more than one piece of data is required in a single message. The format of the data required in
the messages should be strictly followed to avoid problems — although in most cases, an incorrect message
will simply generate an
Note
: Data bytes sent within SysEx messages must not exceed a value of 127 (or &7F). This
limitation is imposed by the
ERROR confirmation message.
MIDI specification. Failure to observe this limit may lead to undefined
behaviour!
Numeric data is always sent as 7-bit bytes (i.e., the top bit of each byte must be zero). Numbers which require
more than one byte to represent them are always sent least-significant byte first. Character strings can be any
length, but must always have a terminating character of value zero. A summary of all the data types is given
in Table 5. Note that the data format
ID is the value returned with every piece of reply data in confirmation
messages, a feature which makes automatic decoding of replies easier.
Table 5: SysEx Data Formats
Name IDByte FormatDescription (Range)
BYTE1<value>byte (0–127)
SBYTE2<sign><value>signed byte (±127)
WORD3<LSB><MSB>word (0–16383)
SWORD 4<sign><LSB><MSB>signed word (±16383)
DWORD 5<LSB><SB1><SB2><MSB>double word (0–268,435,455)
SDWORD 6<sign><LSB><SB1><SB2><MSB>signed double word (±268,435,455)
QWORD 7<B1><B2><B3><B4><B5><B6><B7><B8>quad word (0–72,057,594,037,927,935)
SQWORD 8<sign><B1><B2><B3><B4><B5><B6><B7><B8> signed quad word (±72,057,594,037,927,935)
BYTES 10<value1><value2>2 data bytes (command-specific)
2
3
BYTES 11<value1><value2><value3>3 data bytes (command-specific)
CUSTOM 32specific to commandCustom data (command-specific)
a. <sign>: 0 = positive, 1 = negative.
a
Arrays
If an array of values is to be sent, this is indicated by [n] following the data type. For example, an array of
signed bytes with 10 entries would be shown as
SBYTE[10].
Use of Ellipsis
The ellipsis, “…”, is used to illustrate that more data may be transmitted than the explicit data values shown
in the tables. For example, <Data1>…<DataeN> means that there may be additional bytes between Data1 and
DataN. The number of additional bytes depends on the both format and the content of the data being sent.
AKAI professional Z4/Z8/MPC4000 MIDI System Exclusive Protocol Specification
Item List for SysEx Configuration section [&00{0}]
These options control how the sampler responds to SysEx messages. These options only apply to the
MIDI
port on which the SysEx command was sent. This allows different applications to coexist on different ports
without interfering with the other’s communications. For example, problems would arise if port A disabled
checksums when port B required them.
To ensure that operations on one port do not interfere with those on another, LCD
Note:
synchronisation should be turned off when it is not essential (e.g., if editing a program) and only
used when required, e.g., when selecting the current multi to be played.
Table 6: Control Items for Section &00{0} — SysEx Configuration
<Item><Data1><Data2>Description of Item
&00{0}
RT
&01{1}
RT
&03{3}
&04{4}
&05{5}
&06{6}
&07{7}
b
RT
RT
RT
RT
d
RT
&08{8}BYTE(0, 1)NAEnable/Disable synchronisation between the current playback item
&10{16}
RT
a. The state of this option at power-on is ON.
b. Note that if synchronisation is enabled and the current muti, program or sample is changed by SysEx on a different port which also
has synchronisation enabled, the currently selected item on the current port will also change because the item displayed on the
will have changed. To avoid this situation, synchronisation should be turned off, and enabled only when required.
c. The state of this option at power-on is OFF.
d. Some SysEx messages may require substantial time to execute. This can result in large delays between an OK and a DONE (or REPLY/
ERROR) message which the host could interpret as “samper not responding”. To avoid this, if the Still Alive monitor is enabled, a NULL
message (<&F0><&F7>) will be transmitted to the host approximately every second, whilst the host is awaiting a response.
NANA“Query” — use with user-selectable DeviceID=0 to get an “OK!” and
a “DONE” reply with DeviceID returned
BYTE(0, 1)NAEnable/Disable received message notification (“OK!”)
<Data1> = (0=
BYTE(0, 1)NAEnable/Disable synchronisation between the currently selected
OFF, 1=ON)
samples/programs/multis and those displayed on the front-panel