MIDI Format

MIDI wurde in den frühen 1980er-Jahren erfunden und ist bis heute unverändert, was die Flexibilität des Protokolls deutlich macht. Es werden immer wieder Erweiterungen im Protokoll vorgenommen, weil die Urform diese Erweiterungsmöglichkeiten bereits vorgesehen hat. Die physikalische Datenübertragung soll hier nicht im Detail behandelt werden, es geht hier nur um alle Einzelheiten der Daten, die übertragen werden, die MIDI-Messages. Beim Lesen dieses Artikels ist es von Vorteil, fundiertes Wissen über Bits und Bytes zu haben, da hier viel mit binären und hexadezimalen Zahlen gearbeitet wird, und auch direkt Bits angeschaut werden.

MIDI ist eine serielle Schnittstelle, über die 8bit-Bytes übertragen werden können. Dabei hat das oberste Bit auch schon eine besondere Bedeutung.

Statusbytes und Datenbytes

Ist das oberste Bit des übertragenen Bytes gesetzt, also der Wert >= 128, so handelt es sich um ein Statusbyte. Das Statusbyte kann als Kommando angesehen werden, es dient der Entscheidung, was mit den nachfolgenden Datenbytes genau geschehen soll. Da bei den Datenbytes das oberste Bit nicht gesetzt sein darf, weil es sich sonst um ein Statusbyte handeln würde, schränkt dies den Wertebereich für Datenbytes auf die bekannten 7 Bits ein, einem Wertebereich von 0 bis 127. Um dennoch größere Werte übertragen zu können, gibt es viele verschiedene Methoden, die insbesondere im Abschnitt über die System Exclusive (SysEx) Meldungen beschrieben werden.

Aufgrund dieser strikten Trennung zwischen Statusbytes und Datenbytes gibt es noch ein Feature namens "Running Status", welches die Datenübertragung optimieren soll. So ist es bei vielen Statusbytes nicht zwingend erforderlich, für jede Message das gleiche Statusbyte nochmals zu senden, es werden nur noch die Daten geschickt. Kommt also ein Note-On-Event, wird das Statusbyte nebst den beiden zugehörigen Datenbytes geschickt. Folgen diesem Note-On-Event noch weitere Note-On-Events auf dem selben Kanal, ändert sich das Statusbyte also nicht, wird es nicht nochmals mitgeschickt, sondern in der nächsten Message werden nur die beiden Datenbytes geschickt, der Empfänger weiss dann, dass das zuletzt empfangene Statusbyte zur Bildung der Message verwendet werden soll. Einige Statusbytes müssen jedoch jedes Mal übertragen werden, und einige davon brechen auch einen Running Status ab, während es andere nicht tun. Dies wird im Detail im nächsten Abschnitt beschrieben. Um Running Status noch weiter zu optimieren, gibt es noch einen Sonderfall beim Note-On-Event. Da ein Note-Off-Event einen neuen Status erforderlich machen würde, was nicht unbedingt gewünscht ist, kann statt dem Note-Off-Event auch ein Note-On-Event mit Velocity 0 geschickt werden, was der Empfänger als Note-Off-Event interpretieren sollte. Bei diesem Vorgehen ist es natürlich nicht möglich, eine Release-Velocity mitzuschicken.

Running Status stelle ein Problem für einige frühe MIDI-Geräte dar, der Elka Synthex ist z.B. nicht ohne weiteres fähig, damit umzugehen. Wenn man mit einem modernen Keyboard einfach eine Taste anschlägt und wieder loslässt, wird hier der Status für Note-On nebst den Notendaten geschickt, beim Loslassen wird der Note-On mit Velocity 0 geschickt. Der Synthex interpretiert das fälschlicherweise als weiteres Note-On-Event und schaltet den Ton nicht ab.

Die Definition sieht keinen Timeout für Running Status vor, die meisten Geräte schalten jedoch den Running Status nach einer gewissen Zeit selber wieder ab, wenn also z.B. 3 Sekunden nichts übertragen wird, "vergisst" der Sender das letzte Statusbyte und die nächste Message ist wieder eine vollständige Message. Dies hat den Sinn, falls der Sender zwischendurch mal nicht "zuhört", weil er vielleicht aus- und wieder eingeschaltet wurde, und damit den Status selber vergisst. Kommen nun nur Datenbytes, weiss er damit nichts anzufangen, daher wird nach einer gewissen Inaktivität der Status auf jeden Fall wieder neu gesendet.

