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.
$encoder 1 - Jetzt wirds interessant. Mit diesem Kommando wird die Konfiguration des Bedienelents des Types "encoder" mit der Nummer 1 gestartet. Encoder 1 ist sowohl bei BCR als auch bei BCF immer der ganz links oben. Zur Aufteilung aller Bedienelemente kommen wir später.
.easypar - Dies bedeutet, dass jetzt eine einfache Parameterdefinition kommt. Viele Alltagsprobleme sind durch entsprechende easypar-Statements lösbar, sie stellen alles dar, was man so braucht, Control Changes, Program Changes, Pitch Bender usw. In unserem Falle lautet die Funktion "CC", also Control Change. Schaut man den Rest jetzt genau an, finden wir unsere Einstellungen am Gerät auch ganz schnell wieder. Die nachfolgenden Parameter für den easypar-Typ "CC" sind MIDI-Kanal (1), Controllernummer (16), Minimalwert (44), Maximalwert (55) und die Betriebsart, in diesem Falle absolute. Mehr zu Betriebsarten auch später. Hiermit ist im Prinzip jetzt schon das Verhalten des Encoders ausreichend definiert. Es gibt aber noch einige weitere Parameter, von denen sogar einige sehr wichtig sind, damit überhaupt Daten aus dem BC kommen.
.showvalue on - nicht lebensnotwendig, default ist "off", dieser Parameter steuert, ob bei Werteänderungen (also Drehen am Encoder) die aktuellen Werte im LED-Display eingeblendet werden. Nicht am LED-Ring um den Encoder, das ist ein anderer Parameter, showvalue stellt die Anzeige im 4-Stelligen LED-Display rechts oben ein.
.mode 12dot - Hier kommt nun der LED-Ring um den Encoder. Dieser kennt viele tolle Darstellungsarten, leider aber nur bei den ersten 32 Encodern, also den 8 Encodern in ihren 4 Gruppen. Die 24 Encoder im unteren Teil sind auf einen kleinen Teil der tollen Darstellungsarten beschränkt. Die Darstellungsart "12dot" bedeutet, daß an dem Ring 1 oder 2 LEDs leuchten, um den aktuellen Wert zu präsentieren. Mehr zu den verschiedenen Darstellungsarten auch später.
.resolution 24 24 24 24 - Dies ist ein sehr interessanter Parameter, weil er Einstellungen zulässt, die im Moment weder am Gerät noch mit einem der verfügbaren Editoren zu erreichen sind. Es geht hier um die Geschwindigkeit, wie der Encoder auf Werteänderungen wirkt, und das sogar noch abhängig von der Drehgeschwindigkeit. Da dies ein nicht ganz triviales Thema ist, gibts weiter unten dafür einen dedizierten Abschnitt, der das Verhalten halbwegs verständlich erklären soll. Hier reicht es erstmal, zu wissen, daß die Default-Werte alle 0 sind. Und das bedeutet - eine Encoder-Umdrehung mach 0 Werteänderung. Da damit auch eine unendlich große Anzahl Encoder-Umdrehungen 0 Werteänderungen machen, passiert also gar nichts, wenn dieser Parameter in der Encoder-Konfiguration fehlt, oder aufgrund eines Tippfehlers nicht ausgewertet werden kann. Vorsicht also an dieser Stelle, bei den ersten Gehversuchen kann man das leicht mal übersehen, und sucht den Fehler, warum der Encoder keine Daten schickt, dann an allen möglichen Stellen, aber nicht hier.
.default 44 - auch ein nützliches Feature, es setzt den Default-Wert, der so auch beim Abspeichern im Preset mit gespeichert wird. Lädt man dann das Preset nach einem Kaltstart, ist genau dieser Wert auf dem Encoder eingestellt.
$end - das letzte Kommando im Text. Es geht auch ohne, der BC ist hier abgesichert und beendet sein Warten nach etwa einer Sekunde selber. Um aber sauber zu arbeiten, sollte dieses Kommando auf jeden Fall in der Konfiguration ebenfalls vorhanden sein.
Eine saubere Konfigurationsdatei fängt also immer mit $rev R1 (BCR2000) oder $rev F1 (BCF2000) an und endet mit $end. Was dazwischen steht - da gibt es extrem viele Möglichkeiten. Doch fangen wir erst einmal mit der einfachsten Übung an - Kopieren eines Controllers. ...to be continued
