B-Control-Konfiguration - Versionsgeschichte

Moogulator am 14. Mai 2011 um 22:33 Uhr

2011-05-14T22:33:28Z

← Nächstältere Version		Version vom 14. Mai 2011, 23:33 Uhr
Zeile 424:		Zeile 424:

	[[category:Tricks]]		[[category:Tricks]]



			=Sysex INFO=
			* B-Control - Controller Series - [[Bcr2000]] and find Info about SysEx control synths here: [[B-Control-Konfiguration]], [[B-Control-Tokenreferenz]] & [[BC-Convert]]

Moogulator: /* Internas zur Konfiguration der B-Control-Serie */

2011-04-03T21:13:11Z

Internas zur Konfiguration der B-Control-Serie

← Nächstältere Version		Version vom 3. April 2011, 22:13 Uhr
Zeile 10:		Zeile 10:
	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.		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 ==		== 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.		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.

Moogulator am 17. Mai 2007 um 10:34 Uhr

2007-05-17T10:34:09Z

← Nächstältere Version		Version vom 17. Mai 2007, 11:34 Uhr
Zeile 1:		Zeile 1:
	[[category:MIDI]]		[[category:MIDI]][[category:controller]]
	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.		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.

Moogulator am 30. Januar 2007 um 14:25 Uhr

2007-01-30T14:25:01Z

← Nächstältere Version		Version vom 30. Januar 2007, 15:25 Uhr
Zeile 1:		Zeile 1:
			[[category:MIDI]]
	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.		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.

MIK: /* Weitere nützliche Kommandos */

2007-01-06T20:37:47Z

Weitere nützliche Kommandos

← Nächstältere Version		Version vom 6. Januar 2007, 21:37 Uhr
Zeile 376:		Zeile 376:

	== Weitere nützliche Kommandos ==		== 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!

	[[category:Tricks]]		[[category:Tricks]]

MIK: /* Senden von SysEx-Meldungen oder skurrilen Spezialkonstruktionen */

2007-01-06T20:17:29Z

Senden von SysEx-Meldungen oder skurrilen Spezialkonstruktionen

← Nächstältere Version		Version vom 6. Januar 2007, 21:17 Uhr
Zeile 374:		Zeile 374:

	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.		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 ==

	[[category:Tricks]]		[[category:Tricks]]

MIK: /* Senden von SysEx-Meldungen oder skurrilen Spezialkonstruktionen */

2007-01-06T20:16:13Z

Senden von SysEx-Meldungen oder skurrilen Spezialkonstruktionen

← Nächstältere Version		Version vom 6. Januar 2007, 21:16 Uhr
Zeile 262:		Zeile 262:

	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.		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.

	[[category:Tricks]]		[[category:Tricks]]

MIK am 6. Januar 2007 um 18:22 Uhr

2007-01-06T18:22:09Z

@@ Zeile 214: / Zeile 214: @@
 * bis 2000 - 96 192 384 768
 * ab hier - 96 192 768 2304
 [[category:Tricks]]

MIK am 6. Januar 2007 um 17:55 Uhr

2007-01-06T17:55:39Z

Änderungen zeigen

MIK am 6. Januar 2007 um 16:47 Uhr

2007-01-06T16:47:17Z

@@ Zeile 101: / Zeile 101: @@
 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
 [[category:Tricks]]