Die verschiedenen Statusbytes

Hier werden nun die möglichen Statusbytes und ihre genaue Funktion erläutert, auch ihre Auswirkung auf den Running Status wird mit erwähnt. Bei den meisten Statusbytes kann man schon aufgrund der Bits eine detailierte Vorentscheidung vornehmen, um welche Art von Message es sich handelt. Schauen wir einmal die Bits genauer an:

1 s s s c c c c

Das oberste Bit ist bei einer Statusmeldung immer gesetzt. Die nachfolgenden 3 Bits geben nun Auskunft über den Status selber, und wenn diese im Bereich 0 bis 6 liegen, sind die unteren 4 Bits der MIDI-Kanal. Der Mensch beginnt üblicherweise das Zählen bei 1, daher gibt es nach außen hin MIDI-Kanäle 1 bis 16. Intern wird dies jedoch, da der Computer bei 0 beginnt, mit 0 bis 15 abgebildet, so kommt man mit den vorhandenen 4 Bits für den Kanal aus. Dies gilt bei einem Status von 0 bis 6, also einem Statusbyte von 0x80 bis 0xef. Meldungen mit diesen Statusbytes werden "Voice Messages" genannt, weil sie alle einen direkten Zusammenhang mit dem von der Voice zu erzeugenden Ton haben. Voice Messages sind generell fähig, Running Status zu verwenden. Running Status funktioniert nur, wenn der MIDI-Kanal zwischen den Messages gleich bleibt. Für Running Status ist das Statusbyte als ganzes zu sehen. Kommen also 5 Note-On-Events, 3 davon auf Kanal 1 und 2 davon auf Kanal 2, so muß bei diesem Kanalwechsel auf jeden Fall ein neues Statusbyte mitgeschickt werden, weil sonst die letzten beiden Messages ebenfalls Kanal 1 zugeordnet werden. Ab dann gilt Note-On auf Kanal 2 als gespeichert, wenn nun Noten auf Kanal 1 eingeschaltet werden sollen, muss entsprechend wieder ein neues Statusbyte geschickt werden.

Bei Meldungen, wo alle s-Bits ebenfalls 1 sind, also bei Statusbytes >= 0xf0, gilt der Kanal nicht mehr. Hier kann aber wieder mit einer Bitmaske zur weiteren Entscheidung gearbeitet werden:

1 1 1 1 r s s s

Alle Statusbytes sind >= 0xf0, also sind die oberen 4 Bits alle 1. Das Bit 3 hat hier nun eine weitere Entscheidungsrolle. Ist es 0, also das Statusbyte zwischen 0xf0 und 0xf7, handelt es sich um eine sogenannte System Common Message, diese Kategorie vereint Nachrichten, die üblicherweise Datenbytes als Parameter benötigen, also nach dem Statusbyte meistens noch Datenbytes folgen werden. Natürlich gibt es hier auch Ausnahmen, wie wir später sehen werden. System Common Messages sind nicht fähig, Running Status zu benutzen, darüber hinaus brechen sie einen Running Status sogar ab. Wird also nach einem Note-On eine SysEx-Meldung geschickt, die aus den Status-Bytes 0xf0 und 0xf7 und dazwischen liegenden Datenbytes besteht, muss der Empfänger seinen Status löschen und der Sender muss bei der nächsten Voice Message auf jeden Fall wieder ein Statusbyte mitschicken. Datenbytes, die nach einer abgeschlossenen System Common Message folgen, müssen vom Empfänger ignoriert werden, weil es hierzu keinen Status gibt.

Ist das r-Bit gesetzt, also Statusbytes zwischen 0xf8 und 0xff, handelt es sich um System Realtime Messages. Diese können jederzeit in die Übertragung eingeschoben werden, ohne eine eventuell laufende Nachricht zu beeinträchtigen. So kann z.B. ein Note-On Status übertragen werden, dann das erste Datenbyte für Note-on, jetzt eine System Realtime Message, z.B. MIDI-Clock, und dann das zweite Datenbyte für Note-On, beide Messages werden vom Empfänger vollständig und korrekt erkannt, und der Running Status nach dieser Übertragung steht auf "Note On", da System Realtime Messages keinerlei Einfluss auf Running Status haben, und natürlich auch selber keinen Running Status nutzen können.

Eine System Realtime Message kann auch während einer System Common Message auftreten, dies wird wohl am Häufigsten bei SysEx-Messages der Fall sein, da diese möglicherweise relativ lange zum Übertragen brauchen, aber ein MIDI-Clock (0xf8) sofort durchkommen muss, da diese Message eben in Echtzeit (realtime) behandelt werden muss. Nach dieser Realtime-Message wird die Übertragung der SysEx-Message ganz normal fortgeführt.

Nun zu den einzelnen Message-Typen

0x80 - Note Off

Wie oben beschrieben, besteht das Note-Off-Event nicht nur aus dem Byte 0x80, sondern aus dem Bereich 0x80 bis 0x8f, weil in den unteren 4 Bits der MIDI-Kanal codiert ist. Dies trifft für alle weiteren Voice Messages zu und wird daher nicht bei jeder Message neu erwähnt.

Das Note-Off Event kennt 2 Datenbytes als Parameter. Das erste ist die Notennummer von 0 bis 127, das zweite die Geschwindigkeit, in der die Taste losgelassen wird, auch Release Velocity genannt, ebenfalls im Wertebereich von 0 bis 127.

Note-Off teilt dem Empfänger mit, dass der Ton mit der angegebenen Note gestoppt werden soll. Im Prinzip ein "Gate Off", die Release-Phase der Hüllkurve setzt ein. Einzige Ausnahme von der sofortigen Behandlung des Note-Off Events ist die Verwendung eines Sustain Pedals. Ist dieses eingeschaltet, soll sich der Empfänger nur dieses Note-Off-Event an einem geeigneten Ort aufbewahren, bis das Sustain Pedal abgeschaltet wird, erst dann wird auch der Ton abgeschaltet. Dieses Verhalten ist aber vom Empfänger abhängig, und möglicherweise auch auf Patch-Ebene steuerbar, so macht es bei einem Klavierpatch sicherlich sinn, das Sustain-Pedal zu nutzen, bei einer Bassdrum aber eher nicht.

0x90 - Note On

Das Gegenstück zu Note Off, hier wird dem Empfänger mitgeteilt, dass ein Ton zu spielen ist, also Gate eingeschaltet wird und ein Trigger abgesetzt wird. Als Parameter werden auch hier 2 Datenbytes übertragen - die Notennummer und die Anschlagsstärke, auch Velocity genannt. Wie üblich sind beide Datenbytes im Wertebereich 0 bis 127. Einen Sonderfall stellt aber die Velocity 0 dar. Wie oben bei Running Status beschrieben, stellt ein Note-On Event mit der Verlocity 0 eigentlich ein Note-Off Event dar. Entsprechend wird es dann auch als Note Off behandelt, die Logik mit dem Sustain Pedal greift auch hier, der einzige Unterschied zu einem echten Note Off ist das Fehlen der Release Velocity. Der Empfänger könnte hier einen Standardwert annehmen, sofern er überhaupt die Release Velocity auswertet.

0xa0 - Aftertouch

Dieser Nachrichtentyp ist nicht der Aftertouch, wie ihn die meisten kennen, sondern der selten zu findende polyphone Aftertouch. Diese Message hat einen Bezug zu einer gespielten Note, daher wird dieses Event direkt von der zugehörigen Taste generiert, und nicht wie beim Channel Aftertouch vom gesamten Keyboard. Entsprechend kennt diese Message 2 Datenbytes, das erste ist die Notennummer, auf die sich der neue Druck bezieht, das zweite ist der Druck, der auf die Taste ausgeübt wird, im Wertebereich von 0 (sehr leicht) bis 127 (sehr stark).

0xb0 - Control Change

Eine Control-Change-Nachricht gibt Informationen über einen Controller, dessen Wert sich geändert hat. Der Controller kann dabei so ziemlich alles sein, von einem einfachen Schalter, der nur 2 unterschiedliche Werte kennt, über ein Potentiometer als analoges Eingabegerät, ein Drehencoder als virtuell-analoges Eingabegerät, oder auch völlig obskure Geräte wie der Abstand der Hand zur Antenne bei einem Theremin-ähnlichem Eingabegerät. Bekannte Controller sind das Modwheel und die MIDI Volume, beides wird jeder schon einmal benutzt haben. Die vordefinierten Controllernummern werden später noch behandelt.

Die Nachricht beinhaltet neben dem Statusbyte auch 2 Datenbytes, das erste ist die Controllernummer, das zweite der Controllerwert, wieder beide im Bereich 0 bis 127. Negative Controllerwerte gibt es offiziell nicht, zu diesem Thema jedoch später mehr.

0xc0 - Program Change

Dient zum Umschalten des Sounds bei Synthesizern, kann aber auch anderen Funktionen zugeordnet sein, z.B. die Controllerzuordnung bei einem MIDI-Controller. Generell wird hiermit ein Stück Konfiguration ausgewählt, sei es ein Patch, ein Preset, ein Program, wie auch immer es beim jeweiligen Gerät genannt wird.

Die Message verwendet nur ein Datenbyte, die Programmnummer, wieder im Bereich 0 bis 127. Dies muss keinen echten Zusammenhang mit der auf dem Display angezeigten Patchnummer des Gerätes haben, da die Hersteller die unterschiedlichsten Formen der Datstellung verwenden. Nur sehr wenige geben ihren Patches Nummern von 0 bis 127, häufiger gesehen ist der Bereich 1 bis 128, also ist die Anzeige auf dem Display 1 höher als die eigentlich übertragene Programmnummer. Andere Hersteller arbeiten nicht direkt mit dem Dezimalsystem, sondern kennen Patches von 11 bis 88, wobei jede der beiden Ziffern nur die Werte 1 bis 8 kennt, was insgesamt 64 Kombinationsmöglichkeiten entspricht. Wird also Program 0 angesteuert, entspricht dies dem Displaywert 11, Program 1 wäre 12, Program 8 wäre 21 bis hin zu Program 63, was dem Display 88 entspricht. Damit sind nur 64 verschiedene Programme möglich, was mit den anderen 64 gemacht wird, bleibt dem Gerätehersteller überlassen, entweder werden alle Werte >= 64 einfach ignoriert, oder sie erfüllen den gleichen Zweck wie die Werte 0 bis 63, also sind im gesamten Wertebereich alle Patches doppelt vorhanden, oder es kann damit zusätzlich noch eine Bank umgeschaltet werden, womit das Display vielleicht von A11 bis B88 geht, wobei A11-A88 die Programs 0 bis 63 sind, und B11-B88 die Programs 64 bis 127.

Wieder andere Geräte kennen die Patches 0 bis 99, hier werden dann Werte ab 100 möglicherweise ignoriert, das genaue Verhalten ist immer herstellerabhängig.

0xd0 - Channel Pressure

Hier ist nun der Aftertouch, den jeder kennt, der Channel Aftertouch, offiziell in der MIDI-Sprache auch Channel Pressure genannt. Er verhält sich an für sich wie der oben erwähnte Aftertouch, gilt jedoch nicht pro Note, sondern für die gesamte Voice, also alle zur Zeit gespielten Noten. Dadurch, daß er damit keinen Notenwert übertragen muss, verwendet er auch nur ein Datenbyte, eben den Druck aufs Keyboard im Bereich von 0 (sehr leicht) bis 127 (sehr stark).

0xe0 - Pitch Wheel

Hier kommt nun die erste Ausnahme aus der Welt der 7bit-Übertragung. Da ein Pitch Wheel eine möglichst hohe Auflösung haben sollte, ist dieser Controller als eigenständige Sonderfunktion definiert worden. Er verwendet 2 Datenbytes, die zusammen den 14bit-Wert ergeben. Dazu wird dieser 14bit-Wert in der Mitte geteilt, das erste Datenbyte stellt die Bits 6-0 dar, das zweite Datenbyte die Bits 13-7. Der Empfänger nimmt also das zweite Datenbyte, schiebt es 7 Bits nach links und heftet unten das erste Datenbyte an, um wieder einen 14bit-Wert zu bekommen.

Eine weitere Ausnahme stellt die Tatsache dar, dass das Pitch Wheel sowohl positive als auch negative Werte senden kann. Die Mittelstellung bedeutet dabei genau 0. Da negative Werte bei MIDI nicht vorgesehen wird, wird der Wert einfach von 0 bis 16383 gesendet, der Empfänger weiss aber, da es sich um das Pitch Wheel handelt, dass er von dem empfangenen Wert nochmal 8192 subtrahieren muss. Somit entsteht ein Wertebereich von -8192 bis +8191.

0xf0 - SysEx Start

Nun kommen wir von den Voice Messages zu den System Common Message, und dabei auch sofort zu dem kompliziertesten Message-Typ. System Common Messages enthalten keinen MIDI-Kanal, darum gilt für alle folgenden Messages nicht obige Regel, dass die unteren 4 Bits der MIDI-Kanal sind, sondern bei allen Messages ab hier ist das komplette Statusbyte angegeben.

SysEx ist eine der Erweiterungsmöglichkeiten des MIDI-Protokolls. Hier kann man sich eigene Messages definieren, die darüber hinaus auch keine feste Datengrösse haben, sondern beliebig viele Datenbytes verwenden können, da es einen weiteren Status zum Beenden dieser Message gibt. Es werden also alle Bytes zwischen dem Status 0xf0 und dem abschliessenden Status 0xf7 als Daten einer SysEx-Message behandelt.

Damit es keine Kollisionen durch Wildwuchs in den übertragenen Daten gibt, und Hersteller 1 eine gut gemeinte Message implementiert "Schalte Displaybeleuchtung auf rot um", während Hersteller 2 genau die gleichen Daten verwendet, um "leite Selbstzerstörung ein" zu formulieren, was zu gewissen Komplikationen im Studio-Setup führen könnte, gibt es eine zentrale Verwaltung bei der MMA, der MIDI Manufacturers Association, die jedem Hersteller eine eigene Kennung zuweist. Diese Liste kann auch jeder hier anschauen.

Entsprechend ist es quasi Gesetz, dass diese Hersteller-Nummer direkt auf den Status 0xf0 folgt, um vorab eine Selektierung nach Hersteller vorzunehmen.

Schaut man sich die Herstellernummern (die bei der MMA nicht bis in alle Ewigkeit zurück zu reichen scheint, da es noch viel mehr reservierte Herstellernummern gibt, z.B. ist in der Liste Sequential oder Moog gar nicht zu finden) genauer an, erkennt man ein einfaches Muster:

Es fing an mit den Erfindern von MIDI, Sequential Circuits. Sie haben die Herstellernummer 1. Ab hier zählt es aufwärts, bis 0x18, EMU. Dann kommt 0x20, Bon Tempi, ein europäischer Hersteller, bis hin zu Waldorf, 0x3e, ebenfalls europäisch. Ab 0x40 wirds japanisch - Kawai hat diese ID, wie man auch bei der MMA nachlesen kann. Also sind die Hersteller-IDs an glatten Bereichsgrenzen (wenn man es hexadezimal liest) in Regionen unterteilt. Da zu erwarten war, dass 32 Hersteller pro Region knapp werden könnte, wenn die Verbreitung Computergesteuerter Musikinstrumente zunimmt, wurde ein Sonderfall eingeführt - ist das erste Byte nach dem Status 0xf0 ein 0x00, so handelt es sich um eine lange Hersteller-ID, die direkt auf die 0x00 folgt. Damit wurden zu dem Bereich der bisherigen 127 Hersteller nochmal weitere 16384 Hersteller oben drauf gelegt. Bei dieser langen Hersteller-ID erkennt man aber auch wieder das klassische Schema, 0x00 und 0x01 sind USA, 0x20 ist Europa, und ein Vertreter aus dem japanischen Raum mit langer Hersteller-ID ist auch als Beweis vorhanden - 0x40 ist wieder die japanische Region.

Nach diesem Abschweifen in die Zahlenspiele, die nur verdeutlichen sollen, dass Herstellernummern > 0 mit diesem einen Byte abgeschlossen sind, bei der Herstellernummer 0 aber nochmal 2 Bytes für die lange Herstellernummer folgen, geht es nun weiter.

Bisher haben wir also 0xf0 und die Herstellernummer, entweder in einem oder in 3 Bytes. Was nun danach kommt, bleibt voll und ganz dem Hersteller überlassen, er darf hier tun und lassen, was er will, sollte aber natürlich schon beim ersten Gerät sicher stellen, daß er auch noch ein zweites Gerät auf den Markt bringen kann, ohne Probleme mit seinen Messages vom ersten Gerät zu bekommen. Daher ist in den folgenden Bytes üblicherweise noch eine vom Hersteller vergebene Modellnummer vorhanden, diese kann ein Byte sein, wenn der Hersteller in seiner gesamten Existenz nur 128 verschiedene Geräte bauen möchte, oder auch 2 Bytes, wenn er mehr einplant. Natürlich kann er auch einen Wert als Sonderfunktion frei lassen, um später mal auf lange Modellnummern zu wechseln, wie es die MMA bei den Herstellernummer getan hat. Es gibt hier keine feste Definition.

Ausserdem ist möglicherweise noch eine weitere ID vorhanden, eine Gerätenummer. Diese sagt nichts über den Gerätetyp aus, sondern stellt eine weitere Identifikation dar, da es durchaus vorkommen kann, dass in einem Setup mehrere identische Geräte eines Herstellers vorhanden sind. Damit nicht alle diese Geräte gleichzeitig auf die Message reagieren, was in vielen Fällen unpraktisch sein könnte, gibt es noch die Geräte-ID. Diese ist in etwa zu vergleichen mit dem MIDI-Kanal, aber auch hier gibt es keine feste Definition, es hat sich aber eingebürgert, nur die Werte 0 bis 126 für Geräte-IDs zu verwenden, und die 127 als Spezial-ID für "an alle". Dadurch kann man sich z.B. 127 identische Soundmodule ins Rack (bzw. die Racks) packen, alle an einem MIDI-Kabel laufen lassen (unrealistisch, es geht um die Theorie :), und jedem Gerät aufgrund seiner ID gezielt seine ganz persönliche Konfiguration zuschieben, aber z.B. ein Firmware-Update auf Geräte-ID 127 loszuschicken, womit alle Geräte gleichzeitig ihr Firmware-Update durchziehen.

Übrigens gibt es auch spezielle Herstellernummern für Hobbyzwecke und Entwicklung. Der Hersteller 0x7d ist für Eigenbauten zu empfehlen, die aber niemals das eigene Setup verlassen sollten. Sobald etwas auf den Markt kommen soll, ist es notwendig, sich bei der MMA eine eigene Herstellernummer registrieren zu lassen.

Darüber hinaus gibt es noch 2 Hersteller-IDs für Sonderfälle, also Erweiterungen des MIDI-Standards, die herstellerunabhängig sind und ihrerseits auch wieder in separaten Standards festgeschrieben sind. Hierzu gibt es die Hersteller-IDs 0x7e und 0x7f. Bei diesen Hersteller-IDs ist es auch fest definiert, dass als nöchstes Byte die Geräte-ID kommt. Da es keine Modell-ID geben wird, weil die Messages ja herstellerunabhängig und damit auch geräteunabhängig sind, reicht diese Geräte-ID, quasi der Kanal, auch aus, um gezielt bis zu 127 Geräte zu adressieren. 127? Ja, nicht 128, weil die 127, wie oben schon beschrieben, bedeutet, daß das Gerät auf jeden Fall auf diese Message hören soll, unabhängig von der konfigurierten Geräte-ID.

Zu den Einsatzfällen dieser IDs gehören die GM-Spezifikation, der Sample Dump Standard und einige weitere nützliche Helferlein, die dem Musiker, der mit der ganzen EDV so wenig wie möglich zu tun haben möchte, das Leben etwas einfacher machen. Stichwort "Scanne MIDI-Bus" - hierfür gibt es einen Identity Request. Allerdings ist der bei vielen Geräten, vor allem älteren Modellen, nicht implementiert, weshalb hier auch gerne andere Mechanismen verwendet werden.

So haben wir also nun ausgiebig das Thema SysEx-Message behandelt, ohne wirklich sehr viel darüber zu wissen. Schauen wir die Erkenntnisse einmal kurz anhand einer Message an:

f0 00 20 32 15 01 20 00  00 24 72 65 76 20 52 31 f7
|  |  |  |  |  |  |  --------------------------- |
|  |  |  |  |  |  |  |                           + Ende der SysEx-Message
|  |  |  |  |  |  |  + Daten
|  |  |  |  |  |  + Kommando ans Gerät "Konfigurationsdaten"
|  |  |  |  |  + Geräte-ID 1
|  |  |  |  + Modell - BCR2000
|  |  +--+ Hersteller - Behringer
|  + Verwende lange Hersteller-ID
+ Start der SysEx-Message