B-Control-Tokenreferenz

Hier werden die in Konfigurationsfiles für BC-Convert verwendbaren Tokens, also Schlüsselworter, genauer beschrieben. Sie dienen der Konfiguration der B-Control-Serie von Behringer. Auf das Format des Textfiles wird hier nicht weiter eingegangen, hierzu bitte BC-Convert und B-Control-Konfiguration studieren.

Alle Angabe beziehen sich auf die aktuelle Firmware, Version 1.10. In Älteren Firmware-Versionen sind einige Features möglicherweise nicht vorhanden.

Anfang und Ende der Konfiguration

$rev <arg>

Dieses Token leitet die Konfiguration ein und muss daher als erstes in einer Konfigurationsdatei vorkommen. <arg> kann dabei R1 oder F1 sein und bestimmt, ob die Konfiguration für einen BCR2000 oder einen BCF2000 ist.

$end

Beendet die Konfiguration und sollte damit als letztes Token in der Konfigurationsdatei auftauchen.

Global Mode Konfigurationsparameter

$global

Startet die Konfiguration des Global Mode, also der geräteweiten Paramter. Diesem Kommando folgen eines oder mehrere Parameter-Tokens:

.midimode <arg>

Mögliche Werte: U-1, U-2, U-3, U-4, S-1, S-2, S-3, S-4

Stellt den USB/MIDI-Modus ein, zur Beschreibung der Modi im Detail sei auf die Bedienungsanleitung verwiesen.

.startup <arg>

Mögliche Werte: last, 1-32

Konfiguriert, welches Preset beim Einschalten geladen wird. Bei last wird das Preset geladen, welches beim Ausschalten geladen war, mit 1 bis 32 lässt sich eine zu ladende Preset-Nummer angeben.

.footsw <arg>

Mögliche Werte: auto, norm, inv

Stellt die Polarität der Fußschalter ein, bei auto versucht das Gerät, diese selber zu ermitteln, norm ist für Schliesser und inv ist für Öffner.

.rxch <arg>

Mögliche Werte: off, 1-16

Stellt den MIDI Empfangskanal des BC ein. Auf diesem Kanal können Program Changes empfangen werden, um die Presets umzuschalten.

.deviceid <arg>

Mögliche Werte: 1-16

Stellt die Geräte-ID ein, unter der der BC seine SysEx-Dumps verschickt und unter der er sie empfängt, wenn die Dumps nicht auf ID 127 (an alle) hereinkommen.

.txinterval <arg>

Mögliche Werte: 2, 5, 10, 20, 50, 100

Setzt die minimale Wartezeit zwischen Übertragungen in Milisekunden. Gerade, wenn man mehrere Encoder benutzt, oder sie als NRPNs/RPNs oder gar SysEx auslegt, kann es vorkommen, dass allzu aktives Kurbeln derart viele Daten produziert, dass der MIDI-Bus zu stark belastet wird und z.B. Notenevents nicht mehr durch kommen. Um dieses Problem zu reduzieren, lässt sich mit diesem Kommando das Intervall einstellen, in dem die Controller Updates schicken. Um den richtigen Kompromiss zwischen hakeliger Antwort auf dem Controller und zumatschen des MIDI-Bus zu finden, ist etwas Experimentieren notwendig. Dieser Parameter existiert vermutlich erst seit Firmware 1.10 und ist in der Bedienungsanleitung Version 1.1 beschrieben, er ist im Global Mode auf dem Encoder 8 erreichbar.

.deadtime <arg>

Mögliche Werte: 0-1000 in 10er-Schritten

Stellt die Zeit in ms ein, die ein Controller nach Betätigung nicht auf MIDI-Input hört, um Wertesprünge durch verzögerte Feedbacks zu vermeiden.

Preset-Verwaltungskommandos

$recall <arg>

Lädt das durch <arg> (Wertebereich 1-32) angegebene Preset in den Edit Buffer.

