com.dixshtix.midi
Class EventStatus

java.lang.Object
  |
  +--com.dixshtix.midi.EventStatus

public class EventStatus

extends java.lang.Object

All the primary types of MIDI content.

The MIDI protocol is made up of messages. A message consists of a string (ie, series) of 8-bit bytes. MIDI has many such defined messages. Some messages consist of only 1 byte. Other messages have 2 bytes. Still others have 3 bytes. One type of MIDI message can even have an unlimited number of bytes. The one thing that all messages have in common is that the first byte of the message is the Status byte. This is a special byte because it's the only byte that has bit #7 set. Any other following bytes in that message will not have bit #7 set. So, you can always detect the start a MIDI message because that's when you receive a byte with bit #7 set. This will be a Status byte in the range 0x80 to 0xFF. The remaining bytes of the message (ie, the data bytes, if any) will be in the range 0x00 to 0x7F. (Note that I'm using the C programming language convention of prefacing a value with 0x to indicate hexadecimal).

The Status bytes of 0x80 to 0xEF are for messages that can be broadcast on any one of the 16 MIDI channels. Because of this, these are called Voice messages. (My own preference is to say that these messages belong in the Voice Category). For these Status bytes, you break up the 8-bit byte into 2 4-bit nybbles. For example, a Status byte of 0x92 can be broken up into 2 nybbles with values of 9 (high nybble) and 2 (low nybble). The high nybble tells you what type of MIDI message this is. Here are the possible values for the high nybble, and what type of Voice Category message each represents:

8	Note Off
9	Note On
A	AfterTouch (ie, key pressure)
B	Control Change
C	Program (patch) change
D	Channel Pressure
E	Pitch Wheel

So, for our example status of 0x92, we see that its message type is Note On (ie, the high nybble is 9). What's the low nybble of 2 mean? This means that the message is on MIDI channel 2. There are 16 possible (logical) MIDI channels, with 0 being the first. So, this message is a Note On on channel 2. What status byte would specify a Program Change on channel 0? The high nybble would need to be C for a Program Change type of message, and the low nybble would need to be 0 for channel 0. Thus, the status byte would be 0xC0. How about a Program Change on channel 15 (ie, the last MIDI channel). Again, the high nybble would be C, but the low nybble would be F (ie, the hexadecimal digit for 15).Thus, the status would be 0xCF.

NOTE: Although the MIDI Status byte counts the 16 MIDI channels as numbers 0 to F (ie, 15), all MIDI gear (including computer software) displays a channel number to the musician as 1 to 16. So, a Status byte sent on MIDI channel 0 is considered to be on "channel 1" as far as the musician is concerned. This discrepancy between the status byte's channel number, and what channel the musician "believes" that a MIDI message is on, is accepted because most humans start counting things from 1, rather than 0.

The Status bytes of 0xF0 to 0xFF are for messages that aren't on any particular channel (and therefore all daisy-chained MIDI devices always can "hear" and choose to act upon these messages. Contrast this with the Voice Category messages, where a MIDI device can be set to respond to those MIDI messages only on a specified channel). These status bytes are used for messages that carry information of interest to all MIDI devices, such as synchronizing all playback devices to a particular time. (By contrast, Voice Category messages deal with the individual musical parts that each instrument might play, so the channel nybble scheme allows a device to respond to its own MIDI channel while ignoring the Voice Category messages intended for another device on another channel).

These status bytes are further divided into two categories. Status bytes of 0xF0 to 0xF7 are called System Common messages. Status bytes of 0xF8 to 0xFF are called System Realtime messages. The implications of such will be discussed later.

Actually, certain Status bytes within this range are not defined by the MIDI spec to date, and are reserved for future use. For example, Status bytes of 0xF4, 0xF5, 0xF9, and 0xFD are not used. If a MIDI device ever receives such a Status, it should ignore that message. See Ignoring MIDI Messages.

What follows is a description of each message type. The description tells what the message does, what its status byte is, and whether it has any subsequent data bytes and what information those carry. Generally, these descriptions take the view of a device receiving such messages (ie, what the device would typically be expected to do when receiving particular messages). When applicable, remarks about a device that transmits such messages may be made.

Version:

0.1

Author:

Richard C. Penner II

Field Summary

