Kurzweil 1000 Series Developer Information
Kurzweil Music Systems, Inc.
Contents of this package: 1. 2. 3. 4. Kurzweil 1000 Series MIDI Implementation Kurzweil 1000 Series MIDI System Exclusive Messages Kurzweil 1000 Series Binary Data Transfer Protocol How to talk to the K1000 over MIDI. Kurzweil 1000 Series Object Overview Describes the basic structure of K1000 binary objects. Illustrated!
Kurzweil 1000 Series MIDI Implementation
1st Edition: March 88 MIDI Modes The 1000 series currently supports three modes of MIDI reception: Omni On/Poly, Omni Off/Poly and Multi. In Omni On mode, the channel number is ignored. In Omni Off (aka Poly) mode, only messages received on the basic channel are recognized. In Multi mode, all enabled MIDI channels are recognized. Note Ons and Offs NOTE: The 1000 series products (in fact, all Kurzweil products) refer to Middle C (MIDI key number 60) as C4, in contrast to numerous software products which mistakenly call it C3. This is, as far as we know, an international standard to which weve been adhering since before we ever heard of MIDI. Included with this document is an appendix which lists the key numbers and their proper names. The 1000 series responds to the entire range of MIDI key numbers although the actual, playable range depends on the selected program. (E.g., some of the sampled instruments have natural ranges which do not cover the entire keyboard.) It is also possible to restrict the MIDI key range on an individual MIDI channel via the master parameters. In general most programs respond over the range C0 (=12) thru C8 (=108). The 1000 series also allows multi-layered programs, in which a single MIDI Note On may start multiple voices in the instrument. This technique is provided to allow creation of complex timbres from combinations of raw sounds; there is no efficiency gain by using layers. I.e., it takes the instrument just as long to start four layers from a single MIDI note on as it does to start four individual notes. The lowest octave of key numbers, C-1 (=0) thru B-1 (=11), is available to control the intonation table reference key. When used with a suitable MIDI controller, this allows chromatic modulation in real-time while using a nonequally tempered intonation. In the K1000 keyboard instrument, Note Offs are transmitted using the MIDI Note Off message $8x kkk vvv. This can cause problems with certain simple minded MIDI processors (such as the Yamaha MEP4) which transpose the MIDI stream by only altering key numbers in Note On messages ($9x) on the assumption that the MIDI controller is sending Note Offs as zero velocity Note Ons. Currently, there is no solution to this problem but future versions of the software will add a master parameter to select the type of Note Off (real Note Off or zero velocity Note On) which is transmitted. There is a layer-level parameter which allows the Note Off message to be ignored. This is provided so that programs can be created which play through their envelopes completely, until each note decays to silence. If the envelope doesnt decay, the note will sustain indefinitely. In 1000 series software, both attack and release velocity are available (in normal and inverse form) as internal control sources; programs can be created which respond to these parameters. When a note is started, its release velocity is set to zero (and inverse release velocity is set to one). When the Note Off is received, the actual release velocity becomes available. Zero velocity Note Ons which are received are treated as Note Offs with a velocity of 64. Program Changes The 1000 series responds to the full range of MIDI program change numbers. The numbers are mapped through an editable list (selected by the master parameter RxPMap) which selects the real, internal program number. Program