$store <arg>

Speichert den Edit Buffer in den durch <arg> (Wertebereich 1-32) angegebenen Preset-Speicher.

$preset

Leitet die Preset-Konfiguration ein. Die folgenden Parameter stellen einige Grunddaten zu dem Preset ein, nach dem $preset-Kommando folgen üblicherweise die Kommandos zur Konfiguration der Eingabeelemente, danach ist es optional möglich, mit $store das Preset gleich zu speichern. Es sollte auch möglich sein, ein Preset auf diese Art z.B. Umzubenennen, indem es mit $recall geladen wird, mit $preset der Name geändert wird und es mit $store wieder gespeichert wird.

.name <arg>

Mögliche Werte: ein exakt 24 Zeichen langer String, der zwischen einfachen Anführungszeichen steht.

Setzt den Preset-Namen, der z.B. in einem Editor angezeigt werden kann, aber auch nützlich ist, wenn man seine eigenen Presets von SysEx nach Text konvertieren muss, und dann am Namen erkennen kann, was für ein Preset das ist. Andere Längen als genau 24 Zeichen sind nicht ausprobiert. Der Name wird üblicherweise mit Leerzeichen aufgefüllt, um die 24 Zeichen zu erreichen. Ein Beispielparameter wäre

.name 'Mein erstes Preset     '

.snapshot <arg>

Mögliche Werte: vorerst nur off

Funktion noch nicht genau geklärt.

.request <arg>

Mögliche Werte: vorerst nur off

Laut Bedienungsanleitung gibt es die Möglichkeit, ein Kommando zu definieren, mit dem man sein gesteuertes Gerät dazu bewegen kann, all seine aktuellen Controllereinstellungen zu senden. Dazu gibt es auch eine Tastenkombination am BC. Das Kommanso lässt sich laut Bedienungsanleitung per Editor definieren, der wird nur scheinbar nicht mehr weiter entwickelt. Bisher ist das Format dieses Parameters noch nicht geklärt, aber vermutlich dient er genau dieser Konfiguration.

.egroups <arg>

Mögliche Werte: 1-4

Stellt die Anzahl zur Verfügung stehender Encoder Groups ein. Dieser Parameter mag auf den ersten Blick sinnlos wirken, aber es kann Sinn machen, sich selber Features wegzunehmen. Wenn man z.B. nur die erste Encoder Group belegt hat, und live mit dem BC arbeitet, ist es eher ungünstig, wenn man nun versehentlich mitten im Gig auf die Gruppenumschalttasten kommt und sich damit kurzerhand die oberen 8 Encoder wegnimmt. Daher kann in solchen Fällen die Anzahl Gruppen auf 1, 2 oder 3 eingeschränkt werden, oder mit 4 voll zur Verfügung stehen. Außerdem lassen sich, wenn auf eine Encoder Group gedrosselt wird, alle 4 Tasten für die Gruppenumschaltung anderweitig verwenden.

.fkeys <arg>

Mögliche Werte: off, on

Für den Nervenkitzel zwischendurch - mit diesem Kommando kann man die Funktionstasten, also STORE, LEARN, EDIT und EXIT einschalten und ausschalten. Ist auch nützlich, um versehentliche Bedienung zu vermeiden, außerdem können die abgeschalteten Funktionstasten-Buttons auch anderweitig belegt werden.

.lock <arg>

Mögliche Werte: off, on

Geht noch einen Schritt weiter als .fkeys und schaltet zusätzlich die Preset-Umschalttasten ab. Mit diesem Parameter sperrt man sich also erstmal komplett aus seinem BC aus. Wurde das Preset aber nicht gespeichert, ist kein Grund zur Sorge angesagt - notfalls hilft aus/einschalten, und alles ist wieder beim Alten. Wenn das Preset gespeichert wurde, und in den globalen Parametern Startup auf last oder diesem Preset steht, kommt man an sein Gerät nur noch per SysEx ran.

