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

MIDI Implementation

changes which reference non-existent programs are ignored. In general, it takes the instrument about as much time to change a program as it does to start a single layer note. Control Changes All MIDI control numbers are mapped thru a master table which may be replaced by a RAM copy. Internally, the 1000 series represents all control values as signed, 15 bit fractions with a range of 1. MIDI controls (except for the pitch wheel) are treated as uni-polar values with a range of 0 to 1. When a control source is used as a switch, it is considered to by ON if its value is greater than or equal to 0.5. This translates into an MSB value of 64 or greater. The details of how MIDI control values are mapped to internal control values are as follows: The continuous control MSBs (control numbers 1 thru 31) and LSBs (control numbers 33 thru 63) are recorded for all sixteen MIDI channels. When an MSB message is received, the corresponding LSB is forced to zero if the MSB value is zero; otherwise the LSB is set to all ones. Thus, a control value of 0 yields an internal value of 0, while a control value of 127 ($7F) yields an internal value of -1 ($7FFF). Thus, it is desirable to transmit the MSB of any continuous controller first, followed by the LSB. The continuous switches (control numbers 64 thru 95) are treated similarly to the continuous control MSBs. When an MSB of zero is received, the LSB of the internal value is set to zero, otherwise it is set to all ones. Thus the internal value of any control is value = 256 * MSB + 2 * LSB In general, the 1000 series software makes no distinction between internal control sources (e.g., envelopes or LFOs) and external control sources (i.e., MIDI controls). This allows any MIDI control source to be patched to any control input. Certain well-defined control numbers are given special treatment: 7 Volume MSB 39 Volume LSB The volume control may be thought of as controlling an imaginary output VCA. Thus it is completely independent of the note amplitude. This can cause problems with certain wind controllers which transmit MIDI volume as a way of creating a real-time envelope. Switches are provided to ignore MIDI volume at both the layer and the MIDI channel. In addition, the mapping the control values to loudness is controlled by a master table which may be overridden by a RAM copy. 64 Sustain Pedal. When this switch is on, playing notes are held until the switch is off or until they have decayed to silence. A layer-level parameter is provided to ignore the sustain pedal. 66 Sostenuto Pedal This switch behaves like the sustain pedal, but only notes whose keys were down when the pedal was depressed are held. A layer-level parameter is provided to ignore the sostenuto pedal. 67 Soft Pedal At note start, the value of this control (0 to 1) is multiplied by the layer-level soft pedal range parameter (dB) and the result is subtracted from the initial amplitude of the note. The sign of the range parameter determines whether the notes get louder or softer. When this control is used with a switch pedal, its value will be either 0 or 1, but since it responds to the full range of MIDI control values, it can actually be used as a continuous attenuator. Once a note has been started, this control has no effect. 69 Suspend Pedal (aka Freeze Pedal) This switch behaves like the sostenuto pedal, but in addition to sustaining the note, the envelopes are frozen as well. A layer-level parameter is provided to ignore the suspend pedal.

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

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.
Binary Data Transmission Format The simplest transmission scheme is "nibble-izing," sending each data byte as two four bit values. This is the easy to read but it doubles the transmission time. The most efficient packing format (short of some exotic compression scheme like Huffman encoding) is to send the low seven bits of each byte, with every seven data bytes followed by one byte containing the seven sign bits. Thus, the seven binary data bytes AAAAaaaa BBBBbbbb CCCCcccc DDDDdddd EEEEeeee FFFFffff GGGGgggg are transmitted as 0AAAaaaa 0BBBbbbb 0CCCcccc 0DDDdddd 0EEEeeee 0FFFffff 0GGGgggg 0ABCDEFG If the number of data bytes is not a multiple of seven, a short chunk is transmitted. E.g., if three bytes are left over AAAAaaaa BBBBbbbb CCCCcccc they are transmitted as 0AAAaaaa 0BBBbbbb 0CCCcccc 00000ABC This scheme requires that the receiver know the length of the stream, either in logical size (i.e., the number of eight bit bytes) or physical size (the number of seven bit bytes). In general, to transmit N eight-bit bytes requires N + (N + 6)/7 seven bit bytes (assuming truncating integer division). Conversely, receiving M seven bit bytes yields 7 * (M / 8) + (M mod 8 - 1) eight bit bytes. Since the packets are delimited by the system exclusive message, their length is self defined. Thus, within the packet itself, we include the size as the number of eight bit bytes contained in the data. While this may seem counter-intuitive, we believe it to be a more convenient number since it represents the size of the buffer into which the data is unpacked (see the attached code samples). Response to Data Packet $F0 $07 <dst-ID> $7E <src-ID> <pktNum> $F7 $F0 $07 <dst-ID> $7F <src-ID> <pktNum> $F7 (ACK) (NAK)