121 All Controls Off When this message is received, all controls are reset to zero, with the following exceptions: volume (#7 and #39) is set to maximum ($7FFF), balance (#8 and #40) and pan (#10 and #42) are set to center point ($4000). 122 Local Control On/Off This message is only recognized by the K1000 on the basic MIDI channel (it is ignored in rack-mount equipment). 123 All Notes Off The All Notes Off message is recognized in all MIDI modes. In particular, it is not ignored in Omni On mode. This is contrary to the MIDI spec but represents the unanimous opinion of our users. NOTE: most Roland equipment (e.g., MKB-1000, D-50, etc.) sends an All Notes Off message when all the keys are released. In order to deal with this, the 1000 series includes a master parameter which allows you to ignore the all notes off message. We call it the "Roland Switch." And I just discovered (as I am working on this document) that Kawai equipment exhibits the same behavior. 124 Omni Off 125 Omni On When not in Multi Mode, the Omni On/Off messages are recognized on the basic MIDI channel only. In Multi Mode, these messages are ignored. This is contrary to the MIDI spec but represents the unanimous opinion of our users. When the instrument is in edit mode, the following control numbers are also recognized: Data Entry Slider MSB Data Entry Slider LSB Data Increment Data Decrement The data entry slider (control numbers 6 and 38) and the data increment/decrement buttons (control numbers 96 and 97) are recognized when the instrument is in edit mode.
98 Non-Registered Parameter Select LSB 99 Non-Registered Parameter Select MSB When the instrument is in edit mode, the non-registered parameter select MSB selects the edit menu and the LSB selects the parameter within the menu. However, because the menu selection varies based on high or low level editing mode and in some cases (e.g., envelopes) the actual parameter list varies, there is no absolute mapping between select values and actual parameters. Pitch Wheel Currently, the pitch wheel is the only MIDI control which has an internal range which is bipolar (i.e., 1). The actual conversion from MIDI data values to internal form is pitch wheel value = 256 * MSB + 2 * LSB - $4000 Future implementations of the software will provide an absolute value pitch wheel control source with a range of 0 to 1 in both directions, to allow effects to be tied to pitch bending in either direction. Mono and Poly Pressure Both Mono Pressure and Poly Pressure messages are recognized. Internally they are treated as additional control sources but their internal values are derived by a mapping table rather than a direct conversion. Note that both pressure sources are treated as separate entities. Thus it is possible to create programs which have separate responses to

both Mono and Poly Pressure, provided you have a MIDI controller which transmits both. On the other hand, a program which responds to Poly Pressure will not respond to Mono Pressure, and vice versa. Future versions of the software will provide some master parameter to allow global selection of the pressure source. Poly Pressure messages are only recognized for keys which have notes playing. Note that Poly Pressure messages transmitted after a Note Off message has been received may still be acted upon if the note is still playing (e.g., as a result of a slow decay). This can actually occur if you strike the same key twice. If the envelope has a long decay, the pressure messages for the new note will also affect the previous note.
System Common/Real-Time All system common (except for System Elusives [SIC]) and real-time messages are ignored. Note Names and Key Numbers Octave -9 C 120 C# 121 D 122 D# 123 E 124 F 125 F# 126 G 127 G# A A# B 107
Kurzweil 1000 Series System Exclusive Messages
2nd Edition: April 88 1st Edition: February 88 The 2nd edition of this document provides a correction to the front panel button code list. These notes describe the current state of system exclusive messages in the K1000 series. All values are expressed in hexadecimal. Version Request The K1000 responds to the standard MIDI version request message: $F0 $7E <device ID> $06 $01 $F7 ; request
The 1000 defaults to a device ID of $00, although it may be set to any value from $00 to $7F $F0 $7E <device ID> $06 $02 $07 p1 p2 p3 p4 e1 e2 s1 s2 ; ; ; ; ; response Kurzweil ID product ID engine software version setup software version
$F7 p1 through p4 represent four hexadecimal numerals which constitute the product ID. p1 is the major product heading (150 FS, 250, or 1000), and p2 through p4 distinguish the various models within the major headings. The product code for a 1000 GX, for example, would be: p1 = $64; p2 = $01; p3 = $04; p4 = $00. The table below shows the codes for all Kurzweil products with SysEx capabilities. ID# $15 $19 $64 Product K150 K250 or 250RMX 1000PX PX Plus 1000SX 1000HX 1000GX AX Plus 1200 Pro K1000 SE 1000EX EGP
$01 $01 $01 $01 $01 $01 $01 $02 $03 $04 p2
$00 $01 $02 $03 $04 $05 $05 $01 $01 $01 p3
$00 $01 $00 $00 $00 $00 $02 $00 $01 $00 p4
e1, e2, s1, and s2 represent the hexadecimal values indicating the software version of the 1000. e1 and e2 indicate the engine (operating system) software, which is common to all 1000 Series products. s1 and s2 indicate the setup software. It is the setup software which distinguishes a GX from a PX, etc. For both engine and setup software, the first numeral is the major version number, and the second is the subversion, if any. For example, version 1.0 would be represented as $01 $00. Version 2.14 would be $02 $0E.

System Exclusive Messages
Remote Front Panel The remote front panel messages allow control of the 1000 series over MIDI. The format of the message is $F0 $07 <device ID> $64 $01 <buttons> $F7 where $64 is the major product ID (i.e., 1000 series) and <buttons> are any number of button codes: Code $00 $09 $10 $11 $12 $13 $14 $15 $16 $17 $18 $19 $1A $1B $1C $20 $21 $22 $7F Button digit 0. digit 9 play/edit mode/layer chan/menu increment chan/menu decrement chan/menu incr & decr (double press) prog/param increment prog/param decrement prog/param incr & decr (double press) value increment/yes value decrement/no value incr & decr (double press) enter store bank A bank B bank C send display
(K1000 only) (K1000 only)
(K1000 only) (K1000 only) (K1000 only) (K1000 only) (K1000 only)
Whenever the special "send display" button ($7F) is sent, the K1000 responds with $F0 $07 <device ID> $64 $02 <display text> $F7 where <display text> is the contents of the K1000 display as ordinary ASCII characters. Dump Request Message $F0 $F7 This message may be used to request a dump of any object or group of objects in the 1000s memory. The type and ID number select the object to be dumped. A type of $00 means all types and and ID number of $00 means all objects of the requested type. If the RAM-flag is true (i.e., not zero) only objects stored in non-volatile RAM will be dumped. For example, to request a dump of all RAM based programs, use: $F0 $07 <device ID> $64 $03 $00 $50 $00 $00 $01 $F7 $07 <device ID> $64 $03 <type-msb> <type-lsb> <id-msb> <id-lsb> <RAM-flag>
To request a dump of the Master Parameter Table, use: $F0 $07 <device ID> $64 $03 $00 $42 $00 $00 $01 $F7
To request a memory dump (User Objects and RAM), use: $F0 $07 <device ID> $64 $03 $00 $42 $00 $10 $01 $F7
Channel Setup Message $F0 $F7 This message may be used to set the MIDI mode (Omni, Poly, or Multi) and to enable or disable specific MIDI channels. If <chan-a> (or subsequent) = $00, then it signals a mode change. A value of $01 for <mode-a> (or later) indicates Omni mode, $02 is Poly, and $03 is Multi. If <chan-b> or subsequent is $01 through $10 (16), it is read as a MIDI channel number. In this case, the following <mode> byte value determines whether that MIDI channel is active. $00 enables the channel, and $01 disables it. For example, to put the instrument in Multi mode, with channels 1 thru 4 enabled, use: $F0 $07 $01 $05 $09 $0D <device $00 $02 $01 $06 $01 $0A $01 $0E ID> $00 $01 $01 $01 $64 $03 $07 $0B $0F $04 $00 $01 $01 $01 $00 $04 $08 $0C $10 $03 $00 $01 $01 $01 ; ; ; ; ; multi mode enable 1-4 disable 5-8 disable 9-12 disable 12-16 $07 <device ID> $64 $04 <chan-a> <mode-a> <chan-b> <mode-b>.

Kurzweil 1000 Series Binary Data Transfer Protocol
2nd Edition: April 88 1st Edition: February 88 Notes on 2nd Edition The 2nd edition of this document corrects an error in the description of the data packet checksum. The checksum is computed over the data bytes only and does not include the packet number and size as the previous document described. Introduction to the 1st Edition These notes describe a simple(?) mechanism for reliable binary (eight bit) data transmission over MIDI. The implementation is a two level approach; the transmission of binary information is separated from the purpose (e.g., file transfer) of the information. First, a basic packet level protocol is defined which allows for bidirectional exchange of binary (eight bit) data packets with error checking and re-transmission. This protocol features a synchronization sequence which allows both parties to negotiate details such as transmission speed (to allow for higher-than-MIDI baud rates), packet size and number of outstanding packets (for machines with large buffers). Within the context of the packet protocol, higher level protocols may then be defined to implement various forms of data transfer (remote file systems, interactive streams, etc). This protocol, as described, is currently implemented on the new 1000 series of rack-mount MIDI expanders as well as the new K1000 keyboard. A description of the 1000 data transfer messages is also included, to illustrate how the packet protocol may be used. The Packet Level The following description assumes a bidirectional link (closed loop) between the two parties. There is a brief discussion at the end of this section on how the protocol behaves in an open loop situation. Message Format All messages are transmitted as standard Kurzweil system exclusive messages of the form: $F0 $07 <dev-ID> <mesg-ID> <data.> $F7 Normally, in Kurzweil system exclusives, the <mesg-ID> byte is actually a product ID. Since this protocol is intended to apply to a variety of products, we use a certain range of the number space for message ids: $78-$7B $7C $7E $7F The Hand Shake To exchange data packets (in either direction), the parties at either ends of the MIDI cable must be in sync. Not physical sync, since we are transmitted data asynchronously, but logical sync, in which each party begins in the Sync Messages (levels 0 thru 3) Data Packet Data Packet acknowledged (ACK) Data Packet not acknowledged (NAK)

Binary Data Transfer Protocol
same state. The synchronization process consists of exchanging handshake messages which specify the desired transmission parameters (speed, packet size, etc.). These messages have the form $F0 $07 <dst-ID> <syncN> <src-ID> <xSpeed> <nPacks> <pSizeH> <pSizeL> $F7
The elements of this message are dst-ID The device ID of the destination. SYNC0 ($78) messages may be sent with a device ID of 127 as a general request for sync. syncN The message ID ($78 thru $7B), which includes the partys current synchronization state. src-ID The device ID of the transmitter (0 thru 126). xSpeed The desired transmission speed (1x, 2x, 4x, etc.). nPacks The maximum number of outstanding packets (1 thru 127). pSize The maximum number of eight bit bytes that will be transmitted in a packet (a 14 bit value sent as two seven bit values).
All sync sequences begin at level 0 with both parties transmitting at standard MIDI speed. A party can transmit SYNC0 messages to actively make a connection or it can wait passively for the arrival of a SYNC0 message. When either party receives a SYNC0 message, it should respond by transmitting a SYNC1 message. Here, the transmission parameter negotiation takes place: each party begins by declaring its maximum capability and then lowering its parameters in response to SYNC1 messages from the other party, until a common denominator has been achieved. Then each party switches to level 2. If a speed change is required because the parties have agreed on a higher transmission rate, they switch speeds before transmitting their level 2 messages. Once the parties exchange identical SYNC2 messages, they switch to level three. Once each party has received a valid SYNC3 message, synchronization has been achieved and the exchange stops. Now the parties are able to exchange data packets. Data Packets Each data packet message has the form: $F0 $07 <dst-ID> $7C <src-ID> <pktNum> <pSize> <data.> <chkSum> $F7 The elements are dst-ID The destination device ID (0 thru 126). src-ID The source device ID (0 thru 126). pktNum The packet number. Packet numbers will sequence from 0 to 127. pSize The number of eight bit bytes contained in the packet (two seven bit values concatenated, MSB sent first). Must be between zero and the agreed upon maximum. The actual number of data bytes in the message will be larger (see below). The binary data, transmitted in a seven bit format (see below).
chkSum A fourteen bit check sum accumulated over the data bytes only. The check sum is calculated by rotating the 16 bit sum left one bit and then adding each seven bit value. Only the low seven bits of each byte are transmitted in the packet (i.e., the sign bits are dropped), MSB first.

/* * LFO parameter */ typedef struct { uByte lfob_type; uByte lfob_idno; uByte lfob_rfu; uByte lfob_flags; uByte lfob_shape; uByte lfob_rtCtl; uByte lfob_rtMin; uByte lfob_rtMax; } LFOB;
/* = lfoType */ /* = 1 or 2, 8 or 9 for globals */ /* /* /* /* /* initial phase, etc */ ID# of shapeType object */ rate control (enum table #1) */ min rate (enum table #4) */ max rate (enum table #4) */

Object Overview

In this structure the waveshape of the LFO is determined by the lfob_shape parameter, which is the ID# of an LFO shape table (i.e., a shapeType object). Thus to display the name of the waveshape (e.g., Sine or Rising Saw) one needs a list of shapeType IDs and names. Similarly, the LFOs rate control and range are obtained by indexing into the appropriate master tables (tables #1 and #4). Most stuff within the layer block is fixed size, with two exceptions: the envelopes and two tables (ID numbers 17 and 18) used by the high level effects (absent if the program uses modular effects). The envelope header just contains the number of segments in each section (attack and release) with the segments themselves immediately following the header. Note: although the on-board editor allows only eight segments per section, the note control software supports up to 128 segments per section. However, trying to edit (in the 1000) an envelope with more than eight segments in a section will probably cause the editor to crash! Objects within the program or layer are parsed in sequential order. Scanning stops at the end of the data or when an invalid object is detected. Valid objects which are not recognized by the note control software are ignored (e.g., the two tables mentioned above are used only by the editor). If two objects have the same ID number, the last one seen is the one that is used. The ID numbers of the various objects are significant. E.g., each layer may have an LFO #1 and/or #2. LFOs with IDs other than these are ignored (although future instruments may support more LFOs per voice). Global LFOs, which are contained in the program data, have ID numbers beginning with nine (e.g., gLFO 1 is really LFO #9). Note: Early on in the development, we decided that any local object (i.e., with an ID number of 1 thru 8) appearing in the program data would apply to all layers (unless overridden by a specific object appearing in the layer data). We havent actually done this yet, but will probably do so in a future release of the software to allow limited form of data compression. Be prepared! Within programs and layers, table ID numbers 1 thru 63 are reserved (e.g., in the next release, a special table ID may be designated to contain MIDI data to be transmitted on program change). Other numbers may be used, e.g., to add comments, copyright info, etc. Keymaps and Sound Blocks Each layer object contains the ID of a keymap; this object is a variable size mapping table used to convert MIDI key numbers and attack velocities into pitch and loudness and sample selection. Each keymap in turn refers to one or more sound blocks, which are collections of sound file headers (which contain the low level information needed to play back the samples). Since these are variable-sized structures with several optional sections, a diagram of the overall layout is included. The variable data portion of a keymap consists of one or more byte per key arrays. These include one or two bytes of optional tuning information, optional volume adjust, optional sound block IDs and sound file IDs. Keymaps are also organized into multiple timbre levels which are automatically selected by key velocity. Note: Currently, a keymap always contains a byte per key array of sound file header numbers. A future optimization will allow for special keymaps which reference a single soundfile (e.g., an attack noise) by storing the sound file ID in the headers The sound blocks contain lists of sound file headers. These are the actual descriptions of the samples, along with the so-called "natural envelopes" needed for proper playback. Other Objects The actual waveshapes generated by the LFOs are stored as shapeType objects. All incoming MIDI program numbers are converted to internal program numbers using MIDI program lists (mlistType). Intonation tables (itblType) allow tuning of the scale away from equal temperment. Velocity maps (vmapType), in combination

with several of tables described below, determine the mapping of MIDI key velocities into loudness and control sources. Demo Song Objects (excerpts from the V5 Software addendum manual) A RAM based SONG (Demo) object is basically a MIDI File, Type 0, with a 1000 Series object header prepended to it. Demo songs may be loaded, named, renumbered, or removed with ObjectMover. A separate program is needed to turn MIDI files into object files. There may be more than one Demo song in an object file, in which case, there would be multiple song headers. All song objects must be word aligned. The Demo player will play them in the order of their resource IDs, in a repeating cycle. It is recommended that your program remove, or truncate, text meta-events from the data stream (to save RAM space). Only the tempo meta-event is interpreted by the 1000. The block size in the object header is the size of all the objects in file, negated. The blockSize must include everything from itself to the end of file, so you will calculate DO_blockSize like this: demoFile->DO_blockSize = -(fileSize - 32); The object size itself is calculated in a similar way. Object size should include all data from the type and id fields, to the end of your song. Because this is a 16 bit field, there is a 64K maximum size for demo objects. The tempo field (DS_tempo) is a precalculated clock increment providing the initial tempo of the song. This is a 32 bit field which is added to the Demo clock every 2 milliseconds. The Demo clock counts off 1/480 of a quarter note times, with a 16 bit fraction. Your program can calculate the clock increment like this: myDemo->DS_tempo = (long)bps * 1048L; Where bpm is the desired "beats per minute" for your song. If you are working from the MIDI files "microseconds per beat" value, the formula becomes: myDemo->DS_tempo = (60000000 / uspb) * 1048L; Following the song header, comes the name field. This name may be any length (up to 64 chars) and must be null terminated. The MIDI File song data starts on the next even address after that. Tables Table objects are actually miscellaneous, one-of-a-kind objects. All tables are variable sized, unnamed objects; the format of the extension data is determined by the particular tables ID number. The following is a list of some of the more interesting tables organized by ID number: # Description Control Source Enumeration Table gives name, type and ID# for both MIDI and internal control sources. Envelope/ASR Time Enumeration. Determines the actual times for envelope and ASR segments. Non-linear. Enumeration of note start delays. Non-linear. Enumeration of LFO rates. Non-linear. Contains offsets into table #27. Enumeration of Envelope Scale Factors. Contains offsets into table #6. Uses 5% resistor value scale. Logarithmic Multiplier Table used to scale envelope rates. Table #5 contains offsets into this table. MIDI control number map. Incoming MIDI control change messages have their control numbers mapped thru this table. Allows re-assignment of controls. Master parameter data. Contains most everything that is editable in the master menu. Snapping a copy of this object captures the entire state of the machine (MIDI channel and mode, program assignments, etc).

Object mapping table (contained in program only). Used by the high-level effects editor to map pseudo parameters to real parameters. Pseudo parameter table (program only). Contains the actual values of the high-level pseudo parameters. Key velocity to loudness curve (combined with velocity map). Key velocity to control source value curve (combined with velocity map). Mono/Poly pressure to control value curve. Default is linear. Volume control table (MIDI control value to loudness). Non-linear. Balance control table. Equal power crossfade curve. LFO phase increments. Table #4 contains offsets into this table. Enumeration of bi-polar envelope segment values. Converts percentages into output levels. Linear. Enumeration of amplitude envelope segment values. Converts percentages into loudness levels. Non-linear.
Note: The master parameter block, which is currently table #16, is soon to become a distinct, named object. Thus, the instrument will be able to store multiple sets of master parameters. We havent decided exactly how to do this, yet, so stay tuned for more info.
K1000 Object Types Type# Hex $42 $44 $45 $46 $47 $48 $49 $4A $4B $4C $4D $4E $4F $50 $51 $52 $53 $54 $55 $56 $57 $5B $5E $5F Description Master Table LFO Shape Sound Block Keyboard Map MIDI Program List Edit Menu Definition Edit Menu Group Edit Menu Entry List Intonation Table Compiled Effects Descriptor (Rcv) Velocity Map Rcv PressMap Editor Descriptor Program Data Block Layer Data Block ASR Parameter Block LFO Parameter Block ENV Parameter Block EFX Parameter Block INVNEG Parameter Block MXR Parameter Block Demo Song Program List Bin Map Named? yes yes yes yes

yes yes yes ? yes yes

yes ? ?

v5 v5 v5

K1000 Database Master Tables ID# Notes: 1. 2. 3. 4. 5. 6. 7. Determines sound engine configuration and bandwidth. Specific to sound engine bandwidth. Determines UART and front panel type. Specific to product. Specific to front panel. Determines initial settings after hard reset. Contains product and version ID numbers. Description Control Source Enumeration ENV/ASR Time Enumeration Delay Time Enumeration LFO Rate Enumeration ENV Ctl Scale Enumeration ENV Ctl Log Multiplier Playback Rate Compensation Table (2) Edit Parameter ID Table Edit Menu Position Table Editor Default Object Table MIDI Control Mapping Table Front Panel Button Table (4,5) Diagnostic Tables (4) Product Configuration Table (3,4,6) Arnold Configuration Table (1) Prototype Master Data Block (5) Velocity to Loudness Curve Velocity to Control Source Curve Pressure to Control Source Curve MIDI Volume Control Table Equal Power Attenuation Curve Playback Rate Table LFO Phase Increment Table ENV Value Enumeration Amp ENV Value Enumeration Amp ENV Attack Shape Curve Where EROM SROM SROM SROM SROM SROM SROM EROM EROM EROM EROM EROM SROM SROM SROM SROM SROM SROM SROM SROM

ldb_hikey; ldb_trans; ldb_dtune; ldb_delay; ldb_volume; ldb_stereo; ldb_effect; ldb_nLink; ldb_kflags; ldb_xflags; ldb_enable; ldb_legato; ldb_vflags; ldb_dynam; ldb_keyTilt; ldb_balCtl; ldb_spRange; ldb_pwRange; ldb_lastOut; ldb_rfu[7];
/* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /*
highest MIDI key # */ transpose ( semi-tones) */ detune ( cents) */ */ delay (enum table 23) */ volume adjust (dB) */ stereo position */ compiled effect ID */ compiled effect linkage */ key state flags */ effects flags */ enable switch (enum table #1) */ alt attack switch (enum table #1) */ velocity trigger stuff */ dynamic range (dB) */ amplitude tilt (dB) */ balance control (enum table #1) */ soft pedal range (dB) */ pitch wheel range ( quarter-tones) */ used by compiled effects */
/* * ldb_kflags */ #define ldb_ignRels #define ldb_ignSust #define ldb_ignSost #define ldb_ignSusp /* * ldb_xflags */ #define ldb_pwlDis #define ldb_pwlKey #define ldb_volDis #define ldb_touchDis #define ldb_balRev /* * ldb_vflags */ #define ldb_vt1Level #define ldb_vt1Sense #define ldb_vt2Level #define ldb_vt2Sense

0x01 0x02 0x04 0x08

/* /* /* /*
ignore ignore ignore ignore
key release */ sustain pedal */ sostenuto pedal */ suspend pedal */

0x01 0x02 0x08 0x10 0x20

/* /* /* /* /*
pitch wheel disabled */ pitch bend only key down */ volume control disabled */ touch sense disabled */ */ balance control reversed */

0x07 0x08 0x70 0x80

vtrig vtrig vtrig vtrig

level sense level sense

(fff -> ppp) */ */ */ */
/* * Amplitude control patch block */ typedef struct { uByte type, idno; uByte rfu1[2]; uByte amInput; uByte amDepth; sByte amMin , sByte amMax; uByte rfu2[8]; } AFXB; /* * Pitch control patch block */ typedef struct PFXB { uByte type, idno; uByte rfu1[2]; uByte fmInput; uByte fmDepth;
/* = efxtype,1 */ /* /* /* /* mod mod min max source (enum table #1) */ depth (enum table #1) */ depth (dB) */ depth (dB) */
/* = efxType,2 */ /* mod source (enum table #1 */ /* mod depth (enum table @1) */
sByte sByte uByte uByte sByte sByte uByte } PFXB;
fmMin; fmMax; rfu3; dtCtl; dtMin, dtMax; rfu2[4];
/* min depth (cents) */ /* max depth (cents) */ /* detune control (enum table #1 */ /* min value (cents) */ /* max value (cents) */
/* * Envelope control patch block */ typedef struct ENCB { uByte type, idno; uByte rfu1[2]; struct { uByte rfu; uByte rateCtl; uByte minScale uByte maxScale; } atCtl, dtCtl, rtCtl; } ENCB; /* * ASR parameter block */ typedef struct ASRB { uByte asrb_type; uByte asrb_idno; uByte asrb_flags; uByte asrb_trig; uByte asrb_dtime; uByte asrb_atime; uByte asrb_stime; uByte asrb_rtime; } ASRB; /* * asrb_flags */ #define asrb_hold #define asrb_rept #define asrb_effect /* * LFO parameter block */ typedef struct { uByte lfob_type; uByte lfob_idno; uByte lfob_rfu; uByte lfob_flags; uByte lfob_shape; uByte lfob_rtCtl; uByte lfob_rtMin; uByte lfob_rtMax; } LFOB; /* * lfob_flags */ #define lfob_phase #define lfob_effect

/* = efxType,3 */

/* control (enum table #1) */ /* min rate (enum table #5) */ /* max scale (enum table #5) */ /* attack rate */ /* decay rate */ /* release rate */
/* = asrType */ /* /* /* /* /* trigger input (enum table #1) */ delay time (enum table #2) */ attack time (enum table #2) */ sustain time (unused) */ release time (enum table #2) */

0x01 0x02 0x80

/* hold while trigger on */ /* repeat while trigger on */

/* = lfoType */

ID of shapeType object */ rate control (enum table #1) */ min rate (enum table #4) */ max rate (enum table #4) */

0x03 0x80

/* initial phase (0, 90, 180, 270) */
/* * envelope parameter block */ typedef struct { uByte envb_type; uByte envb_idno; sWord envb_size; uByte envb_naSegs; uByte envb_nrSegs; uByte envb_rfu[2]; } ENVB;
/* = envType */ /* # attack segments */ /* # release segments */
/* * envelope segments immediately follow the header * * for all segments but last * level and time are enumerated * * last segment of each section is special: * * if (level > 0) * jump back and repeat going forward * level is segment # to jump to * time is repeat count (0 means infinite) * * else if (level < 0) * loop back and repeat (ie, backward, then forward) * -level is segment # to stop at and change direction * time is repeat count (0 means infinite) * * else (level == 0) * if (time > 0) * time is decay/release time * else if (attack section) * infinite sustain * else * instant release * */ typedef struct { sByte eseg_level; uByte eseg_time; } ESEG; /* * INV/NEG data block */ typedef struct { uByte invb_type; uByte invb_idno; uByte invb_rfu[2]; uByte inub_inv1in; uByte invb_inv2in; uByte invb_neg1in; uByte invb_neg2in; } IHVB, /* * MXR data block */ typedef struct { uByte mxrb_type; uByte mxrb_ldno; uByte mxrb_rfu[2]; uByte mxrb_in1A; uByte mxrb_in1B;
/* level (enum table #28 or #29) */ /* time (enum table #2) */
/* = invType */ /* input (enum table #1) */
/* = mxrType */ /* input (enum table #1) */
uByte mxrb_in2A; uByte mxrb_in2B; } MXRB; /* * keymap (named) * converts key number and velocity */ typedef struct { uByte kmap_type; uByte kmap_idno; sWord kmap_size; sWord kmap_loKey; sWord kmap_nKeys; sWord kmap_keyOff; sWord kmap_nOctv; sWord kmap_pitch; sWord kmap_cents; uByte kmap_flags; uByte kmap_sound; uByte kmap_rfu1; uByte kmap_level; uByte kmap_timbre[nDYNAM]; uByte kmap_rfu2[4]; } KMAP; /* * kmap_flags */ #define kmap_atten #define kmap_tune

/* * Intonation table (named) */ typedef struct { uByte itblTYPE; uByte itblID; sWord itblSize; sWord itblTbl[12]; } ITBL; /* * Velocity map (named) */ typedef struct { uByte vmapTYPE; uByte vmapID; sWord vmapSize; uByte vmapVels[nDYNAM]; } VMAP;
/* [0] always 0 */ /* entries in cents rel to equal temp */

/* fff -> ppp */

/* * Data structure definitions for 1200 Demo objects * (from the V5 manual addendum) */ /* * file type, first longword in file */ #define SROM 0x53524F4D /* * Demo object type and id declarations */ #define Demo1200 0x5B #define DemoIDBase 1 /* * object file header, one per file */ typedef struct { long DO_type; /* Demo (SROM) */ word DO_rfu[14]; /* must be 0 */ long DO_blockSize; /* negative block size */ } dFHdr; /* * song header, one per song */ typedef struct { char DS_objType; char DS_objID; word DS_objSize; long DS_tempo; } demoSong;
0x5B is a Demo song */ is (1.255) */ size of object */ actual initial beat increment */
/* name of the object goes here, before the song itself */ /* (must be null terminated, even number of bytes) */

Tables.h

Tuesday, February 23, 1988 7:15 PM
/* * standard table header */ typedef struct TBLHDR { uByte tbl_type; uByte tbl_idno; sWord tbl_size; } TBLHDR; /* * time enumeration entry */ struct enumTime { uWord ticks; uWord delta; uWord slop; uWord rfu; }; /* * lfo rate enumeration */ struct enumRate { uWord roffs; uWord hertz; };

/* = tableType */

/* msec / 10 */ /* 32767 / ticks */ /* 32767 % ticks */
/* offset into rate table entry */ /* hertz * 100 */
/* * control source enumeration */ struct enumCtls { uByte type; uByte idno; sWord offs; /* offset to name string }; /* * envelope scale factor table header */ struct envScaleHdr { sWord base; /* offset to 0th entry */ sWord low, high; /* valid index range */ sWord dispNom; /* display value denominator */ } /* * table entry */ struct envScaleEnt { sWord multOff; sWord dispNum; }
/* offset into log multiplier table */ /* display value numerator */
/* * table IDs */ enum { enumCtlsID=1, enumTimeID, enumDelayID, enumRateID, envScaleID, logScaleID, prcTableID, pidTableID, mnpTableID, defTableID, ctlMapID, btnTableID, diagTblID, productID, arcTableID, masterID, omtID, pseudoID, attenMapID=21, velocMapID, pressMapID, volTableID, balTableID, playRateID, lfoDeltaID, envValueID, ampValueID, atkTableID, typeTableID };
/* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /*

control source enum */ ENV/ASR time enum */ layer delay enum */ LFO rate enum */ EMU rate scale factor anum */ log multiplier table */ playback rate compensation */ parameter ID table */ menu position table ID */ default object table */ MIDI control mapping table */ front panel button table */ diagnostic table */ product ID/configuration */ Arnold configuration */ initial master parameters */ object mapping table (program only) */ Pseudo parameters (program only) */ velocity -> attenuation table */ velocity -> control value table */ pressure -> control value table */ volume control table */ balance control table */ playback rate table */ LFO phase increment table */ bi-polar EMU level enumeration */ amplitude EMU level enumeration */ amplitude EMU attack table */
1000 Series Program/Layer Structures

Program

$50 ID size $51

ID size

$53 ID ags shape min rate max

$54 size #aseg #rseg ID

program header name sound layer additional layers, global LFOs, ASRs etc.
layer header name (empty) envelopes local LFOs, ASRs etc.

level1 time1

attack

$52 ags ID trig

. levelN timeN level1 time1. levelN timeN release

delay attack releas

Program Header
12 $ID # output prog # 2 size (bytes) stealing option poly limit 3

Layer Header

$51 keymap ID # detune compiled EFX ID# enable switch keyboard tilt compiled EFX 1 ID # low key # delay compiled EFX link alt start switch balance control 2 size (bytes) high key # volume k-ags v-ags soft pedal range transpose stereo x-ags dynamic range p-wheel range 3

Layer Flags

k-ags ignore suspend ignore sostenuto ignore sustain ignore release

balance sense

touch disable

volume disable

p-wheel key only

p-wheel disable

v-trig #2 sense
velocity trigger #2 level

v-trig #1 sense

velocity trigger #1 level

Diagrams

1000 Series Master Parameter Block
48 $42 velocity map ID transmit prog map p-wheel range program pedal 1 assign ags receive prog map soft-pdl range bin bank prog list dynamic range adj 2 size bags bin bank selection software version stamp program assignment per channel pedal 2 assign wheel up assign wheel dn assign slider assign MIDI Mode master tuning 5 Channel master transpose 6 SysEx ID intonation table ID 7 Display Channel intonation key number
ags +/-dB +/-9 off,1.N low high
miscellaneous ags per channel volume adjust per channel stereo position per channel polyphonicity limit per channel MIDI key number range per channel

1000 Series LFO Tables

LFO Rate Enumeration

type=$42 ID=4

LFO Phase Increment

type=$42 ID=27

LFO Shape Table