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.

Interna 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 - 16
• 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)

Einer der interessantesten Parameter für Drehencoder ist .resolution. Dieser Parameter benötigt 4 Werte, deren genaue Bedeutung hier erklärt werden soll.

Die Encoder im BC sind sehr hochauflösende Typen. Sie generieren 96 Impulse pro Umdrehung, und natürlich lässt sich für jeden Impuls die Richtung erkennen. Die Auflösung ist nun ein Umrechnungsfaktor, wie viele Impulse pro Umdrehung für die Werteänderung herangezogen werden. Ist ein Wert genau 96, bedeutet das, dass 96 Änderungen pro Umdrehung generiert werden. Ist der Wert also 0, so ist er nach einer vollen Umdrehung 96, und die Schrittweite ist dabei genau 1. Um mehr Präzision, also eine geringere Schrittweite zu erreichen, wird ein kleinerer Wert verwendet. Dabei ist es sinnvoll, immer möglichst glatte Verähltnisse zu den 96 Pulsen pro Umdrehung zu verwenden. Also eine Teilung durch 2, 4, 8 usw. oder eine Multiplikation mit 2, 4, 8 usw. Bei der oben verwendeten Auflösung von 192 werden 192 Werteänderungen pro Umdrehung erreicht. Allerdings leidet auch die Auflösung ein wenig darunter. Da der Encoder nur 96 Pulse pro Umdrehung generiert, bekommen wir so automatisch eine Schrittweite von 2. Also erscheinen beim langsamen Drehen die Werte 0 - 2 - 4 - 6 - 8 usw... Wenn man also den kompletten Wertebereich mit einer Umdrehung erfassen will, muss man also mit diesem Kompromiss leben.

Der Grund, warum es 4 Werte beim .resolution-Parameter gibt, ist nun relativ einfach - es gibt eine Beschleunigungsfunktion, die insbesondere bei breit gefächerten Wertebereichen greift. Mit einem 14bit-controller, dessen Wertebereich immerhin 16384 unterschiedliche Werte umfasst, würde man sich mit der Einstellung 96 96 96 96 die Finger wund kurbeln, um den kompletten Wertebereich abzufahren. Daher wird hier die Geschwindigkeit der Werteänderung von der Drehgeschwindigkeit abhängig gemacht. Welche Drehgeschwindigkeiten genau die 4 Werte triggern, ist nicht bekannt, hier sollte einfach experimentiert werden, weil eine physikalische Angabe wie "ab 10 Umdrehungen pro Minute" keinem wirklich weiter hilft, was eine saubere Einstellung angeht.

die erste Zahl gilt hierbei für die langsamste Drehgeschwindigkeit, dies steigert sich bis zur letzten Zahl, die schon ein ziemlich schnelles Drehen erfordert. Aus dem Kompromiss mit den 192 Werteänderungen pro Umdrehung könnte also mit einem Parameter der Art

.resolution 96 96 192 192

der Encoder so eingestellt werden, dass es in langsamer Drehgeschwindigkeit möglich ist, jeden Wert einzustellen, bei schnellem drehen aber der Wertebereich ohne Umgreifen durchgefahren werden kann. Das in der Firmware fest eingestellte Verhalten, welches eingesetzt wird, wenn man am Gerät einen Encoder konfiguriert, sieht wie folgt aus:

Die Werte werden abhängig von dem Wertebereich, den der Encoder bedienen soll, eingestellt. Für die folgenden 4 Stufen werden dabei folgende Einstellungen verwendet:

• bis 20 - 24 24 24 24
• bis 200 - 96 96 96 96
• bis 2000 - 96 192 384 768
• ab hier - 96 192 768 2304

Anzeigemodi der LED-Ringe