Used to read objects (or portions of objects) from the K1000s memory. A single read request will elicit multiple responses if request size is larger than the available data size in the message. Create New Object type idno size[4] type idno size[4] zone[4]
Used to create new objects in the K1000s memory. If the size item in the response message is zero, the object could not be created and the zone item is an error code. Otherwise, zone indicates the heap zone name in which the object will reside. New objects may have the same ID as ROM objects; in this case the RAM object will "hide" the ROM object. Write Request/Response type idno size[4] offset[4] data[N] type idno size[4] offset[4]
Used to write data into objects (or portions of objects). When writing into a newly created object, the series of write requests should be terminated by a zero length write message (i.e., an EOF signal). Delete Object type idno type idno
Used to delete objects from the K1000s memory. Deleting a RAM object which was overriding a ROM object of the same ID will "uncover" the ROM object. Thus, if one is maintaining a directory of K1000 objects, the delete request should be followed by an info request to determine if a ROM version of the object exists.
Kurzweil 1000 Series Object Overview
1st Edition: February88 Objects In General The ROM and RAM memory of the 1000 series is organized as a collection of objects which are identified by a unique type and ID number. Any object may be up or downloaded by using the binary data transfer protocol (described in a separate document). Besides programs (aka patches) other object types exist (e.g., LFO shape tables) and any ROM object may be replaced by a RAM version. Object Format The first two bytes of each object contain the type and ID number of the object. E.g., in a program, the type is progType and the ID number is the the program number (typically one greater than the MIDI program number). While some objects have a fixed size (in which the format of the remaining data is determined solely by the type of the object) most objects are variable sized; the second word of the object is the size of the object in bytes. The size may be odd but the software assumes that all objects begin on even boundaries and pads the size to an even number of bytes. Each variable sized object consists of 1) a header whose size is determined by the object type, 2) an optional name (presence determined by type), NUL-terminated and padded to an even number of bytes and 3) the extension data whose size is just the size of the object less the size of the fixed header and the name (if present). The contents of the extension data is arbitrary; for certain objects (programs and layers) the extension data contains more objects (which may be of fixed or variable size). Thus, editor/librarian software must be prepared to deal with a hierarchy of nested objects. Programs, Layers, Etc. The most visible user object is the program, which is basically a shell which contains the layer objects (up to four in the current 1000 series) as well as objects which define global control sources (LFOs and ASRS). The information in the program header is small, consisting of some voice allocation parameters (stealing and polyphonicity limit) and an alternate MIDI program number. The majority of the information needed for starting notes is contained in the layer object. Besides the stuff in the layer header, the layers extension data contains objects which define the local control sources (LFOs, ASRs and envelopes). Many of the items in objects are ID numbers of other objects; others are enumerations where the actual value of a parameter is obtained by using the parameter as an index into a table. As an example, lets look at the description of the LFO parameter block:

/* * 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).

EROM EROM EROM EROM EROM EROM EROM

/* * */

Types.h
Tuesday, February 23, 1988 7:04 PM
/* * object type numbers */ enum { blockType=64, indexType, tableType, shapeType=68, soundType, keymapType, mlistType, menuType, mngType, melType, itblType, fxType, vmapType, pmapType, editType=79, progType, layerType, asrType, lfoType, envType, efxType, invType, mxrType, songType=91, plistType=94, bmapType, lastType }; #define baseType #define globidno
/* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /*
64 $40 - ignore */ 65 $41 - internal index */ 66 $42 - Master Table */ 68 $44 - LFO Shape Table (named) */ 69 $45 - Sound Block (named) */ 7a $46 - Keyboard Map (named) */ 71 $47 - MIDI Program List (named) */ 72 $48 - Edit Menu */ 73 $49 - Edit Menu Group */ 74 $4A - Edit Menu Element */ 75 $4B - Intonation Table (named) */ 76 $4C - Compiled Effects */ 77 $4D - (Rcv) Velocity Map (named) */ 78 $4E - Rcv Pressure Map (named), V5 */ 79 $4F - Editor */ 80 $50 - Program Data (named) */ 81 $51 - Layer Data (named) */ 82 $52 - ASR Parameter Block */ 83 $53 - LFO Parameter Block */ 84 $54 - ENV Parameter Block */ 85 $55 - EFX Parameter Block */ 86 $56 - INV/NEG Parameter Block */ 87 $57 - MXR Parameter Block */ 91 $5B - Demo Song (named), V5 */ 94 $5E - Program List, V5 */ 95 $5F - Bin Map, V5 */ keep last! */
blockType 8 /* base id # for globals */

Objects.h

Tuesday, February 23, 1988 7:35 PM
/* * Database definitions for K1000 Database Objects * To insure future compatability, all RFU items must be zero! */ typedef typedef typedef typedef #define char unsigned char int unsigned int nDYNAM sByte; uByte; sWord; uWord; 8 /* /* /* /* signed byte */ unsigned byte */ signed word (a short) */ unsigned word (a short) */
/* # dynamic range marks */
/* * generalized data block header */ typedef struct { uByte gdb_type; uByte gdb_idno; sWord gdb_size; } GDB; /* * extended data block header */ typedef struct { uByte xdb_type; uByte xdb_idno; sWord xdb_rfu; long xdb_size; } XDB; /* * Master data block */ typedef struct { uByte mdb_type; uByte mdb_idno; sWord mdb_size; uByte mdb_mode; uByte mdb_chan; uByte mdb_devI0; uByte mdb_dchan; uByte mdb_velMap; uByte mdb_ctlMap; uByte mdb_flags; uByte mdb_bflags; sByte mdb_tune; sByte mdb_trans; uByte mdb_intTab; uByte mdb_refKey; uByte mdb_txPList; uByte mdb_rxPList; uByte mdb_bbPList; uByte mdb_bbentry; uByte mdb_editPos[4]; sByte mdb_pwRange; sByte mdb_spRange; sByte mdb_dynam; uByte mdb_rfu1; uByte mdb_version[4]; uByte mdb_cprogs[16];

/* tabletype */ /* 16 */ /* /* /* /* /* MIDI mode */ basic MIDI channel # 1.16) */ sys-ex device ID 0.126 */ displayed channel # 1.16 */ ID of vmapType object */

/* /* /* /* /* /* /* /*

master tune ( cents) */ master transpose ( semi-tones) */ ID of itabType object */ intonation reference key */ transmit program change map */ receive program change map */ bin bank program map (K1000 only) */ current entry */
/* global pitch wheel range ( QT) */ /* global soft pedal range ( dB) */ /* additive dynamic range adjust (dB) */ /* software version stamp */ /* programs/channel */
/* * local keyboard control assignments (K1000 only) */ uByte mdb_pedal1; /* sustain pedal */ uByte mdb_pedal2; /* other pedal */ uByte mdb_wheelUp; /* mod wheel - up */ uByte mdb_wheelDn; /* mod wheel down */ uByte mdb_slider; /* data slider */ uByte mdb_rfu2; uByte mdb_rfu3[10]; /* * more per channel stuff */ uByte mdb_cflags[16]; /* flags */ sByte mdb_volume[16]; /* volume adjust (dB) */ sByte mdb_stereo[16]; /* stereo position */ uByte mdb_plimit(16]; /* poly limit */ uByte mdb_range[16][2]; /* low/hi MIDI keys */ } MDB; /* Flag #define #define #define #define #define #define #define /* * Flag */ #define #define #define /* * Flag */ #define #define #define definitions for mdb_monoOut mdb_ignNOff mdb_mRefKey mdb_parEdit mdb_confirm mdb_echoPChg mdb_stealSame mdb_flags */ 0x01 /* force monophonic output */ 0x02 /* ignore MIDI all notes off */ 0x04 /* MIDI intonation ref key */ 0x08 /* MIDI parameter editing */ 0x10 /* ~confirm deletes */ 0x20 /* echo program changes */ 0x40 /* steal same note */
definitions for mdb_bflags mdb_btnRept mdb_btnRate mdb_btnAccl 0x01 0x02 0x04 /* button repeats */ /* button repeat rate (slow/fast) */ /* button acceleration */
definitions for mdb_cflags mdb_volDis mdb_panOver mdb_rngOver 0x01 0x02 0x04 /* volume disabled */ /* stereo pan override */ /* MIDI kbd range override
/* * program data block * just a shell to enclose the layer definitions */ typedef struct { uByte pdb_type; uByte pdb_idno; sWord pdb_size; uByte pdb_rfu1; uByte pdb_midiProg; /* output program */ uByte pdb_stealOpt; /* assignment algorithm */ uByte pdb_phLimit; /* polyphonicity limit */ uByte pdb_rfu3[8]; } PDB; /* * layer data block (named) * contained in program data */ typedef struct { uByte ldb_type; uByte ldb_idno; sWord ldb_size; uByte ldb_keymap; uByte ldb_lokey;

/* 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
to sound file, pitch, and amplitude /* = keymapType */ /* /* /* /* /* /* low MIDI key # */ # keys - 1 */ offset to key data */ notes/octove */ pitch of lowest key */ cents/key */
/* ID of soundType object */ /* # timbre levels */ /* timbre level map */

0x01 0x0C

/* 1 means separate atten/key */ /* tuning type */
/* * the keymap data consists of byte/key arrays * * switch (kmap_flags & kmap_tune) * case 0x00: no tuning adjust * case 0x04: relative byte (LSB only) * case 0x08: relative word (MSB/LSB) * case 0x0C: absolute word (MSB/LSB) * * for (each timbre level) { * if (kmap_flags & kmap_atten) * amplitude adjust (1 byte/key) (8 * dB / 6) * if (kmap_sound == 0) * sound block ID (1 byte/key) * sound file header ID (1 byte/key) */ /* * sound block (named) */ typedef struct sblk { uByte sblk_type; uByte sblk_idno; sWord sblk_size; sWord sblk_hBase; sWord sblk_nHdrs; sWord sblk_hdrOff; uByte sblk_rfu[6]; } SBLK;
/* = soundType */ /* base sound file ID # */ /* # sound file headers - 1 */ /* offset to 1st header */
/* * block header is followed by NUL-terminated name * then by array of sound file headers */ typedef struct sfh { uByte sfh_rootKey; /* root MIDI key # */
uByte sWord sWord uByte long long long long sWord sWord uByte } SFH;
sfh_flags; sfh_atten; sfh_pitch; sfh_rfu1[2]; sfh_start1; sfh_start2; sfh_loop; sfh_end; sfh_env1; sfh_env2; sfh_rfu2[4];
/* amp adjust (dons) */ /* pitch at highest play rate */ /* /* /* /* /* /* normal start sample address */ alternate start sample address */ loop point sample address */ last sample address + 2 */ offset to normal envelope */ offset to alternate envelope */
/* * header array is followed by natural envelopes * each segment is two words: * * delta-a,delta-s * * where delta-s is the segment length in samples * and delta-a is the attack/decay rate computed as * * delta-a = (2048 * delta-dB) / (6 * delta-s) * * if the delta-a of the 1st segment is > 0, * a starting amplitude of 0 is assumed * otherwise, the amplitude starts at the maximum value * * the last two segments are the decay and release segments * the delta-s for these must be 0 * the delta-a should be computed using a delta-s which corresponds * to the # of samples in 10 msec at the highest playback rate * for the decay segment, delta-a may be zero (for infinite sustain) */

/* 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