.init

Keine Argumente

Initialisiert den Edit Buffer, löscht also sämtliche Daten über Eingabeelemente. Dieser Parameter wird mit angegeben, wenn ein komplettes Preset via SysEx definiert werden soll, damit sauber auf einem leeren Edit Buffer aufgesetzt werden kann.

Konfiguration der Eingabeelemente

Da einige Parameter allen Eingabeelementen gemeinsam sind, werden diese weiter unten beschrieben. Zu den Eingabeelementen selber werden nur die speziellen Parameter der entsprechenden Typen beschrieben.

$encoder <arg>

Konfiguriert die Drehencoder. Bei den Push-Encodern bezieht sich dies nur auf den Encoder, nicht auf die Druckfunktion. Die Encoder-Nummer wird dabei durch <arg> angegeben und kann im Bereich 1-32 bei einem BCF und 1-56 bei einem BCR liegen. Dabei ist die Aufteilung wie folgt:

  1-8 = oberste Reihe, Gruppe 1
 9-16 = oberste Reihe, Gruppe 2
17-24 = oberste Reihe, Gruppe 3
25-32 = oberste Reihe, Gruppe 4
33-40 = zweite Reihe (nur BCR)
41-48 = dritte Reihe (nur BCR)
49-56 = unterste Reihe (nur BCR)

Parameter, die nur für $encoder gelten:

.resolution <arg1> <arg2> <arg3> <arg4>

Mögliche Werte: positive Zahlen, Bereich noch nicht ermittelt

Dient der Konfiguration der Auflösung der Encoder, die Zahlen bedeuten Schritte pro Umdrehung, die 4 Stufen dienen der Aufteilung in 4 unterschiedliche Drehgeschwindigkeiten. Dreht man sehr langsam, wird <arg1> verwendet, je schneller man dreht, desto näher kommt man an <arg4> heran. Die Werte sollten glatte Brüche oder Vielfache von 96 sein, da dies die physikalische Encoder-Auflösung ist. Also sind z.B. 24, 48, 96, 192 usr. sinnvolle Werte.

.mode <arg>

Mögliche Werte: off, 1dot, 1dot/off, 12dot, 12dot/off, bar, bar/off, spread, pan, qual, cut, damp

Legt den Anzeigemodus für den LED-Ring des Encoders fest. Nur die 8 Push-Encoder in der obersten Reihe unterstützen alle Anzeigemodi, die 24 Encoder im unteren Teil können nur off, 1dot und 1dot/off verwenden. Dieser .mode-Parameter sollte nicht mit dem .mode-Parameter von $button verwechselt werden, sie haben völlig unterschiedliche Funktionen.

$fader <arg> (unvollständig)

Mangels Gerät zur Analyse nicht erforscht.

Parameter, die nur für $fader gelten:

.override

Funktion unbekannt

.motor

Funktion unbekannt

.keyoverride

Funktion unbekannt

$button <arg>

Konfiguriert den Button, der durch <arg> angegeben wird. Erstaunlich viele Elemente des BC können dabei als Buttons verwendet werden, hier eine Liste zur Zuordnung:

  1-8 = Drehencoder Push-Funktion oberste Reihe, Gruppe 1
 9-16 = Drehencoder Push-Funktion oberste Reihe, Gruppe 2
17-24 = Drehencoder Push-Funktion oberste Reihe, Gruppe 3
25-32 = Drehencoder Push-Funktion oberste Reihe, Gruppe 4
33-40 = Block unter Drehencodern, obere Reihe
41-48 = Block unter Drehencodern, untere Reihe
49-52 = Block rechts unten
53-56 = STORE, LEARN, EDIT, EXIT
57-60 = Gruppenumschalter der Encoder-Gruppen
   61 = Fußschalter 1
   62 = Fußschalter 2
   63 = Preset <
   64 = Preset >

Parameter, die nur für $button gelten:

.mode <arg>

Mögliche Werte: down, updown, toggle

Nicht zu verwechseln mit .mode von $encoder. Bei $button bewirkt dieser Parameter die Einstellung des Verhaltens des Buttons. Bei down wird nur beim Drücken die konfigurierte Message mit dem Maximalwert geschickt, bei updown sowohl beim Drücken (Maximalwert) als auch beim Loslassen (Minimalwert), und toggle aktiviert die Umschaltfunktion, also wird mit jedem Druck auf den Taster zwischen dem Minimalwert (off) und dem Maximalwert (on) umgeschaltet und die konfigurierte Message geschickt.

Parameter für alle Eingabeelemente

Die folgenden Parameter gelten für alle Eingabeelemente, teilweise gibt es Abweichungen in der Syntax für die verschiedenen Elemente, die dann bei den entsprechenden Parametern erläutert sind.

.easypar <args>

Mögliche Werte: Je nach Konfiguration, siehe weiter unten

Dient dem Senden einer einfachen Message wie Control Change oder Program Change. Da je nach Messagetyp die Argumente unterschiedlich sind, wird diesem Parameter ein eigener Abschnitt gewidmet. Die Verwendung von easypar schliesst die Verwendung von tx/minmax aus.

.tx <args>

Mögliche Werte: Eine MIDI-Message, bestehend aus mehreren Bytes oder Schlüsselwörtern

Dient dem Senden einer vollständig frei konfigurierbaren Message, wie z.B. SysEx, und kann dabei den Controllerwert auf die verschiedensten Arten in die Message einfügen, auch sind Sonderfunktionen wie Prüfsummengenerierung möglich, daher wird diesem Parameter ein eigener Abschnitt gewidmet. Die Verwendung von tx/minmax schliesst die Verwendung von easypar aus.

.minmax <arg1> <arg2>

Mögliche Werte: beide zwischen 0 und 16383

Konfiguriert für den tx-Parameter den Wertebereich. <arg1> gibt den Minimalwert an, <arg2> den Maximalwert. Nicht verwendbar bei easypar. Wenn <arg1> größer als <arg2> ist, arbeitet der Controller rückwärts, bei Rechtsdrehung werden die Werte also kleiner. Entsprechend kann man bei Buttons hiermit den on-Wert und den off-Wert vertauschen.

.showvalue <arg>

Mögliche Werte: off, on

Steuert die Anzeige im 4-stelligen LED-Display. Bei on werden die Werte bei Änderung im Display angezeigt, bei off werden sie es nicht. Die Defaulteinstellung, wenn dieser Parameter weggelassen wird, ist off, es werden keine Werte angezeigt.

.default <arg>

Mögliche Werte: alle im Bereich zwischen Minimum und Maximum

Legt den Default-Wert fest, der nach Konfiguration des Controllers eingestellt ist, und nach Speichern des Presets auch mit dem Controller zusammen als aktueller Wert gespeichert wird.

Argumente des easypar-Parameters

easypar dient der Übermittlung von Standard-MIDI-Nachrichten. Die Syntax besteht dabei aus dem Nachrichtentyp und den zugehörigen Parametern. Nicht alle Nachrichtentypen können allen Controllern zugewiesen werden, die Sonderfälle sind bei den Nachrichtentypen genauer erläutert.

Argumente des tx-Parameters

tx dient der Konstruktion beliebiger MIDI-Nachrichten wie z.B. SysEx-Nachrichten. Die Syntax besteht dabei aus einer Liste an Bytes, die übertragen werden soll, wobei statt einem Byte auch ein Schlüsselwort verwendet werden kann, um Sonderfunktionen zu steuern. Das Schlüselwort benötigt teilweise selber wieder Parameter, die vor oder nach dem Schlüsselwort mit angegeben werden müssen.

Daten können dabei in hexadezimaler oder dezimaler Form angegeben werden, wie das folgende Beispiel zeigt:

.tx $b0 16 val
.minmax 0 127

Dieser Parameter sorgt dafür, dass der Wert als MIDI-Controller 16 verschickt wird. $b0 ist dabei der MIDI-Status für "Controller Change, Channel 1", angegeben in hexadezimal, 16 ist die in dezimal angegebene Controller-Nummer und val ist das Schlüsselwort für den Controllerwert. Dieser Parameter ist so nur für 7bit-Controller einsetzbar. Bei 14bit muss man etwas anders vorgehen:

.tx $e0 val0.6 val7.13
.minmax 0 16383

Dieser Parameter stellt ein 14bit Pitchwheel dar. Das erste Byte ist das MIDI-Statusbyte für "Pitch Wheel, Channel 1", angegeben in hexadezimal, danach kommen Bits 6-0 den Controllerwertes, gefolgt von Bits 13-7 des Controllerwertes. minmax stellt dabei den Wertebereich von 0 bis 16383 ein, also ein 14 bit breiter Wert. Ein Pitchwheel hat offiziell den Wertebereich -8192 bis 8192, leider lässt sich ein solcher Wertebereich beim BC aber nicht einstellen, daher ist hier die "Nullstellung" des Pitchwheels in dieser Konfiguration der Controllerwert 8192 beim BC.

Es ist auch möglich, mehrere Messages gleichzeitig mit diesem Parameter zu senden, folgendes Beispiel ist im Prinzip ein erweiterter Program Change für einen Oberheim Matrix-1000:

.tx $f0 $10 $06 $0a val7.13 $f7 $c0 val0.6
.minmax 0 1251

Da die Werte nur an Bitgrenzen zerteilbar sind, ist dies keine sonderlich schöne Lösung, aber da der Matrix-1000 eh zu langsam ist, die Daten korrekt zu verarbeiten, soll dies nur ein theoretisches Beispiel darstellen. Die erste Message ist der Bank Switch, die zweite Message ein Program Change auf MIDI-Kanal 1. Für den Bank Switch werden die oberen 7 Bits des Wertebereichs verwendet, für den Program Change die unteren 7 Bits. Da der Matrix Program Changes aber nur zwischen 0 und 99 will, ist der Wertebereich 100-127 wirkungslos, aber die nächste Bank wird erst bei 128 übertragen, wo Bits 13-7 den Wert "1" darstellen und Bits 6-0 wieder "0". Für Geräte, die fähig sind, die SysEx-Message mit dem sofort darauf folgenden Program Change schnell genug zu verarbeiten, ist dies ein nütlicher Parameter, vor allem, wenn die Program-Nummer wirklich von 0-127 geht. Der Wertebereich kann hier einfach berechnet werden - wenn die Bank in Bits 13-7 untergebracht sein soll, so ist der Maximalwert die Anzahl Banks * 128 - 1. Bei 4 Banks zu 128 Programmen wäre der Wertebereich für so ein Statement also 0 bis 4 * 128 - 1, also 0 bis 511. Die 1251 im obigen Beispiel passen da nicht dazu, weil hier wenigstens die letzte Bank nur bis 99 geht, also 9 Banks * 128 + 99 für die letzte Bank.

Die maximale Länge der übertragenen Daten scheint auf 123 Bytes begrenzt zu sein, es wird in der Praxis kaum vorkommen, dass man diese Größe der Message wirklich erreicht bzw. auf einen Encoder legen möchte, da die Übertragung der Daten doch eine gewisse Zeit in Anspruch nimmt und so lange der MIDI-Bus dicht ist. Theoretisch wäre es aber möglich, bei dem einen oder anderen nicht allzu komplexen Gerät einen kompletten Patch als SysEx auf Knopfdruck am BC ans Gerät zu schicken.

Folgende Schlüsselwörter können innerhalb der Nachrichtendefinition verwendet werden:

$??