Es gibt 2 Sets an Anzeigemodi, die von den LED-Ringen verwendet werden können. Leider ist es nur den oberen 8 Encodern vorbehalten, alle Möglichkeiten zu nutzen, die 24 unteren Encoder können nur relativ primitive Anzeigemodi darstellen. Möglicherweise hängt das damit zusammen, daß mit dem LED-Display im Gerät 546 LEDs verbaut sind, die natürlich alle ihren Strom brauchen. Würde man jede LED mit 5mA ansteuern, und mit der Differenz der maximal möglichen einen LED pro Encoder auf den unteren 24 gegenüber den maximal möglichen 15 LEDs pro Encoder auf den oberen 8 rechnen, so wären das 14 LEDs mal 24 Encoder mal 5mA = satte 1,68A. Diese Lastdifferenz ist vermutlich für das interne Netzteil einfach zu viel, weswegen die unteren 24 Encoder eben nur eingeschränkte Darstellungsmöglichkeiten haben.

Nun zu den diversen Darstellungsmöglichkeiten und ihrer Benennung im Konfigurationsfile:

off

(Display: off) Sagt schon alles aus - es wird kein LED-Ring dargestellt

1dot

(Display: 1d) Zeigt genau einen Punkt an, beim Minimalwert den ganz links, beim Maximalwert den ganz rechts

1dot/off

(Display: 1d-) Zeigt wie 1dot genau einen Punkt an, jedoch wird beim Minimalwert der Ring abgeschaltet. Gut, wenn 0 wirklich 0 ist, dann leuchtet nichts.

Hier ist nun die Grenze zwischen den Darstellungsmöglichkeiten. Alle nachfolgenden Darstellungsmöglichkeiten können nur noch auf Encoder 1-32, also den oberen 8 Encodern in ihren 4 Gruppen verwendet werden.

12dot

(Display: 2d) Zeigt einen oder zwei Punkte an, es wird also die Anzeigeauflösung künstlich erhöht, indem ein Punkt jetzt quasi "breiter" ist, und beim Übergang von einem auf den nächsten Punkt in einem gewissen Bereich beide Punkt leuchten.

12dot/off

(Display: 2d-) Analog zu 1dot/off wird hier beim Minimalwert der Ring wieder abgeschaltet.

bar

(Display: bar) Wie ein VU-Meter, es wird nicht punktweise dargestellt, wo der Wert gerade sitzt, sondern es werden alle Punkte ab dem ersten bis zu dem zu dem Wert gehörenden eingeschaltet, quasi ein Leuchtbalken um den Encoder. Sehr gut geeignet für z.B. Pegeleinstellungen

bar/off

(Display: bar-) Wiederum wird hier gegenüber bar beim Minimalwert der Ring abgeschaltet

spread

(Display: sprd) Hier liegt der Minimalwert in der Mitte des Rings, und mit Vergrößerung des Wertes breitet sich der Ring nach links und rechts aus. z.B. für Controller geeignet, die die Amplitude eines LFOs ändern, der Pitch moduliert, in Insiderkreisen auch als Modwheel bekannt.

pan

(Display: pan) der Name ist Programm. Der Mittelwert des Controller-Bereichs sorgt dafür, daß der mittlere Punkt im Ring leuchtet. Verkleinert man den Wert, wird der Ring von der Mitte ausgehend nach links vergrössert, vergrößert man den Wert, breitet er sich nach rechts aus. Entsprechend gut für Pan-Regler geeignet.

qual

(Display: qual) Genau das Gegenteil von spread. Der Maximalwert liegt in der Mitte, verkleinert man den Wert, breitet sich der Ring nach links und rechts aus.

cut

(Display: cut) Der Name sollte wohl für Cutoff stehen, gilt aber in diesem Falle nur für Hochpassfilter. Dieser Modus ist das Gegenteil von bar. Beim Minimalwert ist der Ring voll beleuchtet, beim Maximalwert leuchtet nur der Punkt ganz rechts.

damp

(Display: damp) Ein gespiegelter bar. Sieht aus wie cut mit vertauschten Werten. Beim Minimalwert leuchtet nur der Punkt ganz rechts, beim Vergrössern des Wertes breitet sich der Ring nach links aus (wenn man nach rechts dreht...).

Senden von SysEx-Meldungen oder skurrilen Spezialkonstruktionen

So, jetzt kommt das, worauf viele schon lange warten - senden von System Exclusive-Nachrichten über den BCR. Dies setzt stellenweise die tiefere Kenntnis über Bits und Bytes voraus, da genau solche bevorzugt in SysEx-Nachrichten gerne vorkommen und entsprechend sortiert werden müssen.

Wir haben oben bereits den Parameter .easypar kennen gelernt, mit dem man all die offiziellen Features dec BC konfigurieren kann. Darüber hinaus gibt es noch zwei weitere Parameter, .tx und .minmax, die statt dem .easypar eingesetzt werden können. easypar und tx können nicht gleichzeitig benutzt werden, bzw. sollten nicht, es würde keinen Sinn ergeben. Im Prinzip kann man alles, was man mit easypar formulieren kann, auch mit tx und minmax formulieren, nur ist es für normale Konfigurationen üblicherweise übersichtlicher, easypar zu verwenden. Mit tx ist es auch möglich, mehrere Messages zu schicken, wie dies z.B. bei 14bit Control-Changes oder einem Pitchbender sinnvoll wäre, wenn einem der normale Umfang des BC nicht ausreicht. So ist der Pitchbender in der Spezifikation als 14bit vorgesehen, kaum ein Gerät schick ihn jedoch auch so raus, in der Regel werden nur die oberen 7 Bits verwendet. Und der BC kann auch nur mie einem 7bit Pitchbender arbeiten, ausser man definiert ihn mit tx selber.

Schauen wir beide Parameter an:

.tx <wert> [wert [wert...]]

Hinter .tx werden einer oder mehrere Werte angegeben. Ein Wert macht dabei nur Sinn, wenn man sich echte 1-Byte-Kommandos wie "Tune Request" definieren möchte. Meistens sind es mehrere Werte. Diese können als Zahlen angegeben werden (entweder dezimal oder hexadezimal mit vorgestelltem Dollarzeichen ($)), aber auch bestimmte Schlüsselwörter sein, mit denen sehr vielfältige Funktionen erreicht werden, sogar Prüfsummenberechnungen sind möglich, wie sie von einigen Geräten erwartet werden.

.minmax <min> <max>

Da .tx nur mit der eigentlichen Nachricht bestückt wird, wird der Wertebereich des Encoders oder Faders (oder die beiden Werte eines Buttons) über diesen Parameter angegeben.

Legen wir also los mit einem einfachen 7bit-Encoder, der eine SysEx-Nachricht schicken soll. Ohne auf die genaue Struktur der Nachricht einzugehen (dies ist in MIDI-Grundlagen beschrieben), nehmen wir an, in der Anleitung des zu steuernden Gerätes steht folgendes drin:

F0H 00H 20H 7DH 01H 01H 17H <val> F7H
Set filter cutoff to <val> (7 bit unsigned)

Dann basteln wir uns mal den Encoder 1 passend hin:

$encoder 1
  .tx $f0 $00 $20 $7d $01 $01 $17 val $f7
  .minmax 0 127
  .showvalue on
  .mode 1dot
  .resolution 96 96 96 96
  .default 64

Das wars schon. Tut ja gar nicht weh. Und hier sehen wir auch schon den Platzhalter für den Wert in der Message, als Wert ist hier "val" angegeben. Der einfachste Fall. Wie bereits beschrieben, können an jeder Stelle, wo man einen festen Wert schreiben könnte, auch ein Schlüsselwort verwenden, um einen Teil des Encoder-Wertes einzusetzen oder sogar Sonderfunktionen einzubauen. Dabei kann es auch sein, dass um das Schlüsselwort herum noch andere Werte gesetzt werden müssen, die das Schlüsselwort steuern. Nachfolgend eine Liste der wichtigsten Schlüsselwörter und ihren Funktionen, die Komplettübersicht gibts in der detailierten Beschreibung der B-Control-Tokenreferenz

val

setzt den kompletten 7bit-Wert des Encoders ein. Dies reicht nur für einen Wertebereich von 0-127, ist also nur dann zu verwenden, wenn der Encoder nicht größer ist, und natürlich, wenn dieses Format der Zahl in der Nachricht so vorgesehen ist.

val0

setzt Bit 0 des Wertes ein. Damit kann an dieser Stelle nur 0 oder 1 vorkommen. Wird dann benutzt, wenn ein 8bit-Wert (0-255) so aufgeteilt wird, daß erst dir Bits 7-1 und dann das Bit 0 kommen, oder umgekehrt.

val1.7

Für 8bit-Werte das Gegenstück zu val0, es setit Bits 7-1 ein.

val0.6

im Prinzip das gleiche wie "val", es setzt bits 6-0 vom Wert ein. Die Schreibweise sollte bei 14bit-Controllern verwendet werden, um zu verdeutlichen, welche Bits hier geschickt werden, da es ja insgesamt mehr als 7 Bits sind.

val7.13

Das Gegenstück zu val0.6 bei 14bit-Controllern, es setzt die Bits 13-7 ein.

val0.3

Einige Geräte tun sich leichter, nicht viel an den Bits herumschieben zu müssen, wodurch die Werte in sogenannten "Nibbles" übertragen werden, die 4 Bits breit sind. Dieses Schlüsselwort setzt hierbei das unterste Nibble ein, Bits 3-0.

val4.7

Analog zu val0.3 werden hiermit Bits 7-4 eingesetzt.

val8.11

Das dritte Nibble, Bits 11-8 werden eingesetzt

val12.13

Und das letzte Nibble, welches, da wir maximal 14 bit im BC verwenden können, nur noch aus 2 Bits besteht, Nummer 13 und 12. Diese werden hiermit eingesetzt.

Welche Teile von Werten nun eingesetzt werden müssen, muss man sich selber aus der Anleitung heraus ermitteln. Um alles noch ein wenig zu verdeutlichen, kommt jetzt noch ein Beispiel, was auch verdeutlichen soll, wie man sich seine tx-Daten zusammenrechnet.

Gehen wir von einem 14bit-Controller aus, der von 0-16383 Werte auswerfen kann. Und gehen wir davon aus, dass der Wert 0x1234 (4660) übertragen werden soll. Im Folgenden werden die Varianten dargestellt, die es gibt, um diese Aufgabe zu bewältigen. Dabei werden nur die tx-Parameter zusammengestellt, der minmax-Parameter wird mit "0 16383" vorausgesetzt.

Halbierung des Wertes

Unsere 14 Bits werden in 2 Teile zu je 7 Bits zerlegt. Wandeln wir also unseren Wert erstmal in Binär um

4660 = 1234h = 0001001000110100b

Dies ist eine 16bit-Binarzahl, wie haben nur 14bit, also lassen wie die ersten beiden führenden Nullen einfach weg. Zerlegen wir den Rest nun in 2 Teile zu 7 Bits:

Bits 13-7 = 0100100b = 24h
Bits  6-0 = 0110100b = 34h

Wir wissen also, was herauskommen muss. Setzen wir dies nun in einen tx-Parameter ein:

.tx $f0 $00 $20 $7d $01 $01 $17 val7.13 val0.6 $f7

Diese Message kann man getrost seinem BC zufügen und durchs Netz schicken, da hier eine nicht existierende Hersteller-ID verwendet wurde, sollte kein Gerät auf diese Message reagieren. Wenn man nun den Encoder auf den Wert 4660 einstellt, sollte die korrekte Message kommen:

$f0 $00 $20 $7d $01 $01 $17 $24 $34 $f7

Wir sehen unsere beiden eingesetzten Werte.

Übertragung in Nibbles

Nibbles sind schöne Dinger, wenn man mit Hexadezimalzahlen arbeitet, weil ein Nibble ganz genau eine Stelle einer Hexadezimalzahl ist. Daher lässt sich auch inser Wert nun sehr angenehm in diese Nibbles spalten:

4660 = 1234h = 0001001000110100b

Das Selbe wie oben, nur der Einfachheit halber lassen wir jetzt die beiden unnötigen 0-bits links mal dran, weil wir so 4 schöne 4er-Gruppen bilden können:

Bits 15-12 = 0001b = 1h
Bits  11-8 = 0010b = 2h
Bits   7-4 = 0011b = 3h
Bits   3-0 = 0100b = 4h

Wir sehen, dass jedes Nibble eine Stelle unserer hexadezimalen Zahl darstellt. Bits 14 und 15 werden nicht verwendet, weil wir nur 14 Bits (0-13) haben. Der BC wird auch niemals 1-Bits an diesen Stellen generieren, weil der Wertebereich ja nur bis 16383 geht, was binär genau 14 1-bits wären. Bauen wir uns wieder einen tx-Parameter:

.tx $f0 $00 $20 $7d $01 $01 $17 val12.13 val8.11 val4.7 val0.3 $f7

Schaut man sich die gesendete Message bei dem Wert 4660 nun an, kommt heraus:

$f0 $00 $20 $7d $01 $01 $17 $01 $02 $03 $04 $f7

Und schon haben wir, was wir wollten.

8bit-Werte

Sehr unüblich, aber nicht unmöglich. Die 8bit-Werte. Niemand schreibt uns vor, daß der BC nur den vollen 7bit- oder 14bit-Bereich verwenden muss. Es kann auch mal ein 8bit-Bereich sein. Den Wertebereich würde man dazu folgendermassen definieren:

.minmax 0 255

Für MIDI haben wir nun 1 Bit zuviel. Um diese Zahl zu verschicken, kann man natürlich schonmal oben die Variante "Halbierung des Wertes" benutzen. Wir übertragen da zwar 14 Bits, aber da wir nur in ganzen Bytes rechnen können, ist das einfach eine Tatsache. Die oberen 6 Bits von "val7.13" werden allerdings immer 0 sein, weil der Wert 255 nicht übersteigt. Damit können wir auch die Variante mit den Nibbles benutzen. Allerdings werden hier nur val4.7 und val0.3 verwendet, die anderen Bits sind generell 0.

Als letzte Variante käme noch eine Trennung hinzu, die wie die Variante "Halbierung des Wertes" arbeitet, also für unseren 8bit-Wert eine Aufteilung in 1:7 macht, nur in diesem Falle anders herum, es wird 7:1 aufgeteilt. Wir haben 8 Bits, schicken in einer Portion 7 davon, indem wir val1.7 angeben, und die andere Portion, das unterste Bit, kommt mit val0. Diese Codierung ist aber eher selten verwendet.

Weitere nützliche Kommandos

Um den Rahmen dieses einen Dokuments nicht zu sprengen, kommen wir nun langsam zum Schluss, obwohl es sicherlich noch sehr viel zu sagen gibt. Die wichtigsten Dinge sind drin, und in der B-Control-Tokenreferenz stehen alle möglichen Tokens nochmal kurz und knackig beschrieben. Dieses Dokument soll nur eine grundsätzliche Anleitung geben, wie man vorgehen kann, und welche Möglichkeiten man zum Experimentieren hat.

Daher abschliessend noch ein paar Worte und ein paar Kommandos, die einem das Leben leichter machen können.

Wie beschrieben sind bisher keine Änderungen an den Presets im BC vorgenommen worden. Dies ist jedoch möglich, wer dazu mehr wissen möchte, kann ja statt einem single dump mal einen all dump aus dem BC lassen und sich den genauer anschauen. Um es kurz zusammen zu fassen:

• Ein Konfigurations-Dump ist nicht zwangsläufig einem Preset zugeordnet. Alle Konfigurationen für Encoder, Buttons und Fader arbeiten grundsätzlich im Edit Buffer. So ist es also möglich, wirklich nur ein Element zu konfigurieren, was gerade beim Experimentieren sinnvoll sein kann, weil die kleinen Konfigurationen auf diese Art sehr schnell zu übertragen sind. Ein Textfile könnte dann also so aussehen:

$rev R1
$encoder 1
  .easypar CC 1 16 0 127 absolute
  .showvalue on
  .mode 1dot
  .resolution 96 96 96 96
  .default 64
$end

• Andererseits kann ein Konfigurations-Dump einen oder auch mehrere Presets beinhalten. Das vorgehen dabei sieht dann so aus, dass erst der Edit Buffer gelöscht wird, dann alle Elemente definiert werden, und das Preset gespeichert wird. Danach kann auf genau die gleiche Art das nächste Preset behandelt werden. So sieht ein all dump aus.

• Man kann auch differentielle Änderungen vornehmen, indem man den Edit Buffer nicht initialisiert, sondern ein Preset geladen wird, ein oder mehrere Elemente umdefiniert werden, und das Preset wieder gespeichert wird.

• Wie man einem all dump entnehmen kann, gibt es auch noch globale Konfigurationskommandos, die z.B. den USB/MIDI-Modus einstellen und noch ein paar andere nützliche Parameter. Auch diese kann man unabhängig von Presets verwenden.

Die Wichtigsten Kommandos, um mit den Presets zu arbeiten, sind die folgenden:

$preset

Keine Argumente - leitet die Preset-Konfiguration im Allgemeinen ein. Zu dem Kommando gehören einige Parameter, die vorerst lieber erstmal aus einem bestehenden Dump übernommen werden sollte. Da man sich bei falscher Nutzung der Tokens komplett aus seinem BC aussperren kann, da man die kompletten Funktionstasten zur Steuerung der BC-Funktionen wie Presetwechsel sperren kann. Dieses Kommando wird üblicherweise mit dem Argument .init verwendet, um die Controller-Konfiguration zu löschen.

$recall <n>

Lädt ein Preset in den Edit Buffer, <n> gibt dabei das Preset an. Dieses Kommando benötigt keine Parameter

$store <n>

Speichert ein Preset aus dem Edit Buffer auf den Preset-Platz <n>. Auch dieses Kommando benötigt keine Parameter.

$global

Ist in einem all dump zu finden, hiermit werden globale Parameter eingestellt. Kaum etwas, was man nicht am BCR selber auch einstellen könnte, nur die letzten beiden Parameter der Firmware 1.10, die am Gerät nicht beschriftet sind, sind hier erkennbar. .txinterval ist z.B. ein interessanter Parameter, der die maximale Sendegeschwindigkeit setzt, um nicht bei zu vielem Kurpeln den kompletten MIDI-Bus dichtzumachen. Kann am Gerät mit Firmware 1.10 auch nach EDIT+STORE mit Encoder 7 eingestellt werden.

$fader <n>

Oben gar nicht erwähnt, dient dies der Definition eines Faders. Da Fader keine LED-Ringe aber einen Motor haben, sind hier natürlich wieder die möglichen Parameter ein wenig anders. Details in B-Control-Tokenreferenz.

$button <n>

Auch analog zu $encoder, nur für die Buttons, zu denen auch die Tasterfunktion der ersten 8 Encoder gehört, entsprechend sind die ersten 32 Buttons genau diese Push-Encoder in der Tasterfunktion, 8 Encoder mal 4 Gruppen. Buttons haben, wie auch Fader, wieder andere Charakteristika, wodurch einige Parameter nicht zur Verfügung stehen.

So, nach so viel Text nun einfach mal viel Erfolg beim Experimentieren!

Sysex INFO

• B-Control - Controller Series - Bcr2000 and find Info about SysEx control synths here: B-Control-Konfiguration, B-Control-Tokenreferenz & BC-Convert