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.

Die ersten manuellen Änderungen an der Konfiguration

Unser Ziel ist jetzt, einfach mal auf elegante, einfache Art die Encoder des BC zu belegen, ohne dabei wackelige Editoren oder gar das unkomfortable Interface am Gerät selber zu benutzen. Das ist ganz okay für kleinere Änderungen, aber nicht, wenn mal alle 56 Encoder (die oberen 8 zählen als 32, aufgrund der Gruppen) mit Control Changes zu belegen, da sind wohl einige Stunden Arbeit weg. Und wehe dann, man merkt, dass man alles nicht auf MIDI-Channel 1, sondern 2 haben will.

Als kleine Übung belegen wir also auf der Basis unseres einen Controllers die anderen Controller mal halbautomatisch, und passen dabei gleich die "versehentlich" falsch eingegebenen Wertebereiche an, ausserdem soll das alles auf Channel 2 und nicht mehr auf 1. Wenn wir schon dabei sind, können wir die Encoder gleich noch eine Ecke schneller machen, indem wir die Resolution anpassen. Also einfach die eine Encoder-Konfiguration anpassen, 3 mal kopieren, und die 3 Kopien mit anderen Controller-Nummern ausstatten (ich nehme absichtlich nur 4 Encoder insgesamt, weil Controller 16-19 frei verfügbar sind, auch, wenns kaum einen interessiert, weil jeder Hersteller sich Controller-Nummer frei Schnauze greift). Und dann noch ein paar Kommentare rein, um es übersichtlich zu gestalten. Das endgültige Textfile sieht dann etwa so aus:

# Meine erste verbastelte BCR2000-Konfiguration
#------------------------------------------------------------------------------
# Die ersten 4 Encoder werden den Controller-Nummern 16 bis 19 zugewiesen und
# senden diese auf MIDI-Kanal 2. Die Auflösung wurde auf 192 gestellt, um
# sicherzustellen, dass in weniger als einer kompletten Encoder-Drehung der
# gesamte Wertebereich 0-127 abgefahren werden kann.
#------------------------------------------------------------------------------

$rev R1                                 # Start der Konfiguration

# Im Folgenden wird ein Preset definiert. Dies ist nicht zwingend notwendig,
# es können auch im aktuellen Edit Buffer einzelne Elemente geändert werden,
# aber wir fangen mit der Preset-Definition an, um den Edit Buffer zu leeren.

$preset                                 # Start der Preset-Definition
  .name 'Mein erster Test        '      # Name im Moment mal egal
  .snapshot off                         # Keine Snapshots
  .request off                          # Kein Request-Kommando
  .egroups 4                            # 4 Encoder Groups
  .fkeys on                             # Funktionstasten aktiviert
  .lock off                             # Funktionstasten nicht gesperrt
  .init                                 # Edit Buffer leeren

# Erster Encoder - Controller 16, Channel 2, Werte 0-127

$encoder 1                              # Starte Encoder-Definition
  .easypar CC 2 16 0 127 absolute       # Control Change konfigurieren
  .showvalue on                         # Wert im Display anzeigen
  .mode 12dot                           # 1-2 Punkte im Ring anzeigen
  .resolution 192 192 192 192           # 192 Steps pro Umdrehung
  .default 0                            # Defaultwert 0

# Zweiter Encoder - Controller 17, Channel 2, Werte 0-127

$encoder 2
  .easypar CC 2 17 0 127 absolute
  .showvalue on
  .mode 12dot
  .resolution 192 192 192 192
  .default 0

# Dritter Encoder - Controller 18, Channel 2, Werte 0-127

$encoder 3
  .easypar CC 2 18 0 127 absolute
  .showvalue on
  .mode 12dot
  .resolution 192 192 192 192
  .default 0

# Vierter Encoder - Controller 19, Channel 2, Werte 0-127

$encoder 4
  .easypar CC 2 19 0 127 absolute
  .showvalue on
  .mode 12dot
  .resolution 192 192 192 192
  .default 0

# Alle Konfigurationsfiles immer sauber hiermit beenden

$end                                    # Ende der Konfiguration

Fein. Sehr viele Kommentare, gerade am Anfang sicherlich auch sinnvoll, um sich selber bewusst zu machen, was man da genau tut, und um es später auch nachvollziehen zu können. Jetzt versuchen wir mal, diese Konstruktion an den BC zu schicken:

aphrodite:~/Documents/SysEx Librarian michael$ ./bc-convert -i BCR2000-Test.txt -o BCR2000-Test.syx
BC-Convert Version 0.3 (C) 2006 Michael Kukat
First byte is no SysEx start - using text to SysEx conversion.
aphrodite:~/Documents/SysEx Librarian michael$ 

Das sieht gut aus, kein gemecker über ungültige Zeichen oder sowas, aber eine Fehlerprüfung ist im Konverter nicht wirklich vorhanden, es werden lediglich ungültige Zeichen erkannt und die Zeilen, in denen sie vorkommen, herausgeworfen. Technisch sind das alle Zeichen, deren ASCII-Code über 127 liegt. Dass man in der Datei kein UTF8 oder sowas verwenden sollte, brauche ich wohl nicht extra zu erwähnen.

Also. Hochladen. Und dabei ganz genau auf das Display des BC schauen. Es sollte nur diesen umlaufenden Balken darstellen. Im Zweifelsfall lieber mal ein paar ms mehr Pause zwischen den Messages einstellen, um es genau zu sehen. Wenn irgendetwas nicht stimmt, schreibt der BC nämlich "Err" aufs Display. Sollte das vorkommen, ist vielleicht irgendwo ein Tippfehler drin. Man kann übrigens, wenn man z.B. MIDI-OX verwendet, den Fehler genauer definieren, weil der BC jede Message, die er bekommt, mit einer Antwort quittiert, in der der Status drin steht. Allerdings wird es recht schwer, zu allen möglichen Fehlerstati auch die genaue Bedeutung zu ermitteln.

Wenn die Konfiguration erfolgreich hochgeladen wurde, sollten jetzt die 4 ersten Encoder in der Gruppe 1 einen schönen leuchtenden roten Punkt im LED-Ring haben. Und wenn man mit einem MIDI-Monitor schaut, wird man auch feststellen, daß genau das passiert, was wir haben wollten. Und was bisher noch nicht ging - endlich ist der gesamte Wertebereich ohne Verrenkungen und Umgreifen erreichbar, da wir den Encoder so eingestellt haben, daß eine Umdrehung 192 Werteänderungen sind. Und was es damit genau auf sich hat, kommt im nächsten Abschnitt.

Konfiguration der Auflösung (resolution)

...to be continued