Ein Datenbyte in hexadezimaler Schreibweise (ein ? stellt hierbei eine hexadezimale Ziffer dar), die Stellenzahl darf 1 oder 2 betragen (0 - ff)

???

Ein Datenbyte in dezimaler Schreibweise (ein ? stellt hierbei eine dezimale Ziffer dar), die Stellenzahl darf 1 bis 3 betragen (0 - 255).

val

Setzt den 7bit Controllerwert ein. Wenn der Controller-Wertebereich über 7 Bits hinausgeht, werden die unteren 7 Bits des Wertes eingesetzt.

val0

Setzt Bit 0 des Controllerwertes ein.

val1.7

Setzt Bits 7-1 des Controllerwertes ein.

val0.6

Im Prinzip das gleiche wie val, aber der übersichtlichkeit sollte bei Controllern, die einen größeren Wertebereich als 7 Bits haben, dieses Schlüsselwort für die unteren 7 Bits verwendet werden.

val7.13

Setzt Bits 13-7 des Controllerwertes ein (obere Hälfte bei 14bit-Controllern).

val0.3

Setzt Bits 3-0 des Controllerwertes ein (unterstes Nibble).

val4.7

Setzt Bits 7-4 des Controllerwertes ein (zweites Nibble von unten).

val8.11

Setzt Bits 11-8 des Controllerwertes ein (drittes Nibble von unten).

val12.13

Setzt Bits 13-12 des Controllerwertes ein (höchstes Nibble).

cks-1 <arg>

Errechnet eine Prüfsumme durch Substraktion der Bytes. <arg> gibt dabei an, ab welchem Byte die Berechnung erfolgen soll. Hierbei gilt das erste Byte der Message als Byte 0. Die Berechnung fängt mit dem Wert 0 an, alle Bytes von dem Angegebenen bis zu dem vor dem cks-1 Schlüsselwort werden nun von diesem Wert substrahiert, das Ergebnis wird auf 7 Bit beschnitten und als Prüfsumme statt dem cks-1 Schlüsselwort eingesetzt. Ein Beispiel:

.tx $f0 $00 $20 $7d $01 val cks-1 4 $f7

Bedeutet, dass ab Byte 4, das ist das $01, bis vor dem cks-1 Schlüsselwort, das ist der eingesetzte Controllerwert, eine Prüfsumme gebildet wird. Schauen wir den resultierenden MIDI-Dump mit einem Controllerwert an:

F0 00 20 7D 01 2C 53 F7

Nach unserer Konfiguration prüfen wir das Ergebnis:

0 - $01 - $2c = $d3 (eventuell zeigt der Rechner hier viele "F"s vor dem Wert an, wir beschränken uns auf die letzten 2 Stellen, also dem 8bit-Ergebnis)

Wenn man diesem $d3 nun noch das oberste Bit klaut, also $80 abzieht, kommt als Ergebnis $53 heraus, also genau das, was der BC auch eingesetzt hat.

cks-2 <arg>

Analog zu cks-2, allerdings wird die Prüfsumme hier durch Addition der Werte gebildet. Mit obigem Beispiel (cks-2 statt cks-1) ergibt sich also folgende Message:

F0 00 20 7D 01 2C 2D F7

Nachgerechnet: $01 + $2c = $2d

Auch hier wird das Ergebnis wieder einfach auf 7 Bit gestutzt, wenn wir statt $01 $70 einsetzen und den Controllerwert $36 annehmen, wäre das Ergebnis $a6, der BC schickt $26 heraus, wie wir es erwarten.

cks-3 <arg>

Wie die oberen beiden Prüfsummenberechnungen, hier werden die Werte allerdings Exklusiv-Oder verknüpft. Die Exklusiv-Oder-Verknüpfung arbeitet mit den einzelnen Bits der Datenwerte. Sind Bits an den gleichen Positionen in den beiden Datenwerten identisch, ist das Ergebnisbit 0, ansonsten 1. Wenn wir das Beispiel mit den beiden Werten $55 und $17 durchrechnen, ergeben sich dabei folgende Bitberechnungen:

$55 = 01010101
$17 = 00010111
--------------
XOR = 01000010 = $42

Und genau diese $42 schickt der BC auch raus. Wäre noch ein drittes Byte an der Berechnung beteiligt, würde dieses in diesem Beispiel mit $42 verknüpft werden, jedes Byte wird also immer mit dem vorigen Ergebnis verknüpft, wobei das "vorige Ergebnis" beim ersten Byte einfach "0" als Startwert ist.

reloffs <arg>

Setzt den Offset für die relative Werteausgabe, die relative Wertegenerierung ist noch näher zu definieren. An der Stelle dieses Schlüsselworted wird der relative Controllerwert als Differenz zu dem angegebenen <arg> herausgegeben. Wird also als <arg> $20 angegeben, so werden bei Verkleinerung des Controllerwertes Werte unter $20 geschickt ($1f, $1e...), bei Vergrößerung des Controllerwertes werden Werte über $20 geschickt ($21, $22...). Wie weit dir Werte von dem definierten Mittelwert (Offset) abweichen, wird durch die Größe der Werteänderung des Controllers bestimmt, die wiederum von der Drehgeschwindigkeit abhängig ist. Das genaue Verhalten ist noch nicht analysiert.

relsign <arg>

Ähnlich reloffs wird hier eine relative Werteausgabe vorgenommen, das angegebene <arg> setzt dabei den Wert, der für das Vorzeichen verwendet werden soll, üblicherweise $40, also das höchste Bit des 7bit-Wertes gesetzt.

rel2s

Der relative Wert als 2er-Komplement. Bei positiven Werteänderungen werden positive Werte ($01, $02...) geschickt, bei negativen Werteänderungen negative Werte nach der normalen Darstellung einer 7bit vorzeichenbehafteten Zahl ($7f, $7e...)

ifp <args>

Der Rest der Zeile bzw. alle Bytes bis zum Auftreten eines ifn-Schlüsselwortes werden nur dann geschickt, wenn die Werteänderung positiv ist, also der neue Wert größer ist als der alte Wert. Ansonsten wird der Teil bis Ende der Zeile bzw. bis zum ifn-Schlüsselwort ignoriert.

ifn <args>

Analog zu ifp, aber für negative Werteänderungen

Aus diesen beiden Funktionen kann man änderungsabhängige Messages generieren, z.B.

.tx $f0 $00 $20 $7d ifp $01 val $f7 ifn $02 val $f7

Diese Message wird wie folgt verschickt:

• $f0 $00 $20 $7d werden immer geschickt
• ist die Werteänderung positiv, also ist der Wert größer geworden, wird nun $01 <wert> $f7 geschickt
• ist die Werteänderung negativ, also ist der Wert kleiner geworden, wird nun $02 <wert> $f7 geschickt

ntimes

Eine Funktion, die wiederum mit den relativen Werten zu tun hat, und insbesondere in Verbindung mit ifp und ifn sehr sonderbare Konstruktionen möglich macht. Die relativen Werte basieren auf der Änderungsgeschwindigkeit der Controllerwerte bzw. der Drehgeschwindigkeit des Controllers. Während die Parameter reloffs, relsign und rel2s hierbei diese Geschwindigkeit in dem Wert abbilden, bildet ntimes die Geschwindigkeit in der Anzahl Messages ab. Alles, was hinter dem ntimes-Schlüsselwort kommt, wird also bei langsamer Drehung wie der Teil vor ntimes bei Werteänderung einmach geschickt. Bei Schneller Drehung wird der Teil, der ntimes folgt, geschwindigkeitsabhängig häufiger geschickt. Der Teil vor ntimes kommt also ein mal, der Teil nach ntimes möglicherweise mehrfach, abhängig von der Drehgeschwindigkeit.

Sysex INFO

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