📄 midi3.htm
字号:
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=gb2312">
<title>midi sample dump standard</title>
<meta name="generator" content="microsoft frontpage 3.0">
</head>
<body background="../jpg/di1.JPG">
<p align="center"><font size="6" color="#0000ff">midi sample dump standard</font></p>
<div align="center"><center>
<table border="0" width="88%">
<tr>
<td width="100%"><strong><font size="5">index</font></strong><br>
<br>
1) <a href="#1) introduction">introduction</a><br>
2) <a href="#2) spec: sample du">spec: sample dump formats</a><br>
3) <a href="#3) spec: sample dump messages">spec: sample dump messages</a><br>
4) <a href="#4) dump procedure: m">dump procedure: master (dump source)</a><br>
5) <a href="#5) dump procedure: slave (dump destination)">dump procedure: slave (dump
destination)</a><br>
6) <a href="#6) sds overview">sds overview</a><p><a name="1) introduction">1) introduction</a><br>
<br>
the midi sds was adopted in january 1986 by the midi<br>
manufacturers association and the japanese midi standards committee.<br>
the sds defines the standard method for transfer of sound sample data<br>
between midi-equipped devices. sample dumps may be accomplished with<br>
either an 'open loop' or 'closed loop' system. the open loop method<br>
simply involves the straight dump of all sample data from its source<br>
to the destination, with no timeouts, packet acknowledgements, or any<br>
other form of handshaking, much as in the manner of a sysex bulk dump,<br>
usually intiated at the source. the closed loop method allows the use<br>
of handshaking messages between the dump source and destination, and<br>
usually places the dump process under the control of the slave, to<br>
allow it time to process the incoming data as necessary. as with any<br>
standard, it can not be assumed that a device adheres to it unless the<br>
accompanying documentation specifically indicates it. even then, it is<br>
best to check its conformity with non-critical data.<br>
<br>
<a name="2) spec: sample du">2) spec: sample du</a>mp formats<br>
<br>
dump header:<br>
<br>
f0 7e cc 01 ss ss ee ff ff ff gg gg gg hh hh hh ii ii ii jj f7<br>
<br>
where<br>
<br>
cc = channel number<br>
ss ss = sample number (lsb first)<br>
ee = sample format (number of significant bits; 8->28)<br>
ff ff ff = sample period (1/sample rate) in nanoseconds (lsb first)<br>
gg gg gg = sample length, in words<br>
hh hh hh = sustain loop start point (word number) (lsb first)<br>
ii ii ii = sustain loop end point (word number) (lsb first)<br>
jj = loop type (00:forwards only; 01:alternating)<br>
<br>
data packet:<br>
<br>
f0 7e cc 02 kk <120 bytes> mm f7<br>
<br>
where<br>
<br>
cc = channel number<br>
kk = running packet count (00->7f)<br>
mm = checksum (xor of 7e, cc, 02, kk <120 bytes>)<br>
<br>
the total size of a data packet is 127 bytes. this is to avoid<br>
overflow of the midi input buffer of a device that may want to receive<br>
an entire packet before processing it.<br>
a data packet consists of its own header, a packet number, 120<br>
bytes of data, a checksum, and an eox. the packet number begins at 00<br>
and increments with each new packet. it resets to 00 after it reaches<br>
7f, and continues counting. the packet number is used by the receiver<br>
to distinguish between a new data packet, or a resend of a previous<br>
packet. the packet number is followed by 120 bytes of data, which form<br>
60, 40, or 30 words (msb first for multiword samples), depending on<br>
the length of a single data sample.<br>
each data byte hold seven bits, with the msb in each byte set to<br>
0, in order to conform to the requirements of midi data transmission.<br>
information is left justified within the 7-bit bytes, and unused bits<br>
are filled with 0.<br>
example: assume a data point in the memory of a 16-bit sampler,<br>
with the value 87e5. in binary, that would be<br>
<br>
1000 0111 1110 0101<br>
<br>
and would be encoded as the following midi data stream:<br>
<br>
01000011 01111001 00100000<br>
<br>
the checksum is the running xor of all the data after the sysex<br>
byte, up to but not including the checksum itself.<br>
<br>
<a name="3) spec: sample dump messages">3) spec: sample dump messages<br>
</a><br>
dump request:<br>
<br>
f0 7e cc 03 ss ss f7<br>
<br>
where<br>
<br>
cc = channel number<br>
ss ss = sample number requested (lsb first)<br>
<br>
upon receiving the request, the sampler checks the sample number<br>
to see if it is within legal range. if it is not, the request is<br>
ignored. if it is, the sample dump is started. one packet at a time is<br>
sent, under control of the handshaking messages outlined below.<br>
<br>
handshaking messages:<br>
<br>
for all below:<br>
<br>
cc = channel number<br>
pp = packet number<br>
<br>
packet numbers are included in the handshaking messages to<br>
accomodate machines that have the intelligence to re-transmit specific<br>
packets after an entire dump is finished, or if synchronization is<br>
lost.<br>
<br>
ack : f0 7e cc 7f pp f7<br>
<br>
means last packet was recieved correctly (checksum ok, etc),<br>
please send next one. packet number is packet being acknowledged as<br>
correct.<br>
<br>
nak : f0 7e cc 7e pp f7<br>
<br>
means last packet not received correctly, please send again.<br>
packet number is packet being rejected.<br>
<br>
cancel : f0 7e cc 7d pp f7<br>
<br>
means abort dump immediately. packet number is packet on which<br>
abort occurs.<br>
<br>
wait : f0 7e cc 7c pp f7<br>
<br>
means pause dump indefinitely, until next message is sent. allows<br>
the unit recieving the dump to perform other functions (disk access,<br>
etc), before receiving the remainder of the dump. the next message it<br>
sends (eg ack, abort) will determine if the dump continues or aborts.<br>
<br>
<a name="4) dump procedure: m">4) dump procedure: m</a>aster (dump source)<br>
<br>
once a dump has been requested, either via midi or through the<br>
front panel, the dump header is sent. after sending the header, the<br>
master must time out for at least two seconds, to allow the receiver<br>
to decide if it will accept this sample (has enough memory, etc).<br>
if it receives a cancel, within this time, it should abort<br>
immediately. if it receives an cak, it will start sending packets<br>
immediately. if it receives a wait, it pauses until another message is<br>
received, and then processes that mesage normally. if nothing is<br>
recieved within the timeout, an open loop is assumed, and the dump<br>
starts with the first packet.<br>
after sending each packet, the master should time out for at<br>
least 20 milliseconds and watch its midi in. if an ack is received, it<br>
sends the next packet immediately. if it receives an nak, and the<br>
packet number matches the number of the last packet sent, it resend<br>
that packet if the packet numbers don't match, and the device is<br>
incapable of sending packets out of order, the nak will be ignored.<br>
if a wait is received, the master should watch its midi in port<br>
indefinitely for another ack, nak, or cancel message, which it should<br>
then process normally.<br>
if no messages are received within 20 milliseconds of the<br>
transmission of a packet, the master may assume an open loop<br>
configuration, and send the next packet.<br>
this process continues until there are less than 121 data bytes<br>
to send. the final packet will still consist of 120n bytes, regardless<br>
of how many significant bytes actually remain, and the unused bytes<br>
will be filled with zeroes. the receiver should handshake after<br>
receiving the last packet.<br>
<br>
<a name="5) dump procedure: slave (dump destination)">5) dump procedure: slave (dump
destination)<br>
</a><br>
when receiving a sample dump, a device should keep a running<br>
checksum during reception. if its checksum matches the checksum in the<br>
data packet, it will send an ack and wait for the next packet. if it<br>
does not match, it will send an nak containing the number of the<br>
packet that caused the error, and wait for the next packet. if, after<br>
sending an nak, the packet number of the next packet doesn't match the<br>
previous packet number (the one that was nak'd), and the unit is not<br>
capable of accepting packets out of order, the error is ignored and<br>
the dump continues as if the checksums had matched.<br>
if a receiver runs out of memory before the dumpo is completed,<br>
it should send a cancel to stop the dump.<br>
<br>
<a name="6) sds overview">6) sds overview</a><br>
<br>
sample dump data format: dump header:<br>
<br>
sysex<br>
id: universal non-real time<br>
channel number<br>
sub id: header<br>
sample number (2 bytes, lsb first)<br>
sample format<br>
sample period (3 bytes, lsb first)<br>
sample length (3 bytes, lsb first)<br>
sustain loop start point (3 bytes, lsb first)<br>
sustain loop end point (3 bytes, lsb first)<br>
loop type<br>
eox<br>
<br>
sample dump data format: data packet:<br>
<br>
sysex<br>
id: universal non-real time<br>
channel number<br>
sub id: data packet<br>
packet number<br>
sample data (120 bytes)<br>
checksum<br>
eox<br>
<br>
sample dump messages: dump request:<br>
<br>
sysex<br>
id: universal non-real time<br>
channel number<br>
sub id: dump request<br>
sample number (2 bytes, lsb first)<br>
eox<br>
<br>
sample dump messages: handshaking flags:<br>
<br>
sysex<br>
id: universal non-real time<br>
channel number<br>
sub id: ack or nak or cancel or wait<br>
packet number<br>
eox</td>
</tr>
</table>
</center></div>
<p align="center"><a href="../index.htm">返回</a></p>
</body>
</html>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -