B-Control-Konfiguration
Dieser Artikel soll erläutern, wie man die B-Control-Boxen von Behringer auf eine ungewöhnliche, aber sehr effiziente Art konfigurieren kann. Diese Geräte können deutlich mehr, als die Bedienung am Gerät sehen lässt, der Editor von Behringer selber ist ja auch nicht so das Gelbe vom Ei, und andere Editoren sind rar.
Ein Grund, mal einen Preset-Dump des Gerätes zu analysieren, um eine Möglichkeit zu finden, wie man anderweitig seine Konfiguration da drin unterbringen kann, idealerweise sogar halbautomatisch, wenn man z.B. alle 24 Encoder einfach gleich konfigurieren will, jedoch unterschiedliche Controllernummern verwenden möchte. Außerdem sah es bisher so aus, als könnte die B-Control-Serie mit SysEx nichts anfangen, was sich bei genauerer Analyse auch als Täuschung herausstellt.
Um den Artikel nicht zu lang und damit unübersichtlich zu machen, wird er in mehrere Teile gesplitted, auch, um Anwendern unterschiedlicher Vorkenntnis-stände den besten Weg zu zeigen.
So ist es für den Laien anfangs sicherlich sinnvoll, sich über einige Grundlagen der Funktionsweise digitaler Datenverarbeitung, also über das Leben der Bits und Bytes zu informieren. Erst, wenn dieses Thema wirklich sitzt, kann man auch mit den komplexesten SysEx-Meldungen spielen, weil es genau dabei sehr häufig darum geht, Einen Wert ein Einzelteile zu zerlegen, um ihn zu übertragen. Wie solche Zerlegungen funktionieren, wird dann im Kapitel MIDI-Grundlagen erklärt. Nach diesen beiden Themen gehts dann hier in diesem Artikel weiter, und wer weiss, wie MIDI funktioniert, und auch weiss, wie vorzeichenbehaftete 7bit-Zahlen binär dargestellt werden, darf hier weiter lesen.
Nach den hier beschriebenen Tricks gibts dann noch die B-Control-Tokenreferenz, in der man über alle zur Verfügung stehenden Konfigurationskommandos ausreichend Informationen findet.
Internas zur Konfiguration der B-Control-Serie
Wie die meisten Geräte mit MIDI-Interface, werden auch diese über SysEx-Meldungen konfiguriert. Dies ist ein Format, was es dem Nutzer nicht sehr einfach macht, bequem am Rechner Änderungen an der Konfiguration vorzunehmen. Aber eine genaue Analyse des Formates lässt erkennen, daß die Konfiguration im Prinzip eine normale Textdatei ist, die einfach in SysEx-Meldungen verpackt wurde. Also ist es relativ einfach, einen Konverter zu programmieren, der zwischen diesen Textdateien und dem SysEx-Format konvertiert, um über die Textdatei bequem seine Konfiguration zu ändern. Dazu dient das Programm BC-Convert, welches auf seiner Wiki-Seite heruntergeladen werden kann, außerdem finden sich dort auch grundlegende Bedienhinweise.
Weiterhin ist die Konfiguration in dem Textfile strukturiert aufgebaut, sie besteht aus sogenannten Tokens, welche passend zusammen gefasst werden müssen. Die genauen Informationen zu allen bisher herausgefundenen Tokens und ihren Einsatzmöglichkeiten gibts B-Control-Tokenreferenz, hier sollen nur einige grundlegende Informationen und einige Tricks bei der Arbeit beschrieben werden.
Um also erstmal grundlegend etwas zum Arbeiten zu haben, gehen wir wie folgt vor:
Ein möglichst leeres Preset suchen, sofern noch vorhanden. Wenns keins gibt, wirds jetzt etwas voll in der Datei, geht aber auch. Nehmen wir also z.B. Preset 24, welches nach der "Init"-Angabe im Display noch leer ist. Nun konfigurieren wir den ersten Push-Encoder links oben: EDIT gedrückt halten und am ersten Encoder drehen, bis das Display "E 1" zeigt. Jetzt ist der Editiermodus aktiv. Jetzt folgende Einstellungen mit den 8 Encodern der ersten Reihe vornehmen:
1 - CC
2 - Ch 1
3 - 17
4 - 44
5 - 55
6 - Abs
7 - 2d
8 - on
Mit EXIT den Editiermodus verlassen, wir wollen jetzt dieses Preset, obwohl es nicht gespeichert ist, an den Computer schicken. Dazu ist natürlich eine funktionierende Verbindung über MIDI oder USB notwendig. Wenn diese steht, einfach einen SysEx-Dumper des Vertrauens starten (unter Windows z.B. MIDI-OX, unter MacOS X SysEx Librarian), und den B-Control dazu bewegen, das aktuelle Preset, bzw. genauer gesagt den Edit Buffer, an den Computer zu schicken:
EDIT halten, STORE drücken, bis EG im Display steht, dann beide Tasten wieder loslassen. Mit dem 6. Encoder auf "SnGL" stellen, den Encoder drücken, und alle eingehenden Messages aufnehmen (sollten um die 16 Stück sein).
Jetzt kann dieses Preser konvertiert und analysiert werden, also kommt BC-Convert zum Einsatz. Gehen wir davon aus, der Preset-Dump ist als BCR2000-Test.syx gespeichert, sieht das folgendermassen aus:
aphrodite:~/Documents/SysEx Librarian michael$ ./bc-convert -i BCR2000-Test.syx -o BCR2000-Test.txt BC-Convert Version 0.3 (C) 2006 Michael Kukat First byte is SysEx start - using SysEx to text conversion. aphrodite:~/Documents/SysEx Librarian michael$
Die Richtung, in die Konvertiert werden muss, stellt BC-Convert selber fest. Daher ist es sehr wichtig, sicherzustellen, dass man nicht die Dateien fuer Input (-i) und Output (-o) verwechselt hat. Sonst kann es durchaus mal passieren, dass man anfängt wie oben, dann stundenlang in der Textdatei editiert, diese wieder dem BC zuführen möchte, und versehentlich falschrum konvertiert, also wieder den Urzustand hat. Daher immer schön aufpassen, dass nix schief geht. Aber jetzt mal ans Eingemachte, wie schauen in das Textfile rein, in diesem Beispiel BCR2000-Test.txt.
# Generated by BC-Convert. Input was DeviceID 0, ModelID 21 $rev R1 $preset .name 'init ' .snapshot off .request off .egroups 4 .fkeys on .lock off .init $encoder 1 .easypar CC 1 16 44 55 absolute .showvalue on .mode 12dot .resolution 24 24 24 24 .default 44 $end
Sehr schön, so sieht das also von innen aus. Die ersten beiden Zeilen kommen nicht vom BC, sondern vom BC-Convert. Sie werden automatisch eingefügt, damit man später, falls man die Daten braucht, auch seine DeviceID und ModelID kennt. In diesem Fall ist die DeviceID 0, was der eingestellten ID 1 entspricht, und die ModelID ist 21, dies steht für BCR2000, der BCF2000 hat z.B. 20.
Es wurde schon oft beobachtet, dass hier per Default 127 und 127 eingetragen sind, diese Kombination wird auch beim Generieren der Daten von BC-Convert verwendet, und bedeutet, dass jedes angeschlossene Behringer-Gerät am Bus sich für die Daten interessiert, ausgewertet werden sie voraussichtlich von jedem B-Control am Bus. Wer also mehrere solcher Kisten sein Eigen nennt, wird BC-Convert auf jeden Fall mit den korrekten Parametern für das Gerät, was er füttern möchte, bestücken müssen, sonst werden alle gefüttert, wenn sie nich im SysEx-Tool gezielt angesteuert werden.
Aber schauen wir das gewonnene Textfile doch einmal an:
Analyse eines Dumps vom B-Control
$rev R1 - eine Versionskennung der Konfiguration, bei einem BCF2000 steht hier voraussichtlich F1 statt R1. Die 1 gibt dabei wohl die Version der Konfiguration an. Mit diesem Token wird die Konfiguration eingeleitet, ist dieses nicht vorhanden, werden alle nachfolgenden Tokens vom BC mit einer Fehlermeldung quittiert. Wichtig ist diese Zeile auch zur Unterscheidung, ob die Daten für einen BCR oder einen BCF sind.
$preset - Die Konfiguration eines Presets wird gestartet. Dies ist nicht unbedingt notwendig, man kann auch direkt im Edit Buffer rumfummeln, ohne mit Presets arbeiten zu müssen. Wir werden später auch noch sehen, daß dieses Preset nicht gespeichert wird, sondern aufgrund der folgenden Tokens nur den Edit Buffer leert.
Das $preset-Token kennt Untertokens, die die Ausführung des $preset-Kommandos genauer spezifizieren. Man erkennt hier die Trennung zwischen Kommandos, die mit einem Dollarzeichen eingeleitet werden und immer am Zeilenanfang stehen, und Optionen, die mit einem Punkt eingeleitet werden und immer 2 Zeichen eingerückt sind. Diese Formatierung ist kein Zwang, der BC überlebt es auch anders, aber es ist sicherlich ratsam, sich halbwegs daran zu halten. Ausserdem hat ((BC-Convert)) die Möglichkeit, mit Kommentaren in den Textdateien zu arbeiten, so wird alles ab einem Semikolon (;) oder einer Raute (#) in einer Zeile samt den davor liegenden Leerzeichen, einfach weggeworfen. Ist die Zeile danach leer, weil der Kommentar am Zeilenanfang stand, wird sie überhaupt nicht gesendet. Dieses Feature dient dazu, dass man sich in seinen Textdateien durch ausreichend Kommentare Übersicht verschaffen kann, diese Kommentare aber nicht an den BC geschickt werden, weil der sie nicht verstehen würde.
Nach diesem Abschweifen also weiter mit den $preset-Token und der ersten Option
.name - Diese Option dient dazu, dem Patch einen Namen zu geben. Er wird von Editoren angezeigt, aber sonst ist er nirgends sichtbar. Ist also reine Geschmackssache, ob man einen zuweist. Wichtig ist hierbei nur, dass er exakt 24 Zeichen lang sein muss und zwischen den einfachen Anführungszeichen steht. Genau so wie in dem File, was wir aus der aktuellen Konfiguration unseres Einfachst-Patches generiert haben.
Die anderen Parameter des $preset-Kommandos werden hier nicht erläutert, es sei wieder auf die B-Control-Tokenreferenz verwiesen. Interessant ist noch die Option
.init - Sie löscht den Edit Buffer. Damit kann man also mal alles platt machen, um eine komplett frische Konfiguration in den Edit Buffer zu laden.
Übrigens war hier jetzt noch kein einziges Schreibkommando mit dabei, und in diesem Textfile ist auch keines vorhanden, also passiert keinem der Presets etwas, egal, wieviel man herumschraubt. Das schliesst natürlich eventuelle, bisher noch unbekannte, Firmware-Fehler aus, die bei allzuviel Schweinkram vielleicht dazu tendieren, Mist zu bauen, dies erscheint jedoch unwahrscheinlich, weil während der Analyse der Möglichkeiten sehr sehr viel Schweinkram getrieben wurde. Übrigens basiert alles auf der Firmware-Version 1.10, für die hier beschriebenen Tricks sollte diese jedoch egal sein, solange man vom BCR generierte Daten nur verändert.
...to be continued