static byte	kmbCopyrightTextEvent Copyright (include on start of every track).
static byte	kmbCuePoint Cue Point.
static byte	kmbEndTrack XXX.
static byte	kmbInstrumentName Instrument Name (for Type 1 files).
static byte	kmbKeySignature XXX.
static byte	kmbLyric Lyrics.
static byte	kmbMarker Marker.
static byte	kmbMidiChannel XXX.
static byte	kmbMidiPort XXX.
static byte	kmbSequencerSpecific XXX.
static byte	kmbSetSequenceNumber Track Header MetaEvent.
static byte	kmbSetTempo XXX.
static byte	kmbSmpteOffset XXX.
static byte	kmbTextEvent Generic Text MetaEvent.
static byte	kmbTextEvent08 Generic Text MetaEvent.
static byte	kmbTextEvent09 Generic Text MetaEvent.
static byte	kmbTextEvent0a Generic Text MetaEvent.
static byte	kmbTextEvent0b Generic Text MetaEvent.
static byte	kmbTextEvent0c Generic Text MetaEvent.
static byte	kmbTextEvent0d Generic Text MetaEvent.
static byte	kmbTextEvent0e Generic Text MetaEvent.
static byte	kmbTextEvent0f Generic Text MetaEvent.
static byte	kmbTimeSignature XXX.
static byte	kmbTrackName Sequence/Track Name (include at beginning of track).
static byte	kMetaEvent Used in files only.
static byte	kmid0 Start of defined Manufacturer IDs.
static byte	kmidAkai
static byte	kmidBigBriar
static byte	kmidBonTempi
static byte	kmidCasio
static byte	kmidCheetah
static byte	kmidCrumar
static byte	kmidCTS
static byte	kmidDeltaLabs
static byte	kmidDigiDesign
static byte	kmidEducationalUse This ID is for educational or development use only, and should never appear in a commercial design.
static byte	kmidElka
static byte	kmidEmu
static byte	kmidFairlight
static byte	kmidFender
static byte	kmidGeneralElectro
static byte	kmidGulbransen
static byte	kmidHohner
static byte	kmidJellinghausMs
static byte	kmidJLCooper
static byte	kmidKawai
static byte	kmidKorg
static byte	kmidKurzweil
static byte	kmidLexicon
static byte	kmidLin
static byte	kmidLowery
static byte	kmidMatthewsResearch
static byte	kmidMoog
static byte	kmidOberheim
static byte	kmidOctavePlateau
static byte	kmidPAIA
static byte	kmidPassportDesigns
static byte	kmidPeavey
static byte	kmidPPG
static byte	kmidRoland
static byte	kmidSequentialCircuits
static byte	kmidSIEL
static byte	kmidSimmons
static byte	kmidSolton
static byte	kmidSoundComp
static byte	kmidSyntheAxe
static byte	kmidTechmar
static byte	kmidUniversalNonRealtime
static byte	kmidUniversalRealtime
static byte	kmidYamaha
static byte	ksbActiveSense Realtime byte, never in files
static byte	ksbChannelAfterTouch
static byte	ksbControlChange
static byte	ksbKeyAfterTouch
static byte	ksbMIDI_Clock Realtime byte, never in files
static byte	ksbMIDI_Continue Realtime byte, never in files
static byte	ksbMIDI_Reset Never send by automated or scripted processes.
static byte	ksbMIDI_Start Realtime byte, never in files
static byte	ksbMIDI_Stop Realtime byte, never in files
static byte	ksbNoteOff
static byte	ksbNoteOn
static byte	ksbPatchChange
static byte	ksbPitchWheelChange
static byte	ksbQuarterFrameMessage System Common Message: MTC Quarter Frame Message.
static byte	ksbReservedF4 Reserved for future use.
static byte	ksbReservedF5 Reserved for future use.
static byte	ksbReservedF9 Realtime byte, never in files.
static byte	ksbReservedFD Realtime byte, never in files
static byte	ksbSongPosition Sets in a Random-Access manner the position of a stopped song for a Continue.
static byte	ksbSongSelect Sets in a Random-Access manner the position of a stopped song for a Continue.
static byte	ksbSysexF0 System Common Message: Start of a system-exclusive message.
static byte	ksbSysexF7 Continuation (possibly time-delayed) of a system-exclusive message.
static byte	ksbTuneRequest Requests self-calibration.
static byte	ksnChannelAfterTouch Voice message, change volume, pressure on all notes in channel.
static byte	ksnControlChange Voice message, change a control.
static byte	ksnKeyAfterTouch Voice message, alters playback on a particular channel and note at a specific velocity.
static byte	ksnNoteOff Voice message, ends playback on a particular channel and note, at a speed given by the velocity.
static byte	ksnNoteOn Voice message, starts playback on a particular channel, note, and velocity.
static byte	ksnPatchChange Voice message, change patch (instrument/program/etc) on a channel.
static byte	ksnPitchWheelChange Voice message, change pitch wheel, takes 14-bit unsigned argument.

Constructor Summary

EventStatus()

Methods inherited from class java.lang.Object

, clone, equals, finalize, getClass, hashCode, notify, notifyAll, registerNatives, toString, wait, wait, wait

Field Detail

ksnNoteOff

public static final byte ksnNoteOff

Voice message, ends playback on a particular channel and note, at a speed given by the velocity.

This message is sent when a note is released (ended).

 80+channel note velocity
 

Purpose

Indicates that a particular note should be released. Essentially, this means that the note stops sounding, but some patches might have a long VCA release time that needs to slowly fade the sound out. Additionally, the device's Hold Pedal controller may be on, in which case the note's release is postponed until the Hold Pedal is released. In any event, this message either causes the VCA to move into the release stage, or if the Hold Pedal is on, indicates that the note should be released (by the device automatically) when the Hold Pedal is turned off. If the device is a MultiTimbral unit, then each one of its Parts may respond to Note Offs on its own channel. The Part that responds to a particular Note Off message is the one assigned to the message's MIDI channel.

See Also:

Channel, Note, Velocity

ksbNoteOff

public static final byte ksbNoteOff

ksnNoteOn

public static final byte ksnNoteOn

Voice message, starts playback on a particular channel, note, and velocity. A 64 velocity is default.

This message is sent when a note is depressed (start).

 90+channel note velocity
 

A zero velocity is a disguised NoteOff.

Purpose

Indicates that a particular note should be played. Essentially, this means that the note starts sounding, but some patches might have a long VCA attack time that needs to slowly fade the sound in. In any case, this message indicates that a particular note should start playing (unless the velocity is 0, in which case, you really have a Note Off). If the device is a MultiTimbral unit, then each one of its Parts may sound Note Ons on its own channel. The Part that sounds a particular Note On message is the one assigned to the message's MIDI channel.

A Note On message that has a velocity of 0 is considered to actually be a Note Off message, and the respective note is therefore released. See the Note Off entry for a description of such. This "trick" was created in order to take advantage of running status.

A device that recognizes MIDI Note On messages must be able to recognize both a real Note Off as well as a Note On with 0 velocity (as a Note Off). There are many devices that generate real Note Offs, and many other devices that use Note On with 0 velocity as a substitute.

An All Notes Off controller message can be used to turn off all notes for which a device received Note On messages (without having received respective Note Off messages).

See Also:

Channel, Note, Velocity

ksbNoteOn

public static final byte ksbNoteOn

ksnKeyAfterTouch

public static final byte ksnKeyAfterTouch

Voice message, alters playback on a particular channel and note at a specific velocity.

Polyphonic Key Pressure (After-touch).

This message is sent when the pressure (velocity) of a previously triggered note changes.

 A0+channel note velocity
 

Purpose

While a particular note is playing, pressure can be applied to it. Many electronic keyboards have pressure sensing circuitry that can detect with how much force a musician is holding down a key. The musician can then vary this pressure, even while he continues to hold down the key (and the note continues sounding). The Aftertouch message conveys the amount of pressure on a key at a given point. Since the musician can be continually varying his pressure, devices that generate Aftertouch typically send out many such messages while the musician is varying his pressure. Upon receiving Aftertouch, many devices typically use the message to vary a note's VCA and/or VCF envelope sustain level, or control LFO amount and/or rate being applied to the note's sound generation circuitry. But, it's up to the device how it chooses to respond to received Aftertouch (if at all). If the device is a MultiTimbral unit, then each one of its Parts may respond differently (or not at all) to Aftertouch. The Part affected by a particular Aftertouch message is the one assigned to the message's MIDI channel.

See Also:

Channel, Note, Velocity

ksbKeyAfterTouch

public static final byte ksbKeyAfterTouch

ksnControlChange

public static final byte ksnControlChange

Voice message, change a control.

This message is sent when a controller value changes. Controllers include devices such as pedals and levers. Certain controller numbers are reserved for specific purposes, like changing the mode of a channel.

 B0+channel control value
 

Purpose

Sets a particular controller's value. A controller is any switch, slider, knob, etc, that implements some function (usually) other than sounding or stopping notes (ie, which are the jobs of the Note On and Note Off messages respectively). There are 128 possible controllers on a MIDI device. These are numbered from 0 to 127. Some of these controller numbers as assigned to particular hardware controls on a MIDI device. For example, controller 1 is the Modulation Wheel. Other controller numbers are free to be arbitrarily interpreted by a MIDI device. For example, a drum box may have a slider controlling Tempo which it arbitrarily assigns to one of these free numbers. Then, when the drum box receives a Controller message for that controller number, it can adjust its tempo. A MIDI device need not have an actual physical control on it in order to respond to a particular controller.For example, even though a rack-mount sound module may not have a Mod Wheel on it, the module will likely still respond to and utilize Modulation controller messages to modify its sound. If the device is a MultiTimbral unit, then each one of its Parts may respond differently (or not at all) to various controller numbers. The Part affected by a particular controller message is the one assigned to the message's MIDI channel.

See Also:

Channel, Controller, Value

ksbControlChange

public static final byte ksbControlChange

ksnPatchChange

public static final byte ksnPatchChange

Voice message, change patch (instrument/program/etc) on a channel.

This message sent when the patch (Program) number changes.

 C0+channel patch
 

Purpose

To cause the MIDI device to change to a particular Program (which some devices refer to as Patch, or Instrument, or Preset, or whatever). Most sound modules have a variety of instrumental sounds, such as Piano, and Guitar, and Trumpet, and Flute, etc. Each one of these instruments is contained in a Program. So, changing the Program changes the instrumental sound that the MIDI device uses when it plays Note On messages. Of course, other MIDI messages also may modify the current Program's (ie, instrument's) sound. But, the Program Change message actually selects which instrument currently plays. There are 128 possible program numbers, from 0 to 127. If the device is a MultiTimbral unit, then it usually can play 16 "Parts" at once, each receiving data upon its own MIDI channel. This message will then change the instrument sound for only that Part which is set to the message's MIDI channel.

See Also:

Channel, Patch

ksbPatchChange

public static final byte ksbPatchChange

ksnChannelAfterTouch

public static final byte ksnChannelAfterTouch

Voice message, change volume, pressure on all notes in channel.

This message is sent when the channel pressure changes. Some velocity-sensing keyboards do not support polyphonic after-touch. Use this message to send the single greatest velocity (of all the current depressed keys).

 D0+channel velocity
 

Purpose

While notes are playing, pressure can be applied to all of them. Many electronic keyboards have pressure sensing circuitry that can detect with how much force a musician is holding down keys. The musician can then vary this pressure, even while he continues to hold down the keys (and the notes continue sounding). The Channel Pressure message conveys the amount of overall pressure on the keys at a given point. Since the musician can be continually varying his pressure, devices that generate Channel Pressure typically send out many such messages while the musician is varying his pressure. Upon receiving Channel Pressure, many devices typically use the message to vary all of the sounding notes' VCA and/or VCF envelope sustain levels, or control LFO amount and/or rate being applied to the notes' sound generation circuitry. But, it's up to the device how it chooses to respond to received Channel Pressure (if at all). If the device is a MultiTimbral unit, then each one of its Parts may respond differently (or not at all) to Channel Pressure. The Part affected by a particular Channel Pressure message is the one assigned to the message's MIDI channel.

See Also:

Channel, Velocity

ksbChannelAfterTouch

public static final byte ksbChannelAfterTouch

ksnPitchWheelChange

public static final byte ksnPitchWheelChange

Voice message, change pitch wheel, takes 14-bit unsigned argument.

This message is sent to indicate a change in the pitch wheel. The pitch wheel is measured by a fourteen bit value. Center (no pitch change) is 0x2000 (8192). Sensitivity is a function of the transmitter.

 E0+channel lo hi
 

Pitch Wheel = 128 * hi + lo - 8192 ;

Purpose

To set the Pitch Wheel value. The pitch wheel is used to slide a note's pitch up or down in cents (ie, fractions of a half-step). If the device is a MultiTimbral unit, then each one of its Parts may respond differently (or not at all) to Pitch Wheel. The Part affected by a particular Pitch Wheel message is the one assigned to the message's MIDI channel.

See Also:

Channel, PitchWheel

ksbPitchWheelChange

public static final byte ksbPitchWheelChange

ksbSysexF0

public static final byte ksbSysexF0

System Common Message: Start of a system-exclusive message.

Arbitrary length messages to a device of a specific Manufacturer ID. This message makes up for all that MIDI doesn't support. mid is a seven bit Manufacturer's I.D. code. If the synthesizer recognizes the I.D. code as its own, it will listen to the rest of the message (seven-bit data). Otherwise, the message will be ignored. System Exclusive is used to send bulk dumps such as patch parameters and other non-spec data. (Note: Real-Time messages ONLY may be interleaved with a System Exclusive.)

 F0 mid data ... F7 (on wire)
 F0 len mid data ... [F7] (in file)
 

See Also:

BinaryData

ksbQuarterFrameMessage

public static final byte ksbQuarterFrameMessage

System Common Message: MTC Quarter Frame Message.

Some master device that controls sequence playback sends this timing message to keep a slave device in sync with the master. (not in MIDI 1.0 Spec)

 F1 mtc
 

MIDI Time Code

MIDI Time Code (MTC) is a sub-protocol within MIDI, and is used to keep 2 devices that control some sort of timed performance (ie, maybe a sequencer and a video deck) in sync. MTC messages are an alternative to using MIDI Clocks and Song Position Pointer messages. MTC is essentially SMPTE mutated for transmission over MIDI. SMPTE timing is referenced from an absolute "time of day". On the other hand, MIDI Clocks and Song Position Pointer are based upon musical beats from the start of a song, played at a specific Tempo. For many (non-musical) cues, it's easier for humans to reference time in some absolute way rather than based upon musical beats at a certain tempo.

There are several MIDI messages which make up the MTC protocol. All but one are specially defined SysEx messages.

The most important message is the Quarter Frame message (which is not a SysEx message). It has a status of 0xF1, and one subsequent data byte. This message is sent periodically to keep track of the running SMPTE time. It's analogous to the MIDI Clock message. The Quarter Frame messages are sent at a rate of 4 per each SMPTE Frame. In other words, by the time that a slave has received 4 Quarter Frame messages, a SMPTE Frame has passed. So, the Quarter Frame messages provide a "sub-frame" clock reference. (With 30 fps SMPTE, this "clock tick" happens every 8.3 milliseconds).

But the Quarter Frame is more than just a quarter frame "clock tick". The Quarter Frame message's data byte contains the SMPTE time (ie, hours, minutes, seconds, and frames). SMPTE time is normally expressed in 80 bits. Obviously, this is too many bits to be contained in 1 8-bit data byte. So, each Quarter Frame message contains just one piece of the time (for example, one Quarter Frame may contain only the hours). In order to get the entire SMPTE time at any given point, a slave needs to receive several Quarter Frame messages, and piece the current SMPTE time together from those messages. It takes 8 Quarter Frame messages to convey the current SMPTE time. In other words, by the time that a slave can piece together the current SMPTE time, two SMPTE frames have passed (ie, since there are 4 Quarter Frame messages in each frame). So, MTC's version of SMPTE time actually counts in increments of 2 SMPTE Frames per each update of the current SMPTE time.

The first (of 8) Quarter Frame message contains the low nybble (ie, bits 0 to 3) of the Frame Time. The second Quarter Frame message contains the high nybble (ie, bits 4 to 7) of the Frame Time. The third and fourth messages contain the low and high nybbles of the Seconds Time. The fifth and sixth messages contain the low and high nybbles of the Minutes Time. The seventh and eighth messages contain the low and high nybbles of the Hours Time. The eighth message also contains the SMPTE frames-per-second Type (ie, 24, 25, 30 drop, or 30 fps). If you were to break up the Quarter Frame's data byte into its 7 bits, the format is:

0nnn dddd

where nnn is one of 7 possible values which tell you what dddd represents. Here are the 7 values, and what each causes dddd to represent.

Value	dddd
0	Current Frames Low Nibble
1	Current Frames High Nibble
2	Current Seconds Low Nibble
3	Current Seconds High Nibble
4	Current Minutes Low Nibble
5	Current Minutes High Nibble
6	Current Hours Low Nibble
7	Current Hours High Nibble and SMPTE Type
	In the data byte for the Hours High Nibble and SMPTE Type, the bits are interpreted as follows: 0nnn x yy d where nnn is 7. x is unused and set to 0. d is bit 4 of the Hours Time. yy tells the SMPTE Type as follows:
		yy	SMPTE Type
		0	24 fps
		1	25 fps
		2	29.97 fps (30 Drop-Frame)
		3	30 fps

0xF1 0x25

means that the 5 is the low nybble of the Seconds Time (because nnn is 2). If the following Quarter Frame is subsequently received,

0xF1 0x32

then this means that 2 is the high nybble of the Seconds Time. Therefore, the current SMPTE Seconds is 0x25 (ie, 37 seconds).

When MTC is running in the forward direction (ie, time is advancing), the Quarter Frame messages are sent in the order of Frames Low Nibble to Hours High Nibble. In other words, the order looks something like this:

0xF1 0x0n

where n is the current Frames Low Nibble

0xF1 0x1n

where n is the current Frames High Nibble

0xF1 0x2n

where n etc.

0xF1 0x3n

0xF1 0x4n

0xF1 0x5n

0xF1 0x6n

0xF1 0x7n

When MTC is running in reverse (ie, time is going backwards), these are sent in the opposite order, ie, the Hours High Nibble is sent first and the Frames Low Nibble is last.

The arrival of the 0xF1 0x0n and 0xF1 0x4n messages always denote where SMPTE Frames actually occur in realtime.

Since 8 Quarter Frame messages are required to piece together the current SMPTE time, timing lock can't be achieved until the slave has received all 8 messages. This will take from 2 to 4 SMPTE Frames, depending upon when the slave comes online.

The Frame number (contained in the first 2 Quarter Frame messages) is the SMPTE Frames Time for when the first Quarter Frame message is sent. But, because it takes 7 more Quarter Frames to piece together the current SMPTE Time, when the slave does finally piece the time together, it is actually 2 SMPTE Frames behind the real current time. So, for display purposes, the slave should always add 2 frames to the current time.

See Also:

TimeSignature

ksbSongPosition

public static final byte ksbSongPosition

Sets in a Random-Access manner the position of a stopped song for a Continue.

This is an internal 14 bit register that holds the number of MIDI beats (1 beat= six MIDI clocks) since the start of the song.

 F2 lo hi
 

See Also:

Beats

ksbSongSelect

public static final byte ksbSongSelect

Sets in a Random-Access manner the position of a stopped song for a Continue.

The Song Select specifies which sequence or song is to be played.

 F3 seq
 

See Also:

Song

ksbReservedF4

public static final byte ksbReservedF4

Reserved for future use.

ksbReservedF5

public static final byte ksbReservedF5

Reserved for future use.

ksbTuneRequest

public static final byte ksbTuneRequest

Requests self-calibration. Should never be in files

Upon receiving a Tune Request, all analog synthesizers should tune their oscillators.

 F6
 

ksbSysexF7

public static final byte ksbSysexF7

Continuation (possibly time-delayed) of a system-exclusive message.

• In files, this byte indicates a continuation of F0

   F7 len data ... [F7]
   

• On the wire, this byte ends a F0

   F7
   

Some midi units send a system exclusive message as a series of small "packets" (with a time delay in-between transmission of each packet). The first packet begins with an F0, but it doesn't end with an F7. The subsequent packets don't start with an F0 nor end with F7. The last packet doesn't start with an F0, but does end with the F7. So, between the first packet's opening F0 and the last packet's closing F7, there's 1 SysEx message there. (Note: only extremely poor designs, such as the crap marketed by Casio exhibit these aberrations). Of course, since a delay is needed in-between each packet, you need to store each packet as a separate event with its own time in the MTrk. Also, you need some way of knowing which events shouldn't begin with an F0 (ie, all of them except the first packet). So, the MIDI file spec redefines a midi status of F7 (normally used as an end mark for SysEx packets) as a way to indicate an event that doesn't begin with F0. If such an event follows an F0 event, then it's assumed that the F7 event is the second "packet" of a series. In this context, it's referred to as a SysEx CONTINUATION event. Just like the F0 type of event, it has a variable length followed by data bytes. On the other hand, the F7 event could be used to store MIDI REALTIME or MIDI COMMON messages. In this case, after the variable length bytes, you should expect to find a MIDI Status byte of F1, F2, F3, F6, F8, FA, FB, FC, or FE. (Note that you wouldn't find any such bytes inside of a SysEx CONTINUATION event). When used in this manner, the F7 event is referred to as an ESCAPED event.

See Also:

ksbQuarterFrameMessage, ksbSongPosition, ksbSongSelect, ksbTuneRequest, ksbMIDI_Clock, ksbMIDI_Start, ksbMIDI_Continue, ksbMIDI_Stop, ksbActiveSense, ksbMIDI_Reset

ksbMIDI_Clock

public static final byte ksbMIDI_Clock

Realtime byte, never in files

Timing Clock. Sent 24 times per quarter note when synchronization is required.

 F8
 

ksbReservedF9

public static final byte ksbReservedF9

Realtime byte, never in files.

ksbMIDI_Start

public static final byte ksbMIDI_Start

Realtime byte, never in files

Start the current sequence playing. (This message will be followed with Timing Clocks).

 FA
 

ksbMIDI_Continue

public static final byte ksbMIDI_Continue

Realtime byte, never in files

Continue at the point the sequence was Stopped.

 FB
 

ksbMIDI_Stop

public static final byte ksbMIDI_Stop

Realtime byte, never in files

Stop the current sequence.

 FC
 

ksbReservedFD

public static final byte ksbReservedFD

Realtime byte, never in files

ksbActiveSense

public static final byte ksbActiveSense

Realtime byte, never in files

Active Sensing.

Use of this message is optional. When initially sent, the receiver will expect to receive another Active Sensing message each 300ms (max), or it will be assume that the connection has been terminated. At termination, the receiver will turn off all voices and return to normal (non- active sensing) operation.

 FE
 

ksbMIDI_Reset

public static final byte ksbMIDI_Reset

Never send by automated or scripted processes. Never in files.

Reset all receivers in the system to power-up status. This should be used sparingly, preferably under manual control. In particular, it should not be sent on power-up.

 FF
 

kMetaEvent

public static final byte kMetaEvent

Used in files only.

A status of FF is reserved to indicate a special non-MIDI event. (Note that FF is used in MIDI to mean "reset", so it wouldn't be all that useful to store in a data file. Therefore, the MIDI file spec arbitrarily redefines the use of this status). After the FF status byte is another byte that tells you what Type of non-MIDI event it is. It's sort of like a second status byte. Then after this byte is another byte(s -- a variable length quantity again) that tells how many more data bytes follow in this event (ie, its Length). This Length doesn't include the FF, Type byte, nor the Length byte. These special, non-MIDI events are called Meta-Events, and most are optional unless otherwise noted. What follows are some defined Meta-Events (including the FF Status and Length). Note that unless otherwise mentioned, more than one of these events can be placed in an Mtrk (even the same Meta-Event) at any delta-time. (Just like all midi events, Meta-Events have a delta-time from the previous event regardless of what type of event that may be. So, you can freely intermix MIDI and Meta events).

kmbSetSequenceNumber

public static final byte kmbSetSequenceNumber

Track Header MetaEvent.

 FF 00 02 ss ss
 

This optional event which must occur at the beginning of a MTrk (ie, before any non-zero delta-times and before any midi events) specifies the number of a sequence. The two data bytes ss ss, are that number which corresponds to the MIDI Cue message. In a format 2 MIDI file, this number identifies each "pattern" (ie, Mtrk) so that a "song" sequence can use the MIDI Cue message to refer to patterns. If the ss ss numbers are omitted (ie, Length byte = 0 instead of 2), then the MTrk's location in the file is used (ie, the first MTrk chunk is the first pattern). In format 0 or 1, which contain only one "pattern" (even though format 1 contains several MTrks), this event is placed in only the first MTrk. So, a group of format 1 files with different sequence numbers can comprise a "song collection".

There can be only one of these events per MTrk chunk in a Format 2. There can be only one of these events in a Format 0 or 1, and it must be in the first MTrk.

See Also:

Sequence

kmbTextEvent

public static final byte kmbTextEvent

Generic Text MetaEvent.

 FF 01 len text
 

Any amount of text (amount of bytes = len) for any purpose. It's best to put this event at the beginning of an MTrk. Although this text could be used for any purpose, there are other text-based Meta-Events for such things as orchestration, lyrics, track name, etc. This event is primarily used to add "comments" to a MIDI file which a program would be expected to ignore when loading that file.

Note that len could be a series of bytes since it is expressed as a variable length quantity.

See Also:

TextData

kmbCopyrightTextEvent

public static final byte kmbCopyrightTextEvent

Copyright (include on start of every track).

 FF 02 len text
 

A copyright message (ie, text). It's best to put this event at the beginning of an MTrk.

Note that len could be a series of bytes since it is expressed as a variable length quantity.

See Also:

TextData

kmbTrackName

public static final byte kmbTrackName

Sequence/Track Name (include at beginning of track).

 FF 03 len text
 

The name of the sequence or track (ie, text). It's best to put this event at the beginning of an MTrk.

Note that len could be a series of bytes since it is expressed as a variable length quantity.

See Also:

TextData

kmbInstrumentName

public static final byte kmbInstrumentName

Instrument Name (for Type 1 files).

 FF 04 len text
 

The name of the instrument that the track plays (ie, text). This might be different than the Sequence/Track Name. For example, maybe the name of your sequence (ie, Mtrk) is "Butterfly", but since the track is played on a piano, you might also include an Instrument Name of "Piano".

It's best to put one (or more) of this event at the beginning of an MTrk to provide the user with identification of what instrument(s) is playing the track. Usually, the instruments (ie, patches, tones, banks, etc) are setup on the audio devices via MIDI Program Change events within the MTrk, particularly in MIDI files that are intended for General MIDI Sound Modules. So, this event exists merely to provide the user with visual feedback of the instrumentation for a track.

Note that len could be a series of bytes since it is expressed as a variable length quantity.

See Also:

TextData

kmbLyric

public static final byte kmbLyric

Lyrics.

 FF 05 len text
 

A song lyric (ie, text) which occurs on a given beat. A single Lyric MetaEvent should contain only one syllable.

Note that len could be a series of bytes since it is expressed as a variable length quantity.

See Also:

TextData

kmbMarker

public static final byte kmbMarker

Marker.

 FF 06 len text
 

A marker (ie, text) which occurs on a given beat. Marker events might be used to denote a loop start and loop end (ie, where the sequence loops back to a previous event).

Note that len could be a series of bytes since it is expressed as a variable length quantity.

See Also:

TextData

kmbCuePoint

public static final byte kmbCuePoint

Cue Point.

 FF 07 len text
 

A cue point (ie, text) which occurs on a given beat. A Cue Point might be used to denote where a WAVE (ie, sampled sound) file starts playing, where the text would be the WAVE's filename.

Note that len could be a series of bytes since it is expressed as a variable length quantity.

See Also:

TextData

kmbTextEvent08

public static final byte kmbTextEvent08

Generic Text MetaEvent.

 FF 08 len text
 

Note that len could be a series of bytes since it is expressed as a variable length quantity.

See Also:

TextData

kmbTextEvent09

public static final byte kmbTextEvent09

Generic Text MetaEvent.

 FF 09 len text
 

Note that len could be a series of bytes since it is expressed as a variable length quantity.

See Also:

TextData

kmbTextEvent0a

public static final byte kmbTextEvent0a

Generic Text MetaEvent.

 FF 0A len text
 

Note that len could be a series of bytes since it is expressed as a variable length quantity.

See Also:

TextData

kmbTextEvent0b

public static final byte kmbTextEvent0b

Generic Text MetaEvent.

 FF 0B len text
 

Note that len could be a series of bytes since it is expressed as a variable length quantity.

See Also:

TextData

kmbTextEvent0c

public static final byte kmbTextEvent0c

Generic Text MetaEvent.

 FF 0C len text
 

Note that len could be a series of bytes since it is expressed as a variable length quantity.

See Also:

TextData

kmbTextEvent0d

public static final byte kmbTextEvent0d

Generic Text MetaEvent.

 FF 0D len text
 

Note that len could be a series of bytes since it is expressed as a variable length quantity.

See Also:

TextData

kmbTextEvent0e

public static final byte kmbTextEvent0e

Generic Text MetaEvent.

 FF 0E len text
 

Note that len could be a series of bytes since it is expressed as a variable length quantity.

See Also:

TextData

kmbTextEvent0f

public static final byte kmbTextEvent0f

Generic Text MetaEvent.

 FF 0F len text
 

Note that len could be a series of bytes since it is expressed as a variable length quantity.

See Also:

TextData

kmbMidiChannel

public static final byte kmbMidiChannel

XXX.

kmbMidiPort

public static final byte kmbMidiPort

XXX.

kmbEndTrack

public static final byte kmbEndTrack

XXX.

kmbSetTempo

public static final byte kmbSetTempo

XXX.

kmbSmpteOffset

public static final byte kmbSmpteOffset

XXX.

kmbTimeSignature

public static final byte kmbTimeSignature

XXX.

kmbKeySignature

public static final byte kmbKeySignature

XXX.

kmbSequencerSpecific

public static final byte kmbSequencerSpecific

XXX.

kmid0

public static final byte kmid0

Start of defined Manufacturer IDs. Most manufacturers have been assigned a unique 7-bit manufacturer ID. Microsoft has an oddball manufacturer ID. It consists of 3 bytes, rather than 1 byte, and it is 0x00 0x00 0x41 . Note that the first byte is 0. The MMA sort of reserved the value 0 for the day when it would run out of the maximum 128 IDs available with using a single byte, and would need more bytes to represent IDs for new manufacturers.

See Also:

kmidEducationalUse, kmidUniversalNonRealtime, kmidUniversalRealtime

kmidSequentialCircuits

public static final byte kmidSequentialCircuits

kmidBigBriar

public static final byte kmidBigBriar

kmidOctavePlateau

public static final byte kmidOctavePlateau

kmidMoog

public static final byte kmidMoog

kmidPassportDesigns

public static final byte kmidPassportDesigns

kmidLexicon

public static final byte kmidLexicon

kmidKurzweil

public static final byte kmidKurzweil

kmidFender

public static final byte kmidFender

kmidGulbransen

public static final byte kmidGulbransen

kmidDeltaLabs

public static final byte kmidDeltaLabs

kmidSoundComp

public static final byte kmidSoundComp

kmidGeneralElectro

public static final byte kmidGeneralElectro

kmidTechmar

public static final byte kmidTechmar

kmidMatthewsResearch

public static final byte kmidMatthewsResearch

kmidOberheim

public static final byte kmidOberheim

kmidPAIA

public static final byte kmidPAIA

kmidSimmons

public static final byte kmidSimmons

kmidDigiDesign

public static final byte kmidDigiDesign

kmidFairlight

public static final byte kmidFairlight

kmidPeavey

public static final byte kmidPeavey

kmidJLCooper

public static final byte kmidJLCooper

kmidLowery

public static final byte kmidLowery

kmidLin

public static final byte kmidLin

kmidEmu

public static final byte kmidEmu

kmidBonTempi

public static final byte kmidBonTempi

kmidSIEL

public static final byte kmidSIEL

kmidSyntheAxe

public static final byte kmidSyntheAxe

kmidHohner

public static final byte kmidHohner

kmidCrumar

public static final byte kmidCrumar

kmidSolton

public static final byte kmidSolton

kmidJellinghausMs

public static final byte kmidJellinghausMs

kmidCTS

public static final byte kmidCTS

kmidPPG

public static final byte kmidPPG

kmidElka

public static final byte kmidElka

kmidCheetah

public static final byte kmidCheetah

kmidKawai

public static final byte kmidKawai

kmidRoland

public static final byte kmidRoland

kmidKorg

public static final byte kmidKorg

kmidYamaha

public static final byte kmidYamaha

kmidCasio

public static final byte kmidCasio

kmidAkai

public static final byte kmidAkai

kmidEducationalUse

public static final byte kmidEducationalUse

This ID is for educational or development use only, and should never appear in a commercial design.

kmidUniversalNonRealtime

public static final byte kmidUniversalNonRealtime

kmidUniversalRealtime

public static final byte kmidUniversalRealtime

Constructor Detail

EventStatus

public EventStatus()