Synthesizer Wiki - Benutzerbeiträge [de]

Happy Knobbing Members

2008-04-29T15:31:23Z

MIK: /* Members 2008 */

'''[[Happy Knobbing Modular Meeting]] Members'''
we don't know if there is a next meeting but this time it's at least these members attending:

==Modular Meeting 2008==
[[Image:Butt-Happy.jpg]]

We'll do a next meeting at the same time (Weekend + something that is called Pfingsten (Whitsuntide) over here, since it is free for all working people in germany) next year (2008), so you can register to the forum so we know you when you want to come.. but it's also no problem to just come along - but don't forget something modular.. if it's too hard for transport just end me an email..

Es ist soweit: Pfingsten 2008 wird das nächste Treffen steigen! Thomas wird wieder die Behausung stellen - Gegenüber Hauptstraße 122 neben der Kirche.

es ist nicht sicher, dass wir das Treffen wirklich regelmäßig (also ab 2009) machen, daher bitte nicht drauf verlassen - Es hängt letzlich von allen Beteiligten ab, DASS es stattfindet. An den "Ryhthmus" bitte also nicht gewöhnen! Nur bitte den Modular und den Spaß nicht vergessen.

Machines that will work: Digital, Analogue and Software Modulars with Monitor (TFT, CRT, Plasma.. doesn't matter but you need to be able to see the Patches) - No Modular - no entrance because it is limited space.

Regeln 2008 werden wie 2007 sein: Alles erlaubt vom Computer / Software Modular bis zu analogen oder digitaler Hardware, Software jedoch bitte nur mit Bildschirm, sonst bringts nichts - Außerdem haben wir nur begrenzt Platz, daher auch diesmal diese Regeln. Essen muss nicht mitgenommen werden, es wird gegrillt - Der Preis wird ca 20-30€ betragen (Essen + Raummiete für FR-SO).

===was muss man machen, um mitzumachen?===
*ein Modularsystem mitbringen, dabei ist egal welcher Art: Analog, Digital, Computer, es muss aber bei digitalen Systemen das Patch sichtbar sein (Computer ist dann Pflicht zum mitbringen, sonst kann man nichts sehen) - Ohne Modular oder wenigstens einem netten Modularsequencer bitte auf ein normales Treffen kommen, Raum ist begrenzt.
*Anmeldung im Forum idealerweise und freiwillig hier Listung Name/Gear und evtl Performance und Workshops (wegen Planung)
*Abdrücken von ca. 20-30 Euro für Essen und Raummiete. Essen kann man natürlich auch selbst mitbringen.
*Sonst nichts. Nur nicht vergessen, was man so braucht zum Betrieb und anspielen (Kabel, Mehrfachstecker, Kopfhörer), siehe weiter unten..
*Bitte diese Regeln nicht durchdiskutieren, wir haben das jetzt zum dritten Mal und waren immer froh, dass wir das so gemacht haben, weil es sonst einfach zu voll geworden wäre. Das Forum ist Anlaufstelle, wer uns nicht bekannt ist, sollte sich bitte wenigstens dort einmal kurz melden.
*Login fürs Wiki hier gibts bei Moogulator gegen Emailnennung via PM im [[Forum]], danach kann jeder hier posten und sich eintragen oder umtragen.

===Members 2008===
who will attend:

* [[Pattysplanet]] --> gearliste siehe Moogulator..
* [[Moogulator]] zusammen: [[Symbolic Sound]] Kyma + System 100m + [[Clavia]] G2? / Reaktor? / [[EMS]] Synthi A - wenns den Krraftzwerg von MFBx bis dahin gibt auch den ;)
* Bernie ([[Aliens-Project]]) - back roots: vintage Roland + PPG Modular, EMS-AKS, EMS-VCS3...
* Jan ([[Elektrolabel]]) - - EMS-SYNTHI-E + W.Palm DerKleine + Lots of cabinets, Soundlab Minisynth, Modular Controllers
* [[Anyware]] - inSEQt & ??
* [http://www.fonitronik.de fonik] - surprise (klee?)...
* [http://www.joerg-erren.de Jörg] - Semtex + ein paar Doepfer Module + ???
* TomAbe - [[Semtex]] und [[TMSS]]/[[Theis]]Modular und [[InSEQt]] ohne Fragezeichen! Den bringe ich auch mit.
* herw [http://reaktor.approx.de/phpbb3/index.php Deutsches Reaktor Forum] - modular m1 + modular ts + Doepfer
* [http://www.sdiy.de sonicwarrior] - ? (Auf jeden Fall diesmal mit zwei Schraubenziehern mit Bits!!! ;) )
* Scaff
* Kreismeister
* Sauron the Mad - PAiA
* Feinstrom
* System700
* Tronique [[TMSS]]/[[Theis]]Modular
* Penko (X-SchneidersBüro) falls bis dahin geliefert bringe ich einen Cwejman-S1Mk2 mit (http://sensoraudio.com/8.html)
* Pascal "Pasgasman" from France - [[Clavia]] Nord Modular G2 with Laptop
* Happy - ?
* haesslich (http://www.sequencer.de/synthesizer/viewtopic.php?p=264973#264973)
* rechner7 (http://www.sequencer.de/synthesizer/viewtopic.php?p=264973#264973)
* Oliver (kein Forumsmember aber gaaaanz lieb und uns bekannt, war auch schon bei den früheren Treffen mit interessanten Geräten) - vermutlich EMS
* ACA - Doepfer
* Moondust - Doepfer
* READYdot 3HE Doepfer A-100 mit MFB OSC-1, tribe mx, KP3, modFX

unconfirmed/tba.
* Paul, Andreas, Heinzel @ [[Schneidersbüro]]
* [[Curetronic]] - Matthias
* XeroX mit ein paar Dotcom Modulen und Anyware Instruments Semtex und auch hoffentlich dem Inseqt

more @ Forum: http://www.sequencer.de/synthesizer/viewtopic.php?t=22353&postdays=0&postorder=asc&start=30

===Workshops + Performance 2008===
finden nur am SA statt (vorraussichtlich)
Samstag - Haupttag für Workshops und Performance

Die Zeiten am SAMSTAG von ca. 19:00 bis 23:00 sind für Live Performance vorgesehen.
Das halten wir rel. offen, jedoch soll die Musik nicht zu kurz kommen. Die anderen Tage sind für Aufbau, Abbau, Ankommen, Abfahren gedacht und weiteres Fachsimpeln, denn das geht ja früh ab NAchmittag los und endet offen am Sonntag.
Jamgruppen und Workshops dann nach kurzer Klärung möglich. Workshops auch FR abend.

==Modular Meeting 2007==
[[Image:Butt-Happy.jpg]]

===Members 2007 (as good as I/we know)===

[[Image:Modular_menschenfleisch_lor.jpg]]

* Oliver -(Formant mit sehr hellen LEDs, Synthi A)
* Rechner7 - Doepfer
* Synthdoctor (MS10 mod - moog filter, modularisiert - SQ10)
* HPL (doepfer moduler, p3, cwejman s1, semtex)
* + [[Moogulator]] - [[Roland]] [[100m]], evtl. DIY Sequencer 10 Step, Roland [[SH5]] oder [[SH7]] (kleines Pult, [[Electribe]])
* Elektrolabel - Jan - 4 Cabinets mit Modulen (evtl. ein fünftes), [[Sherman]] FB2, [[ML303]], [[Sidbox]], [[ARP]] [[Axxe]], [[Yamaha]] [[CS5]]
* + ACA - [[Doepfer]] Modular + X - Recording
* Moondust / DIY Doepfer?
* serenadi - LeBernard™ modular
* Haesslich - [[Doepfer]] Modular
* [[Anyware]] / Thomas - Veranstalter - Master of this years meeting.. with [[InSEQt]], [[Semtex]] + [[Cloxbox]]?..
* Sonicwarrior - [[Curetronic]] Modular plus X (evtl. Formant Tastatur, [[ML303]] oder [[InSEQt]])
* + Scaff - [[Dotcom]] Modular + ?
* [[User:Kreismeister]] - [[Doepfer]] Modular
* [http://www.modular.fonik.de FONIK] (Matthias H.)- 2x2 3HE Cabinets DIY Modular, Baby10 Sequencer, Waterproof SoundLab (nur SA)
* [[User:tronique]] - [[TMSS]]/[[Theis]] Modular
* TomAbe - [[Semtex]] und [[TMSS]]/[[Theis]]Modular und [[InSEQt]]???
* Happy - [[Dotcom]] Modular + X
* Penko [[User:Penkollage]] von [[Schneidersbüro]] &
* Paul "Herr Schulz" [[Schneidersbüro]] mit Cwejman-Module, MFB-Module, Livewire, Bananalogue, [[Steckbox]]
http://www.superbooth.com
* Bernie ([[Aliens-Project]]) - PPG 300 Modular + Dotcom Modular (3 big cabinets), Space-Echo, EMS VCS3, Coron DS-7, WEM Copycat, FX, Mixer + Kleinkram...
http://www.aliens-project.de
* herw - MODULAR MINI 2 (Version 2.6 / > 500 Patches) auf G5 + PA und midi, Beamer / evtl. MIDIBOARD (kurzweil) (nur Samstag)
* EL-KA Member HaJo PS3100 (SA only)und von Georg "dem berühmten Erfinder" Mahr den MSQ-51 CV Sequenzer (Sa only?)
* Mathias / Curetronic
* Dirk Matten +
* Frank S. mit Synthanorma Sequencer vom Synthesizerstudio Bonn
* [[pattysplanet]] (clavia nordmodular + macbook, WX gesteuert)

[[Image:Happyknobbing_413.JPG|Ein Teil der Gruppe vom Treffen - Es sind halt nicht alle drauf - Modularmeeting 2007]]

--> einige, die sich angekündigt haben, stehen noch nicht hier.. können sich aber eintragen: login wie immer gegen email und nickname bei moogulator.. more tba.. http://www.synthesizerforum.de/synthesizer/viewtopic.php?t=11811&start=120&postdays=0&postorder=asc&highlight=

about 32 people came and even more modulars compared to 2006 - and: it was far out and in very official holidays, so some family guys could not come.. they will have to dream about it till 2008.. harhar..

==Modular Meeting 2006==
-> about 40 people with many more synths

*Bernie / [[Aliens-Project]] - Alles aus dem Studio (Gastgeber) ua [[M5]], Moog, PPG, Roland [[System700]], Dotcom und andere Modulars
*[[Moogulator]] / Mic - [[Roland]] 100m, DIY Sequencer 10 Step, (kleines Pult)
* HPL [[Semtex]], [[Sequentix]] [[P3]], [[Sherman]] Filterbank
* Smoo/Sägezahn / Olivier, [[Auralesque]] Modular DIY
* Island - [[Synthesizers.com]] Modular + little [[Curetronic]] Box
* Scaff / Meic - [[Synthesizers.com]] Modular, Machinedrum, [[Semtex]]
* Jörg (Erren) - [[Curetronic]] Modular, [[Semtex]]
* Groovepatcher / Sven - großes [[Doepfer]] Modular
* Happy / Christian - [[Curetronic]] + [[Dotcom]] Modular
* the Vision / Robert - [[ARP]] [[Avatar]] modularisiert + [[MS20]]
* Bluesynths / Theo Bloderer - MS20
* Monolith 2063 / Oliver - dotcom Modular, [[ARP]] [[Odyssey]], [[Doepfer]] Module
* Serenadi - Großes DIY Modular "Le Bernard"
* Curetronic / Mattias Schmidt - [[Curetronic]] Modular
* Penko / [[Schneidersbüro]] - [[Cwejman]] [[S1]] und [[Cwejman]] Modular
* Anyware / Thomas - [[Semtex]] und DIY Kits
* elektrolabel / Jan - [[Curetronic]] Modular
* Ralf - [[ARP]][[2600]]
* Oliver - DIY Sequencer 64 Step,[[ARP]][[2600]] [[Doepfer]] Modular [[Orgon]] Systems [[Enigiser]]
* 3x Personen ? - [[Doepfer]] Modular
* ACA - [[Roland]] [[System100]]
* Moondust - [[Doepfer]] Modular / DIY
* ENT / Kai - [[System100]]
* 0=1 / Matthias + Alex - Full MS-Series ([[MS10]],[[MS20]],[[SQ10]],[[MS50]]) some doubles..
* Haesslich - DIY Modular
* Kreismeister / Guido - [[Simplesizer]], [[Doepfer]] Modular
* Interfunk / Electronic Corporation - [[SAM16]] Sequencer, Full [[Korg]] MS-Series ([[MS20]],[[SQ10]],[[MS50]]), [[KRR55]], Semtex?
* Sonicwarrior - [[Semtex]]

- app. 37 - 40 Members, please add your Info here if you do not find your name..

==Modular Meeting Infopage + Pics/Videos==

back to main page..

--> [[Happy Knobbing Modular Meeting]]

Happy Knobbing Members

2008-04-17T18:48:00Z

MIK: /* Members 2008 */

'''[[Happy Knobbing Modular Meeting]] Members'''
we don't know if there is a next meeting but this time it's at least these members attending:

==Modular Meeting 2008==
[[Image:Butt-Happy.jpg]]

We'll do a next meeting at the same time (Weekend + something that is called Pfingsten (Whitsuntide) over here, since it is free for all working people in germany) next year (2008), so you can register to the forum so we know you when you want to come.. but it's also no problem to just come along - but don't forget something modular.. if it's too hard for transport just end me an email..

Es ist soweit: Pfingsten 2008 wird das nächste Treffen steigen! Thomas wird wieder die Behausung stellen - Gegenüber Hauptstraße 122 neben der Kirche.

es ist nicht sicher, dass wir das Treffen wirklich regelmäßig (also ab 2009) machen, daher bitte nicht drauf verlassen - Es hängt letzlich von allen Beteiligten ab, DASS es stattfindet. An den "Ryhthmus" bitte also nicht gewöhnen! Nur bitte den Modular und den Spaß nicht vergessen.

Machines that will work: Digital, Analogue and Software Modulars with Monitor (TFT, CRT, Plasma.. doesn't matter but you need to be able to see the Patches) - No Modular - no entrance because it is limited space.

Regeln 2008 werden wie 2007 sein: Alles erlaubt vom Computer / Software Modular bis zu analogen oder digitaler Hardware, Software jedoch bitte nur mit Bildschirm, sonst bringts nichts - Außerdem haben wir nur begrenzt Platz, daher auch diesmal diese Regeln. Essen muss nicht mitgenommen werden, es wird gegrillt - Der Preis wird ca 20-30€ betragen (Essen + Raummiete für FR-SO).

===was muss man machen, um mitzumachen?===
*ein Modularsystem mitbringen, dabei ist egal welcher Art: Analog, Digital, Computer, es muss aber bei digitalen Systemen das Patch sichtbar sein (Computer ist dann Pflicht zum mitbringen, sonst kann man nichts sehen) - Ohne Modular oder wenigstens nem netten Modularsequencer bitte auf ein normales Treffen kommen, Raum ist begrenzt im Platz daher..
*Anmeldung im Forum idealerweise und freiwillig hier Listung Name/Gear und evtl Performance und Workshops (freiwillig natürlich).
*Abdrücken von ca. 20-30 Euro für Essen und Raummiete
*Sonst nichts.. Nur nicht vergessen, was man so braucht zum betrieb und anspielen, siehe weiter unten..
*Bitte diese Regeln nicht durchdiskutieren, wir haben das jetzt zum dritten Mal und waren immer froh, dass wir das so gemacht haben, weil es sonst einfach zu voll geworden wäre.. Wir überlegen einen Besuchertag zB am SO zu machen, hierzu bitte im Forum diskutieren.
*Login fürs Wiki hier gibts bei Moogulator gegen Emailnennung via PM im [[Forum]]..

===Members 2008===
who will attend:

* [[Pattysplanet]] --> gearliste siehe Moogulator..
* [[Moogulator]] zusammen: [[Symbolic Sound]] Kyma + System 100m + [[Clavia]] G2? / Reaktor? / [[EMS]] Synthi A - wenns den Krraftzwerg von MFBx bis dahin gibt auch den ;)
* Bernie ([[Aliens-Project]]) - back roots: vintage Roland + PPG Modular, EMS-AKS, EMS-VCS3...
* Jan ([[Elektrolabel]]) - - EMS-SYNTHI-E + W.Palm DerKleine + Lots of cabinets, Soundlab Minisynth, Modular Controllers
* [[Anyware]] - inSEQt & ??
* [http://www.fonitronik.de fonik] - surprise (klee?)...
* [http://www.joerg-erren.de Jörg] - Semtex + ein paar Doepfer Module + ???
* TomAbe - [[Semtex]] und [[TMSS]]/[[Theis]]Modular und [[InSEQt]] ohne Fragezeichen! Den bringe ich auch mit.
* Sadnoiss [[TMSS]]/[[Theis]]Modular
* herw [http://reaktor.approx.de/phpbb3/index.php Deutsches Reaktor Forum] - modular m1 + modular ts + Doepfer
* [http://www.sdiy.de sonicwarrior] - ? (Auf jeden Fall diesmal mit zwei Schraubenziehern mit Bits!!! ;) )
* Scaff
* Kreismeister
* Sauron the Mad - PAiA
* Feinstrom
* System700
* Tronique [[TMSS]]/[[Theis]]Modular
* Penko
* MiK (mit [http://http://www.youtube.com/watch?v=Itx5pnHSeAA Eigenbau-Synth] und Formant, nebst Zubehör)
* Pascal "Pasgasman" from France - [[Clavia]] Nord Modular G2 with Laptop
* Happy - ?
* haesslich (http://www.sequencer.de/synthesizer/viewtopic.php?p=264973#264973)
* rechner7 (http://www.sequencer.de/synthesizer/viewtopic.php?p=264973#264973)

unconfirmed/tba.
* Paul, Andreas, Heinzel @ [[Schneidersbüro]]
* [[Curetronic]] - Matthias
* XeroX mit ein paar Dotcom Modulen und Anyware Instruments Semtex und auch hoffentlich dem Inseqt
* tba.

more @ Forum: http://www.sequencer.de/synthesizer/viewtopic.php?t=22353&postdays=0&postorder=asc&start=30

===Workshops + Performance 2008===
finden nur am SA statt (vorraussichtlich)
Samstag - Haupttag für Workshops und Performance

*15:00 [[Moogulator]] vermtl. [[Kyma]] oder [[Roland]] [[System100m]]
*16:00 5-10 Minuten Geräusch und Vorstellung aller, die Lust haben nach Anmeldung hier, bzw Meldung vor Ort.
*19:00 Einzeljams einzelner Gruppen
*20:00 Moogulator, kleine Performance (gern auch mit anderen, bitte melden bis Jan 2008 - Jamgruppe 1, via Forum abklären..)
* ??
* 23:00 Ende Performance, es geht "normal" weiter oder nach gemeinsamem Entschluss..

Die Zeiten am SAMSTAG von ca. 19:00 bis 23:00 sind für Live Performance vorgesehen.
Das halten wir rel. offen, jedoch soll die Musik nicht zu kurz kommen. Die anderen Tage sind für Aufbau, Abbau, Ankommen, Abfahren gedacht und weiteres Fachsimpeln, denn das geht ja früh ab NAchmittag los und endet offen am Sonntag.

===Jamgruppen 1-5 Leute und grobe Richtung===
*Gruppe 1 - Moogulator + ?? - Frickelelektronik und Neumodisches Getute™ (TD-freie Zone)
*Gruppe 2 - ?? - (??)
*Gruppe 3 - ?? - (??)
*tba

==Modular Meeting 2007==
[[Image:Butt-Happy.jpg]]

===Members 2007 (as good as I/we know)===

[[Image:Modular_menschenfleisch_lor.jpg]]

* Oliver -(Formant mit sehr hellen LEDs, Synthi A)
* Rechner7 - Doepfer
* Synthdoctor (MS10 mod - moog filter, modularisiert - SQ10)
* HPL (doepfer moduler, p3, cwejman s1, semtex)
* + [[Moogulator]] - [[Roland]] [[100m]], evtl. DIY Sequencer 10 Step, Roland [[SH5]] oder [[SH7]] (kleines Pult, [[Electribe]])
* Elektrolabel - Jan - 4 Cabinets mit Modulen (evtl. ein fünftes), [[Sherman]] FB2, [[ML303]], [[Sidbox]], [[ARP]] [[Axxe]], [[Yamaha]] [[CS5]]
* + ACA - [[Doepfer]] Modular + X - Recording
* Moondust / DIY Doepfer?
* serenadi - LeBernard™ modular
* Haesslich - [[Doepfer]] Modular
* [[Anyware]] / Thomas - Veranstalter - Master of this years meeting.. with [[InSEQt]], [[Semtex]] + [[Cloxbox]]?..
* Sonicwarrior - [[Curetronic]] Modular plus X (evtl. Formant Tastatur, [[ML303]] oder [[InSEQt]])
* + Scaff - [[Dotcom]] Modular + ?
* [[User:Kreismeister]] - [[Doepfer]] Modular
* [http://www.modular.fonik.de FONIK] (Matthias H.)- 2x2 3HE Cabinets DIY Modular, Baby10 Sequencer, Waterproof SoundLab (nur SA)
* [[User:tronique]] - [[TMSS]]/[[Theis]] Modular
* TomAbe - [[Semtex]] und [[TMSS]]/[[Theis]]Modular und [[InSEQt]]???
* Happy - [[Dotcom]] Modular + X
* Penko [[User:Penkollage]] von [[Schneidersbüro]] &
* Paul "Herr Schulz" [[Schneidersbüro]] mit Cwejman-Module, MFB-Module, Livewire, Bananalogue, [[Steckbox]]
http://www.superbooth.com
* Bernie ([[Aliens-Project]]) - PPG 300 Modular + Dotcom Modular (3 big cabinets), Space-Echo, EMS VCS3, Coron DS-7, WEM Copycat, FX, Mixer + Kleinkram...
http://www.aliens-project.de
* herw - MODULAR MINI 2 (Version 2.6 / > 500 Patches) auf G5 + PA und midi, Beamer / evtl. MIDIBOARD (kurzweil) (nur Samstag)
* EL-KA Member HaJo PS3100 (SA only)und von Georg "dem berühmten Erfinder" Mahr den MSQ-51 CV Sequenzer (Sa only?)
* Mathias / Curetronic
* Dirk Matten +
* Frank S. mit Synthanorma Sequencer vom Synthesizerstudio Bonn
* [[pattysplanet]] (clavia nordmodular + macbook, WX gesteuert)

[[Image:Happyknobbing_413.JPG|Ein Teil der Gruppe vom Treffen - Es sind halt nicht alle drauf - Modularmeeting 2007]]

--> einige, die sich angekündigt haben, stehen noch nicht hier.. können sich aber eintragen: login wie immer gegen email und nickname bei moogulator.. more tba.. http://www.synthesizerforum.de/synthesizer/viewtopic.php?t=11811&start=120&postdays=0&postorder=asc&highlight=

about 32 people came and even more modulars compared to 2006 - and: it was far out and in very official holidays, so some family guys could not come.. they will have to dream about it till 2008.. harhar..

==Modular Meeting 2006==
-> about 40 people with many more synths

*Bernie / [[Aliens-Project]] - Alles aus dem Studio (Gastgeber) ua [[M5]], Moog, PPG, Roland [[System700]], Dotcom und andere Modulars
*[[Moogulator]] / Mic - [[Roland]] 100m, DIY Sequencer 10 Step, (kleines Pult)
* HPL [[Semtex]], [[Sequentix]] [[P3]], [[Sherman]] Filterbank
* Smoo/Sägezahn / Olivier, [[Auralesque]] Modular DIY
* Island - [[Synthesizers.com]] Modular + little [[Curetronic]] Box
* Scaff / Meic - [[Synthesizers.com]] Modular, Machinedrum, [[Semtex]]
* Jörg (Erren) - [[Curetronic]] Modular, [[Semtex]]
* Groovepatcher / Sven - großes [[Doepfer]] Modular
* Happy / Christian - [[Curetronic]] + [[Dotcom]] Modular
* the Vision / Robert - [[ARP]] [[Avatar]] modularisiert + [[MS20]]
* Bluesynths / Theo Bloderer - MS20
* Monolith 2063 / Oliver - dotcom Modular, [[ARP]] [[Odyssey]], [[Doepfer]] Module
* Serenadi - Großes DIY Modular "Le Bernard"
* Curetronic / Mattias Schmidt - [[Curetronic]] Modular
* Penko / [[Schneidersbüro]] - [[Cwejman]] [[S1]] und [[Cwejman]] Modular
* Anyware / Thomas - [[Semtex]] und DIY Kits
* elektrolabel / Jan - [[Curetronic]] Modular
* Ralf - [[ARP]][[2600]]
* Oliver - DIY Sequencer 64 Step,[[ARP]][[2600]] [[Doepfer]] Modular [[Orgon]] Systems [[Enigiser]]
* 3x Personen ? - [[Doepfer]] Modular
* ACA - [[Roland]] [[System100]]
* Moondust - [[Doepfer]] Modular / DIY
* ENT / Kai - [[System100]]
* 0=1 / Matthias + Alex - Full MS-Series ([[MS10]],[[MS20]],[[SQ10]],[[MS50]]) some doubles..
* Haesslich - DIY Modular
* Kreismeister / Guido - [[Simplesizer]], [[Doepfer]] Modular
* Interfunk / Electronic Corporation - [[SAM16]] Sequencer, Full [[Korg]] MS-Series ([[MS20]],[[SQ10]],[[MS50]]), [[KRR55]], Semtex?
* Sonicwarrior - [[Semtex]]

- app. 37 - 40 Members, please add your Info here if you do not find your name..

==Modular Meeting Infopage + Pics/Videos==

back to main page..

--> [[Happy Knobbing Modular Meeting]]

Happy Knobbing Members

2008-04-06T19:24:42Z

MIK:

'''[[Happy Knobbing Modular Meeting]] Members'''
we don't know if there is a next meeting but this time it's at least these members attending:

==Modular Meeting 2008==
[[Image:Butt-Happy.jpg]]

We'll do a next meeting at the same time (Weekend + something that is called Pfingsten (Whitsuntide) over here, since it is free for all working people in germany) next year (2008), so you can register to the forum so we know you when you want to come.. but it's also no problem to just come along - but don't forget something modular.. if it's too hard for transport just end me an email..

Es ist soweit: Pfingsten 2008 wird das nächste Treffen steigen! Thomas wird wieder die Behausung stellen - Gegenüber Hauptstraße 122 neben der Kirche.

es ist nicht sicher, dass wir das Treffen wirklich regelmäßig (also ab 2009) machen, daher bitte nicht drauf verlassen - Es hängt letzlich von allen Beteiligten ab, DASS es stattfindet. An den "Ryhthmus" bitte also nicht gewöhnen! Nur bitte den Modular und den Spaß nicht vergessen.

Machines that will work: Digital, Analogue and Software Modulars with Monitor (TFT, CRT, Plasma.. doesn't matter but you need to be able to see the Patches) - No Modular - no entrance because it is limited space.

Regeln 2008 werden wie 2007 sein: Alles erlaubt vom Computer / Software Modular bis zu analogen oder digitaler Hardware, Software jedoch bitte nur mit Bildschirm, sonst bringts nichts - Außerdem haben wir nur begrenzt Platz, daher auch diesmal diese Regeln. Essen muss nicht mitgenommen werden, es wird gegrillt - Der Preis wird ca 20-30€ betragen (Essen + Raummiete für FR-SO).

===was muss man machen, um mitzumachen?===
*ein Modularsystem mitbringen, dabei ist egal welcher Art: Analog, Digital, Computer, es muss aber bei digitalen Systemen das Patch sichtbar sein (Computer ist dann Pflicht zum mitbringen, sonst kann man nichts sehen) - Ohne Modular oder wenigstens nem netten Modularsequencer bitte auf ein normales Treffen kommen, Raum ist begrenzt im Platz daher..
*Anmeldung im Forum idealerweise und freiwillig hier Listung Name/Gear und evtl Performance und Workshops (freiwillig natürlich).
*Abdrücken von ca. 20-30 Euro für Essen und Raummiete
*Sonst nichts.. Nur nicht vergessen, was man so braucht zum betrieb und anspielen, siehe weiter unten..
*Bitte diese Regeln nicht durchdiskutieren, wir haben das jetzt zum dritten Mal und waren immer froh, dass wir das so gemacht haben, weil es sonst einfach zu voll geworden wäre.. Wir überlegen einen Besuchertag zB am SO zu machen, hierzu bitte im Forum diskutieren.
*Login fürs Wiki hier gibts bei Moogulator gegen Emailnennung via PM im [[Forum]]..

===Members 2008===
who will attend:

* [[Pattysplanet]] --> gearliste siehe Moogulator..
* [[Moogulator]] zusammen: [[Symbolic Sound]] Kyma + System 100m + [[Clavia]] G2? / Reaktor? / [[EMS]] Synthi A - wenns den Krraftzwerg von MFBx bis dahin gibt auch den ;)
* Bernie ([[Aliens-Project]]) - back roots: vintage Roland + PPG Modular, EMS-AKS, EMS-VCS3...
* Jan ([[Elektrolabel]]) - - EMS-SYNTHI-E + W.Palm DerKleine + Lots of cabinets, Soundlab Minisynth, Modular Controllers
* [[Anyware]] - inSEQt & ??
* [http://www.fonitronik.de fonik] - surprise (klee?)...
* [http://www.joerg-erren.de Jörg] - Semtex + ein paar Doepfer Module + ???
* TomAbe - [[Semtex]] und [[TMSS]]/[[Theis]]Modular und [[InSEQt]] ohne Fragezeichen! Den bringe ich auch mit.
* Sadnoiss [[TMSS]]/[[Theis]]Modular
* herw [http://reaktor.approx.de/phpbb3/index.php Deutsches Reaktor Forum] - modular m1 + modular ts + Doepfer
* [http://www.sdiy.de sonicwarrior] - ? (Auf jeden Fall diesmal mit zwei Schraubenziehern mit Bits!!! ;) )
* Scaff
* Kreismeister
* Sauron the Mad - PAiA
* Feinstrom
* System700
* Tronique [[TMSS]]/[[Theis]]Modular
* Penko
* MiK (mit [http://http://www.youtube.com/watch?v=Itx5pnHSeAA Eigenbau-Synth] und Formant, nebst Zubehör)
unconfirmed/tba.
* Paul, Andreas, Heinzel @ [[Schneidersbüro]]
* [[Curetronic]] - Matthias
* XeroX mit ein paar Dotcom Modulen und Anyware Instruments Semtex und auch hoffentlich dem Inseqt
* tba.

more @ Forum: http://www.sequencer.de/synthesizer/viewtopic.php?t=22353&postdays=0&postorder=asc&start=30

===Workshops + Performance 2008===
finden nur am SA statt (vorraussichtlich)
Samstag - Haupttag für Workshops und Performance

*15:00 [[Moogulator]] vermtl. [[Kyma]] oder [[Roland]] [[System100m]]
*16:00 5-10 Minuten Geräusch und Vorstellung aller, die Lust haben nach Anmeldung hier, bzw Meldung vor Ort.
*19:00 Einzeljams einzelner Gruppen
*20:00 Moogulator, kleine Performance (gern auch mit anderen, bitte melden bis Jan 2008 - Jamgruppe 1, via Forum abklären..)
* ??
* 23:00 Ende Performance, es geht "normal" weiter oder nach gemeinsamem Entschluss..

Die Zeiten am SAMSTAG von ca. 19:00 bis 23:00 sind für Live Performance vorgesehen.
Das halten wir rel. offen, jedoch soll die Musik nicht zu kurz kommen. Die anderen Tage sind für Aufbau, Abbau, Ankommen, Abfahren gedacht und weiteres Fachsimpeln, denn das geht ja früh ab NAchmittag los und endet offen am Sonntag.

===Jamgruppen 1-5 Leute und grobe Richtung===
*Gruppe 1 - Moogulator + ?? - Frickelelektronik und Neumodisches Getute™ (TD-freie Zone)
*Gruppe 2 - ?? - (??)
*Gruppe 3 - ?? - (??)
*tba

==Modular Meeting 2007==
[[Image:Butt-Happy.jpg]]

===Members 2007 (as good as I/we know)===

[[Image:Modular_menschenfleisch_lor.jpg]]

* Oliver -(Formant mit sehr hellen LEDs, Synthi A)
* Rechner7 - Doepfer
* Synthdoctor (MS10 mod - moog filter, modularisiert - SQ10)
* HPL (doepfer moduler, p3, cwejman s1, semtex)
* + [[Moogulator]] - [[Roland]] [[100m]], evtl. DIY Sequencer 10 Step, Roland [[SH5]] oder [[SH7]] (kleines Pult, [[Electribe]])
* Elektrolabel - Jan - 4 Cabinets mit Modulen (evtl. ein fünftes), [[Sherman]] FB2, [[ML303]], [[Sidbox]], [[ARP]] [[Axxe]], [[Yamaha]] [[CS5]]
* + ACA - [[Doepfer]] Modular + X - Recording
* Moondust / DIY Doepfer?
* serenadi - LeBernard™ modular
* Haesslich - [[Doepfer]] Modular
* [[Anyware]] / Thomas - Veranstalter - Master of this years meeting.. with [[InSEQt]], [[Semtex]] + [[Cloxbox]]?..
* Sonicwarrior - [[Curetronic]] Modular plus X (evtl. Formant Tastatur, [[ML303]] oder [[InSEQt]])
* + Scaff - [[Dotcom]] Modular + ?
* [[User:Kreismeister]] - [[Doepfer]] Modular
* [http://www.modular.fonik.de FONIK] (Matthias H.)- 2x2 3HE Cabinets DIY Modular, Baby10 Sequencer, Waterproof SoundLab (nur SA)
* [[User:tronique]] - [[TMSS]]/[[Theis]] Modular
* TomAbe - [[Semtex]] und [[TMSS]]/[[Theis]]Modular und [[InSEQt]]???
* Happy - [[Dotcom]] Modular + X
* Penko [[User:Penkollage]] von [[Schneidersbüro]] &
* Paul "Herr Schulz" [[Schneidersbüro]] mit Cwejman-Module, MFB-Module, Livewire, Bananalogue, [[Steckbox]]
http://www.superbooth.com
* Bernie ([[Aliens-Project]]) - PPG 300 Modular + Dotcom Modular (3 big cabinets), Space-Echo, EMS VCS3, Coron DS-7, WEM Copycat, FX, Mixer + Kleinkram...
http://www.aliens-project.de
* herw - MODULAR MINI 2 (Version 2.6 / > 500 Patches) auf G5 + PA und midi, Beamer / evtl. MIDIBOARD (kurzweil) (nur Samstag)
* EL-KA Member HaJo PS3100 (SA only)und von Georg "dem berühmten Erfinder" Mahr den MSQ-51 CV Sequenzer (Sa only?)
* Mathias / Curetronic
* Dirk Matten +
* Frank S. mit Synthanorma Sequencer vom Synthesizerstudio Bonn
* [[pattysplanet]] (clavia nordmodular + macbook, WX gesteuert)

[[Image:Happyknobbing_413.JPG|Ein Teil der Gruppe vom Treffen - Es sind halt nicht alle drauf - Modularmeeting 2007]]

--> einige, die sich angekündigt haben, stehen noch nicht hier.. können sich aber eintragen: login wie immer gegen email und nickname bei moogulator.. more tba.. http://www.synthesizerforum.de/synthesizer/viewtopic.php?t=11811&start=120&postdays=0&postorder=asc&highlight=

about 32 people came and even more modulars compared to 2006 - and: it was far out and in very official holidays, so some family guys could not come.. they will have to dream about it till 2008.. harhar..

==Modular Meeting 2006==
-> about 40 people with many more synths

*Bernie / [[Aliens-Project]] - Alles aus dem Studio (Gastgeber) ua [[M5]], Moog, PPG, Roland [[System700]], Dotcom und andere Modulars
*[[Moogulator]] / Mic - [[Roland]] 100m, DIY Sequencer 10 Step, (kleines Pult)
* HPL [[Semtex]], [[Sequentix]] [[P3]], [[Sherman]] Filterbank
* Smoo/Sägezahn / Olivier, [[Auralesque]] Modular DIY
* Island - [[Synthesizers.com]] Modular + little [[Curetronic]] Box
* Scaff / Meic - [[Synthesizers.com]] Modular, Machinedrum, [[Semtex]]
* Jörg (Erren) - [[Curetronic]] Modular, [[Semtex]]
* Groovepatcher / Sven - großes [[Doepfer]] Modular
* Happy / Christian - [[Curetronic]] + [[Dotcom]] Modular
* the Vision / Robert - [[ARP]] [[Avatar]] modularisiert + [[MS20]]
* Bluesynths / Theo Bloderer - MS20
* Monolith 2063 / Oliver - dotcom Modular, [[ARP]] [[Odyssey]], [[Doepfer]] Module
* Serenadi - Großes DIY Modular "Le Bernard"
* Curetronic / Mattias Schmidt - [[Curetronic]] Modular
* Penko / [[Schneidersbüro]] - [[Cwejman]] [[S1]] und [[Cwejman]] Modular
* Anyware / Thomas - [[Semtex]] und DIY Kits
* elektrolabel / Jan - [[Curetronic]] Modular
* Ralf - [[ARP]][[2600]]
* Oliver - DIY Sequencer 64 Step,[[ARP]][[2600]] [[Doepfer]] Modular [[Orgon]] Systems [[Enigiser]]
* 3x Personen ? - [[Doepfer]] Modular
* ACA - [[Roland]] [[System100]]
* Moondust - [[Doepfer]] Modular / DIY
* ENT / Kai - [[System100]]
* 0=1 / Matthias + Alex - Full MS-Series ([[MS10]],[[MS20]],[[SQ10]],[[MS50]]) some doubles..
* Haesslich - DIY Modular
* Kreismeister / Guido - [[Simplesizer]], [[Doepfer]] Modular
* Interfunk / Electronic Corporation - [[SAM16]] Sequencer, Full [[Korg]] MS-Series ([[MS20]],[[SQ10]],[[MS50]]), [[KRR55]], Semtex?
* Sonicwarrior - [[Semtex]]

- app. 37 - 40 Members, please add your Info here if you do not find your name..

==Modular Meeting Infopage + Pics/Videos==

back to main page..

--> [[Happy Knobbing Modular Meeting]]

Happy Knobbing Members

2008-03-22T23:40:54Z

MIK:

'''[[Happy Knobbing Modular Meeting]] Members'''
we don't know if there is a next meeting but this time it's at least these members attending:

==Modular Meeting 2008==
[[Image:Butt-Happy.jpg]]

We'll do a next meeting at the same time (Weekend + something that is called Pfingsten (Whitsuntide) over here, since it is free for all working people in germany) next year (2008), so you can register to the forum so we know you when you want to come.. but it's also no problem to just come along - but don't forget something modular.. if it's too hard for transport just end me an email..

Es ist soweit: Pfingsten 2008 wird das nächste Treffen steigen! Thomas wird wieder die Behausung stellen - Gegenüber Hauptstraße 122 neben der Kirche.

es ist nicht sicher, dass wir das Treffen wirklich regelmäßig (also ab 2009) machen, daher bitte nicht drauf verlassen - Es hängt letzlich von allen Beteiligten ab, DASS es stattfindet. An den "Ryhthmus" bitte also nicht gewöhnen! Nur bitte den Modular und den Spaß nicht vergessen.

Machines that will work: Digital, Analogue and Software Modulars with Monitor (TFT, CRT, Plasma.. doesn't matter but you need to be able to see the Patches) - No Modular - no entrance because it is limited space.

Regeln 2008 werden wie 2007 sein: Alles erlaubt vom Computer / Software Modular bis zu analogen oder digitaler Hardware, Software jedoch bitte nur mit Bildschirm, sonst bringts nichts - Außerdem haben wir nur begrenzt Platz, daher auch diesmal diese Regeln. Essen muss nicht mitgenommen werden, es wird gegrillt - Der Preis wird ca 20-30€ betragen (Essen + Raummiete für FR-SO).

===was muss man machen, um mitzumachen?===
*ein Modularsystem mitbringen, dabei ist egal welcher Art: Analog, Digital, Computer, es muss aber bei digitalen Systemen das Patch sichtbar sein (Computer ist dann Pflicht zum mitbringen, sonst kann man nichts sehen) - Ohne Modular oder wenigstens nem netten Modularsequencer bitte auf ein normales Treffen kommen, Raum ist begrenzt im Platz daher..
*Anmeldung im Forum idealerweise und freiwillig hier Listung Name/Gear und evtl Performance und Workshops (freiwillig natürlich).
*Abdrücken von ca. 20-30 Euro für Essen und Raummiete
*Sonst nichts.. Nur nicht vergessen, was man so braucht zum betrieb und anspielen, siehe weiter unten..
*Bitte diese Regeln nicht durchdiskutieren, wir haben das jetzt zum dritten Mal und waren immer froh, dass wir das so gemacht haben, weil es sonst einfach zu voll geworden wäre.. Wir überlegen einen Besuchertag zB am SO zu machen, hierzu bitte im Forum diskutieren.
*Login fürs Wiki hier gibts bei Moogulator gegen Emailnennung via PM im [[Forum]]..

===Members 2008===
who will attend:

* [[Pattysplanet]] --> gearliste siehe Moogulator..
* [[Moogulator]] zusammen: [[Symbolic Sound]] Kyma + System 100m + [[Clavia]] G2? / Reaktor? / [[EMS]] Synthi A - wenns den Krraftzwerg von MFBx bis dahin gibt auch den ;)
* Bernie ([[Aliens-Project]]) - back roots: vintage Roland + PPG Modular, EMS-AKS, EMS-VCS3...
* Jan [[Elektrolabel]] - Modularsystem, Soundlab Minisynth, Modular Controllers
* [[Anyware]] - inSEQt & ??
* [http://www.modular.fonik.de fonik] - surprise...
* [http://www.joerg-erren.de Jörg] - Semtex + ein paar Doepfer Module + ???
* TomAbe - [[Semtex]] und [[TMSS]]/[[Theis]]Modular und [[InSEQt]] ohne Fragezeichen! Den bringe ich auch mit.
* Sadnoiss [[TMSS]]/[[Theis]]Modular
* herw [http://reaktor.approx.de/phpbb3/index.php Deutsches Reaktor Forum] - modular m1 + modular ts + Doepfer
* [http://www.sdiy.de sonicwarrior] - ? (Auf jeden Fall diesmal mit zwei Schraubenziehern mit Bits!!! ;) )
* Scaff
* Kreismeister
* Sauron the Mad - PAiA
* Feinstrom
* System700
* Tronique [[TMSS]]/[[Theis]]Modular
* Penko
* MiK (mit dem [http://http://www.youtube.com/watch?v=Itx5pnHSeAA Eigenbau-Synth] und nem Rechner zum umkonfigurieren)
unconfirmed/tba.
* Paul, Andreas, Heinzel @ [[Schneidersbüro]]
* [[Curetronic]] - Matthias
* tba.
more @ Forum: http://www.sequencer.de/synthesizer/viewtopic.php?t=22353&postdays=0&postorder=asc&start=30

===Workshops + Performance 2008===
finden nur am SA statt (vorraussichtlich)
Samstag - Haupttag für Workshops und Performance

*15:00 [[Moogulator]] vermtl. [[Kyma]] oder [[Roland]] [[System100m]]
*16:00 5-10 Minuten Geräusch und Vorstellung aller, die Lust haben nach Anmeldung hier, bzw Meldung vor Ort.
*19:00 Einzeljams einzelner Gruppen
*20:00 Moogulator, kleine Performance (gern auch mit anderen, bitte melden bis Jan 2008 - Jamgruppe 1, via Forum abklären..)
* ??
* 23:00 Ende Performance, es geht "normal" weiter oder nach gemeinsamem Entschluss..

Die Zeiten am SAMSTAG von ca. 19:00 bis 23:00 sind für Live Performance vorgesehen.
Das halten wir rel. offen, jedoch soll die Musik nicht zu kurz kommen. Die anderen Tage sind für Aufbau, Abbau, Ankommen, Abfahren gedacht und weiteres Fachsimpeln, denn das geht ja früh ab NAchmittag los und endet offen am Sonntag.

===Jamgruppen 1-5 Leute und grobe Richtung===
*Gruppe 1 - Moogulator + ?? - Frickelelektronik und Neumodisches Getute™ (TD-freie Zone)
*Gruppe 2 - ?? - (??)
*Gruppe 3 - ?? - (??)
*tba

==Modular Meeting 2007==
[[Image:Butt-Happy.jpg]]

===Members 2007 (as good as I/we know)===

[[Image:Modular_menschenfleisch_lor.jpg]]

* Oliver -(Formant mit sehr hellen LEDs, Synthi A)
* Rechner7 - Doepfer
* Synthdoctor (MS10 mod - moog filter, modularisiert - SQ10)
* HPL (doepfer moduler, p3, cwejman s1, semtex)
* + [[Moogulator]] - [[Roland]] [[100m]], evtl. DIY Sequencer 10 Step, Roland [[SH5]] oder [[SH7]] (kleines Pult, [[Electribe]])
* Elektrolabel - Jan - 4 Cabinets mit Modulen (evtl. ein fünftes), [[Sherman]] FB2, [[ML303]], [[Sidbox]], [[ARP]] [[Axxe]], [[Yamaha]] [[CS5]]
* + ACA - [[Doepfer]] Modular + X - Recording
* Moondust / DIY Doepfer?
* serenadi - LeBernard™ modular
* Haesslich - [[Doepfer]] Modular
* [[Anyware]] / Thomas - Veranstalter - Master of this years meeting.. with [[InSEQt]], [[Semtex]] + [[Cloxbox]]?..
* Sonicwarrior - [[Curetronic]] Modular plus X (evtl. Formant Tastatur, [[ML303]] oder [[InSEQt]])
* + Scaff - [[Dotcom]] Modular + ?
* [[User:Kreismeister]] - [[Doepfer]] Modular
* [http://www.modular.fonik.de FONIK] (Matthias H.)- 2x2 3HE Cabinets DIY Modular, Baby10 Sequencer, Waterproof SoundLab (nur SA)
* [[User:tronique]] - [[TMSS]]/[[Theis]] Modular
* TomAbe - [[Semtex]] und [[TMSS]]/[[Theis]]Modular und [[InSEQt]]???
* Happy - [[Dotcom]] Modular + X
* Penko [[User:Penkollage]] von [[Schneidersbüro]] &
* Paul "Herr Schulz" [[Schneidersbüro]] mit Cwejman-Module, MFB-Module, Livewire, Bananalogue, [[Steckbox]]
http://www.superbooth.com
* Bernie ([[Aliens-Project]]) - PPG 300 Modular + Dotcom Modular (3 big cabinets), Space-Echo, EMS VCS3, Coron DS-7, WEM Copycat, FX, Mixer + Kleinkram...
http://www.aliens-project.de
* herw - MODULAR MINI 2 (Version 2.6 / > 500 Patches) auf G5 + PA und midi, Beamer / evtl. MIDIBOARD (kurzweil) (nur Samstag)
* EL-KA Member HaJo PS3100 (SA only)und von Georg "dem berühmten Erfinder" Mahr den MSQ-51 CV Sequenzer (Sa only?)
* Mathias / Curetronic
* Dirk Matten +
* Frank S. mit Synthanorma Sequencer vom Synthesizerstudio Bonn
* [[pattysplanet]] (clavia nordmodular + macbook, WX gesteuert)

[[Image:Happyknobbing_413.JPG|Ein Teil der Gruppe vom Treffen - Es sind halt nicht alle drauf - Modularmeeting 2007]]

--> einige, die sich angekündigt haben, stehen noch nicht hier.. können sich aber eintragen: login wie immer gegen email und nickname bei moogulator.. more tba.. http://www.synthesizerforum.de/synthesizer/viewtopic.php?t=11811&start=120&postdays=0&postorder=asc&highlight=

about 32 people came and even more modulars compared to 2006 - and: it was far out and in very official holidays, so some family guys could not come.. they will have to dream about it till 2008.. harhar..

==Modular Meeting 2006==
-> about 40 people with many more synths

*Bernie / [[Aliens-Project]] - Alles aus dem Studio (Gastgeber) ua [[M5]], Moog, PPG, Roland [[System700]], Dotcom und andere Modulars
*[[Moogulator]] / Mic - [[Roland]] 100m, DIY Sequencer 10 Step, (kleines Pult)
* HPL [[Semtex]], [[Sequentix]] [[P3]], [[Sherman]] Filterbank
* Smoo/Sägezahn / Olivier, [[Auralesque]] Modular DIY
* Island - [[Synthesizers.com]] Modular + little [[Curetronic]] Box
* Scaff / Meic - [[Synthesizers.com]] Modular, Machinedrum, [[Semtex]]
* Jörg (Erren) - [[Curetronic]] Modular, [[Semtex]]
* Groovepatcher / Sven - großes [[Doepfer]] Modular
* Happy / Christian - [[Curetronic]] + [[Dotcom]] Modular
* the Vision / Robert - [[ARP]] [[Avatar]] modularisiert + [[MS20]]
* Bluesynths / Theo Bloderer - MS20
* Monolith 2063 / Oliver - dotcom Modular, [[ARP]] [[Odyssey]], [[Doepfer]] Module
* Serenadi - Großes DIY Modular "Le Bernard"
* Curetronic / Mattias Schmidt - [[Curetronic]] Modular
* Penko / [[Schneidersbüro]] - [[Cwejman]] [[S1]] und [[Cwejman]] Modular
* Anyware / Thomas - [[Semtex]] und DIY Kits
* elektrolabel / Jan - [[Curetronic]] Modular
* Ralf - [[ARP]][[2600]]
* Oliver - DIY Sequencer 64 Step,[[ARP]][[2600]] [[Doepfer]] Modular [[Orgon]] Systems [[Enigiser]]
* 3x Personen ? - [[Doepfer]] Modular
* ACA - [[Roland]] [[System100]]
* Moondust - [[Doepfer]] Modular / DIY
* ENT / Kai - [[System100]]
* 0=1 / Matthias + Alex - Full MS-Series ([[MS10]],[[MS20]],[[SQ10]],[[MS50]]) some doubles..
* Haesslich - DIY Modular
* Kreismeister / Guido - [[Simplesizer]], [[Doepfer]] Modular
* Interfunk / Electronic Corporation - [[SAM16]] Sequencer, Full [[Korg]] MS-Series ([[MS20]],[[SQ10]],[[MS50]]), [[KRR55]], Semtex?
* Sonicwarrior - [[Semtex]]

- app. 37 - 40 Members, please add your Info here if you do not find your name..

==Modular Meeting Infopage + Pics/Videos==

back to main page..

--> [[Happy Knobbing Modular Meeting]]

BC-Convert

2007-05-22T09:58:58Z

MIK:

This utility is able to convert the configuration of the [[B-Control]] series MIDI controllers between native [[SysEx]] format and a text file, which can be edited by any editor to change the configuration without having to fiddle around with the cumbersome built in user interface.

The current version of BC-Convert can be found [[Media:BC-Convert 0.3 Win OSX.zip|here]].

For a small documentation of the usage, read the following.

<pre>aphrodite:~/Documents/SysEx Librarian michael$ ./bc-convert -h
BC-Convert Version 0.3 (C) 2006 Michael Kukat
Usage: ./bc-convert [options]
Error: Help requested
Options:
-i <input file> Input file (default stdin)
-o <output file> Output file (default stdout)
-d <device id> Device ID (used on SysEx output only)
-m <model id> Model ID (used on SysEx output only)
-s Force SysEx output (default autodetect)
-t Force text output (default autodetect)

-s and -t can't be used together for obvious reasons.
aphrodite:~/Documents/SysEx Librarian michael$ </pre>

This is a command line tool, which has been compiled for MacOS X and Win32. No Drag&Drop or other funny stuff, just the command line. The following options can be used:

'''-i <input file>''' - gives the file to read for conversion.

'''-o <output file>''' - gives the file to write to. WARNING! This file will be overwritten!

'''-d <device id>''' - used on text to SysEx conversion only, sets the device ID of the device to configure. This is the configured ID less one. So if you configured ID 1 on your B-Control, use -d 0 for the converter. This argument is optional, by default, 127 is assumed, which talks to all B-Control devices on the MIDI interface you are sending the SysEx file on.

'''-m <model id>''' - very similar to the -d option, but sets the model ID. Usually, this is 20 for BCF2000 and 21 for BCR2000. Set to 127 by default, which in conjunction with the default device ID of 127 talks to all B-Control devices on the MIDI interface you are sending the SysEx file on.

'''-s''' - This forces conversion from text to SysEx, usually, the auto detection mechanism is able to recognize the conversion direction.

'''-t''' - The opposite of -s, this forces SysEx to text conversion.

The text format is quite simple, it contains the data encapsulated in the SysEx messages of the [[B-Control]]. As an addition, the converter has some features to simplify your life, it ignores blank lines and is able to strip off comments from your text, which the B-Control might not understand, but which help you to keep your files readable. By first converting a preset to text, you get somthing like this in your text file:

<pre># Generated by BC-Convert. Input was DeviceID 0, ModelID 21

$rev R1
...</pre>

The first line is a comment and will not be sent with the SysEx data. The second line is blank and will also net get sent. In detail, the parser works the following way:

First, isolate the complete line. Next, scan from the start of the line for a character starting a comment. This is the hash (#) and the semicolon (;). The semicolon should no longer be used, as it might disappear somewhen, so please only use the hash to start a comment. If one of those characters is found, the line is scanned backwards skipping all white spaces (blanks and TABs). The comment including all leading white spaces is stripped off.

If after this something is left over, it is written to the SysEx file.

So comments can be used like in the following example:

<pre># This is my test configuration

$rev R1 # Start BCR configuration
$preset # Start preset configuration
.init # Clear current edit buffer

#-------------------------
# Encoder 1 - MIDI volume
#-------------------------

$encoder 1 # Start encoder configuration
.easypar CC 1 7 0 127 absolute
.showvalue on
.mode 12dot/off
.resolution 96 96 96 96
.default 100

$end # End of BCR configuration</pre>

As you can see, everything can be well-formatted and commented this way. For a list of possible tokens which can be used in the configuration file, see [[B-Control-Tokenreferenz]].

[[category:Tricks]]

B-Control-Tokenreferenz

2007-02-16T05:02:47Z

MIK: /* $global */

[[category:MIDI]]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.

[[category:Tricks]]

BC-Convert

2007-01-07T18:34:17Z

MIK:

BC-Convert

2007-01-07T18:30:54Z

MIK:

This utility is able to convert the configuration of the [[B-Control]] series MIDI controllers between native [[SysEx]] format and a text file, which can be edited by any editor to change the configuration without having to fiddle around with the cumbersome built in user interface.

The current version of BC-Convert can be found here: [[Image:BC-Convert 0.3 Win OSX.zip]]

For a small documentation of the usage, read the following.

<pre>aphrodite:~/Documents/SysEx Librarian michael$ ./bc-convert -h
BC-Convert Version 0.3 (C) 2006 Michael Kukat
Usage: ./bc-convert [options]
Error: Help requested
Options:
-i <input file> Input file (default stdin)
-o <output file> Output file (default stdout)
-d <device id> Device ID (used on SysEx output only)
-m <model id> Model ID (used on SysEx output only)
-s Force SysEx output (default autodetect)
-t Force text output (default autodetect)

-s and -t can't be used together for obvious reasons.
aphrodite:~/Documents/SysEx Librarian michael$ </pre>

This is a command line tool, which has been compiled for MacOS X and Win32. No Drag&Drop or other funny stuff, just the command line. The following options can be used:

'''-i <input file>''' - gives the file to read for conversion.

'''-o <output file>''' - gives the file to write to. WARNING! This file will be overwritten!

'''-d <device id>''' - used on text to SysEx conversion only, sets the device ID of the device to configure. This is the configured ID less one. So if you configured ID 1 on your B-Control, use -d 0 for the converter. This argument is optional, by default, 127 is assumed, which talks to all B-Control devices on the MIDI interface you are sending the SysEx file on.

'''-m <model id>''' - very similar to the -d option, but sets the model ID. Usually, this is 20 for BCF2000 and 21 for BCR2000. Set to 127 by default, which in conjunction with the default device ID of 127 talks to all B-Control devices on the MIDI interface you are sending the SysEx file on.

'''-s''' - This forces conversion from text to SysEx, usually, the auto detection mechanism is able to recognize the conversion direction.

'''-t''' - The opposite of -s, this forces SysEx to text conversion.

The text format is quite simple, it contains the data encapsulated in the SysEx messages of the [[B-Control]]. As an addition, the converter has some features to simplify your life, it ignores blank lines and is able to strip off comments from your text, which the B-Control might not understand, but which help you to keep your files readable. By first converting a preset to text, you get somthing like this in your text file:

<pre># Generated by BC-Convert. Input was DeviceID 0, ModelID 21

$rev R1
...</pre>

The first line is a comment and will not be sent with the SysEx data. The second line is blank and will also net get sent. In detail, the parser works the following way:

First, isolate the complete line. Next, scan from the start of the line for a character starting a comment. This is the hash (#) and the semicolon (;). The semicolon should no longer be used, as it might disappear somewhen, so please only use the hash to start a comment. If one of those characters is found, the line is scanned backwards skipping all white spaces (blanks and TABs). The comment including all leading white spaces is stripped off.

If after this something is left over, it is written to the SysEx file.

So comments can be used like in the following example:

<pre># This is my test configuration

$rev R1 # Start BCR configuration
$preset # Start preset configuration
.init # Clear current edit buffer

#-------------------------
# Encoder 1 - MIDI volume
#-------------------------

$encoder 1 # Start encoder configuration
.easypar CC 1 7 0 127 absolute
.showvalue on
.mode 12dot/off
.resolution 96 96 96 96
.default 100

$end # End of BCR configuration</pre>

As you can see, everything can be well-formatted and commented this way. For a list of possible tokens which can be used in the configuration file, see [[B-Control-Tokenreferenz]].

[[category:Tricks]]

Datei:BC-Convert 0.3 Win OSX.zip

2007-01-07T18:27:45Z

MIK:

Organ

2007-01-07T18:09:08Z

MIK:

The organ, sometimes called the queen of instruments, is in it classic form an instrument generating the tones by controlling airflow through several organ pipes. Those pipe organs today can usually be found in churchs. There also exist electronic versions or organs, which are more interesting for the audience here, as they have some similarities to a [[synthesizer]].

An electronic organ usually consists of an enclosure containing all electronics to generate the tones and a keyboard. The size of those models differs, there exist large versions with a form comparable to an upright piano, and portable versions, which look a lot like the synthesizer keyboard we know.

Technically, the classic electronic organ works completely different than a synthesizer. An organ made in the 1960s is fully polyphonic, compared to the usually monophonic synthesizers of this time. This polyphony is achieved by using just square waves. One master clock is first divided into 12 semitones, which have a quite high pitch after those dividers. Those 12 semitones are then divided in a divider chain, each chain divides the frequency by 2. This can be done very easy with digital electronics, as just one flipflop is needed for one divider stage. So all basic tone generators always run in parallel. The keys now just switch on and off this signal to the rest of the audio chain.

Usually, an organ-sound has a simple envelope. If the key is pressed down, the sound starts. If the key is released, the sound stops. The first electronic organs worked exactly this way. By the time, organs got more different sound flavours, even piano sounds can be found on some analog products, so an envelope generator is needed. And to keep the polyphony, not just one envelope generator is needed, but one per key.

To create an own volume envelope per key, there is a very simple VCA connected to each key, just consisting of a capacitor, which is fully charged when idle and is connected to the amplitude of the VCA when the key is pressed down, which discharges the capacitor. If the key is released, the capacitor is recharged very quickly.

So for a 61-key organ, we now have 61 rough square wave oscillators and 61 VCAs including envelope generators. Compared to a synthesizer, this is a lot, but all those components are quite primitive, the oscillators don't know any more complex waveforms, the the envelope generators are of AR-type with fixed attack and release values. Between those 2 sets of units, a common unit is present, which forms the sound. This usually consists of filters, depending on the type, several different configurations for this filtering can be activated to create different sound flavours.

So the sound flexibility of an electronic organ is very small compared to a synthesizer, but this might be compensated by the very good polyphony.

Most electronic organs also contain a bass section, which is a real analog synthesizer, as the bass section is also monophonic and usually of a voltage-controlled type.

[[MIDI]] is nearly impossible for this classic electronic organ, as every key needs to switch the audio signal and the capacitor for the envelope, so a MIDI kit would need two switches for every key. If you see an organ using MIDI, it is some modern digital organ, which works more like a primitive digital synthesizer.

[[category:Hardware]]

Organ

2007-01-07T18:08:18Z

MIK:

Wine Country

2007-01-07T17:05:41Z

MIK:

Ex-workers from [[Sequential Circuits]] founded [http://www.winecountrysequential.com/ Wine Country Productions Inc.] to continue supporting users of old Synthesizers made by Sequential Circuits. Even today they are still in business to provide spare parts and service for those old instruments.

Creamware Noah

2007-01-07T17:02:17Z

MIK:

The [[Creamware]] Noah was a successless Synthesizer which should bring together the best of the two world - hardware and software synthesizers. It is a 19" 2U box featuring 6 or 11 AD SHARC DSPs. This box wasn't a static synthesizer you have to take as it is, but it was a platform where synthesizer plugins could be installed. Those software synthesizers were based on the SCOPE platform plugins, in fact, the Noah is a small [[SCOPE]] platform as a standalone unit.

The market success of this synthesizer was way below the expectations, which led Creamware to the decision to greate a last edition of 111 units called the "Noah EX Final Edition", which were sold for 1.111 EUR per unit. Even today, one may occasionally hit one of those units in a store, maybe even for 990 EUR today.

As the machine is EOL, no further plugins will be programmed, and CreamWare published all available plugins without the need of a license key, so every Noah owner can use those plugins. As of today, the following plugins exist for the Noah:

* Profit5 - a [[Sequential Circuits]] [[Prophet 5]] emulation
* EDS8i - a vintage analog drum
* Prodyssey - an [[ARP]] [[Odyssey]] emulation
* Six-String - a guitar modeling synthesizer
* Vectron - a vector synthesizer, maybe inspired by the [[Korg]] [[Wavestation]]

The following plugins were included in the base system:

* B-2003 - the emulation of the classic [[Hammond]] [[B3]] [[Organ]]
* Lightwave - a [[wavetable]] based synthesizer
* Minimax - emulation of the well-known [[Moog]] [[Minimoog]]
* Vectron Player - stripped version of the Vectron plugin
* Pro-One - [[SCI]] [[Pro-One]] emulation, this was developed together with [[Wine Country]]

The device was available in 2 versions, the Noah, featuring 6 DSPs and the Noah EX with 11 DSPs, doubling the computing performance. In other aspects, the units were identical.

The 2U enclosure of the Noah contains a standard ATX power supply to feed all the electronics, as inputs and outputs, it features USB 1.1, optical audio with selectable 8 channel [[ADAT]] or 2 channel [[S/PDIF]] protocol, a [[wordclock]] connector was also present besides 2 channel analog input and 2 channel analog output. On the front, several buttons and rotaty encoders surround a large 2x40 characters LCD and a compact flash slot to store plugins and data.

Although the synthesizer is sounding really good and has a fascinating architecture, it might be just a collectors item today.

Ladder

2007-01-07T16:42:47Z

MIK:

Everyone knows what a ladder is. The ladder we mean in the synthesizer world usually is the so-called [[Moog]]-Ladder, which got its name by stacking 4 identical filter stages, each consisting of 2 transistors and 2 capacitors, bordered by 2 resistors each, on top of each other in the schematic diagram.

Ladder ist das englische Wort für Leiter, in dem Zusammenhang mit der Synthesizerwelt ist hier aber insbesondere die "[[Moog]]-Ladder" gemeint, die im Deutschen allgemein mit "Moog-Kaskade" übersetzt wird. Der Begriff kommt daher, dass 4 identische Filterstufen, jede aus 2 Transistoren und 2 Kondensatoren bestehend, umfasst von je 2 Widerständen, im Schaltplan übereinander angebracht sind wie die Stufen einer Leiter.

[[category:Sound_Synthesis]]

MIDI Format

2007-01-07T16:27:35Z

MIK: /* Darstellung negativer Zahlen und Tricks für Controllerboxen */

[[MIDI]] wurde in den frühen 1980er-Jahren erfunden und ist bis heute unverändert, was die Flexibilität des Protokolls deutlich macht. Es werden immer wieder Erweiterungen im Protokoll vorgenommen, weil die Urform diese Erweiterungsmöglichkeiten bereits vorgesehen hat. Die physikalische Datenübertragung soll hier nicht im Detail behandelt werden, es geht hier nur um alle Einzelheiten der Daten, die übertragen werden, die MIDI-Messages. Beim Lesen dieses Artikels ist es von Vorteil, fundiertes Wissen über [[Bits und Bytes]] zu haben, da hier viel mit binären und hexadezimalen Zahlen gearbeitet wird, und auch direkt Bits angeschaut werden.

MIDI ist eine serielle Schnittstelle, über die 8bit-Bytes übertragen werden können. Dabei hat das oberste Bit auch schon eine besondere Bedeutung.

== Statusbytes und Datenbytes ==

Ist das oberste Bit des übertragenen Bytes gesetzt, also der Wert >= 128, so handelt es sich um ein Statusbyte. Das Statusbyte kann als Kommando angesehen werden, es dient der Entscheidung, was mit den nachfolgenden Datenbytes genau geschehen soll. Da bei den Datenbytes das oberste Bit nicht gesetzt sein darf, weil es sich sonst um ein Statusbyte handeln würde, schränkt dies den Wertebereich für Datenbytes auf die bekannten 7 Bits ein, einem Wertebereich von 0 bis 127. Um dennoch größere Werte übertragen zu können, gibt es viele verschiedene Methoden, die insbesondere im Abschnitt über die System Exclusive ([[SysEx]]) Meldungen beschrieben werden.

Aufgrund dieser strikten Trennung zwischen Statusbytes und Datenbytes gibt es noch ein Feature namens "Running Status", welches die Datenübertragung optimieren soll. So ist es bei vielen Statusbytes nicht zwingend erforderlich, für jede Message das gleiche Statusbyte nochmals zu senden, es werden nur noch die Daten geschickt. Kommt also ein Note-On-Event, wird das Statusbyte nebst den beiden zugehörigen Datenbytes geschickt. Folgen diesem Note-On-Event noch weitere Note-On-Events auf dem selben Kanal, ändert sich das Statusbyte also nicht, wird es nicht nochmals mitgeschickt, sondern in der nächsten Message werden nur die beiden Datenbytes geschickt, der Empfänger weiss dann, dass das zuletzt empfangene Statusbyte zur Bildung der Message verwendet werden soll. Einige Statusbytes müssen jedoch jedes Mal übertragen werden, und einige davon brechen auch einen Running Status ab, während es andere nicht tun. Dies wird im Detail im nächsten Abschnitt beschrieben. Um Running Status noch weiter zu optimieren, gibt es noch einen Sonderfall beim Note-On-Event. Da ein Note-Off-Event einen neuen Status erforderlich machen würde, was nicht unbedingt gewünscht ist, kann statt dem Note-Off-Event auch ein Note-On-Event mit Velocity 0 geschickt werden, was der Empfänger als Note-Off-Event interpretieren sollte. Bei diesem Vorgehen ist es natürlich nicht möglich, eine Release-Velocity mitzuschicken.

Running Status stelle ein Problem für einige frühe MIDI-Geräte dar, der Elka Synthex ist z.B. nicht ohne weiteres fähig, damit umzugehen. Wenn man mit einem modernen Keyboard einfach eine Taste anschlägt und wieder loslässt, wird hier der Status für Note-On nebst den Notendaten geschickt, beim Loslassen wird der Note-On mit Velocity 0 geschickt. Der Synthex interpretiert das fälschlicherweise als weiteres Note-On-Event und schaltet den Ton nicht ab.

Die Definition sieht keinen Timeout für Running Status vor, die meisten Geräte schalten jedoch den Running Status nach einer gewissen Zeit selber wieder ab, wenn also z.B. 3 Sekunden nichts übertragen wird, "vergisst" der Sender das letzte Statusbyte und die nächste Message ist wieder eine vollständige Message. Dies hat den Sinn, falls der Sender zwischendurch mal nicht "zuhört", weil er vielleicht aus- und wieder eingeschaltet wurde, und damit den Status selber vergisst. Kommen nun nur Datenbytes, weiss er damit nichts anzufangen, daher wird nach einer gewissen Inaktivität der Status auf jeden Fall wieder neu gesendet.

== Die verschiedenen Statusbytes ==

Hier werden nun die möglichen Statusbytes und ihre genaue Funktion erläutert, auch ihre Auswirkung auf den Running Status wird mit erwähnt. Bei den meisten Statusbytes kann man schon aufgrund der Bits eine detailierte Vorentscheidung vornehmen, um welche Art von Message es sich handelt. Schauen wir einmal die Bits genauer an:

1 s s s c c c c

Das oberste Bit ist bei einer Statusmeldung immer gesetzt. Die nachfolgenden 3 Bits geben nun Auskunft über den Status selber, und wenn diese im Bereich 0 bis 6 liegen, sind die unteren 4 Bits der MIDI-Kanal. Der Mensch beginnt üblicherweise das Zählen bei 1, daher gibt es nach außen hin MIDI-Kanäle 1 bis 16. Intern wird dies jedoch, da der Computer bei 0 beginnt, mit 0 bis 15 abgebildet, so kommt man mit den vorhandenen 4 Bits für den Kanal aus. Dies gilt bei einem Status von 0 bis 6, also einem Statusbyte von 0x80 bis 0xef. Meldungen mit diesen Statusbytes werden "Voice Messages" genannt, weil sie alle einen direkten Zusammenhang mit dem von der Voice zu erzeugenden Ton haben. Voice Messages sind generell fähig, Running Status zu verwenden. Running Status funktioniert nur, wenn der MIDI-Kanal zwischen den Messages gleich bleibt. Für Running Status ist das Statusbyte als ganzes zu sehen. Kommen also 5 Note-On-Events, 3 davon auf Kanal 1 und 2 davon auf Kanal 2, so muß bei diesem Kanalwechsel auf jeden Fall ein neues Statusbyte mitgeschickt werden, weil sonst die letzten beiden Messages ebenfalls Kanal 1 zugeordnet werden. Ab dann gilt Note-On auf Kanal 2 als gespeichert, wenn nun Noten auf Kanal 1 eingeschaltet werden sollen, muss entsprechend wieder ein neues Statusbyte geschickt werden.

Bei Meldungen, wo alle s-Bits ebenfalls 1 sind, also bei Statusbytes >= 0xf0, gilt der Kanal nicht mehr. Hier kann aber wieder mit einer Bitmaske zur weiteren Entscheidung gearbeitet werden:

1 1 1 1 r s s s

Alle Statusbytes sind >= 0xf0, also sind die oberen 4 Bits alle 1. Das Bit 3 hat hier nun eine weitere Entscheidungsrolle. Ist es 0, also das Statusbyte zwischen 0xf0 und 0xf7, handelt es sich um eine sogenannte System Common Message, diese Kategorie vereint Nachrichten, die üblicherweise Datenbytes als Parameter benötigen, also nach dem Statusbyte meistens noch Datenbytes folgen werden. Natürlich gibt es hier auch Ausnahmen, wie wir später sehen werden. System Common Messages sind nicht fähig, Running Status zu benutzen, darüber hinaus brechen sie einen Running Status sogar ab. Wird also nach einem Note-On eine SysEx-Meldung geschickt, die aus den Status-Bytes 0xf0 und 0xf7 und dazwischen liegenden Datenbytes besteht, muss der Empfänger seinen Status löschen und der Sender muss bei der nächsten Voice Message auf jeden Fall wieder ein Statusbyte mitschicken. Datenbytes, die nach einer abgeschlossenen System Common Message folgen, müssen vom Empfänger ignoriert werden, weil es hierzu keinen Status gibt.

Ist das r-Bit gesetzt, also Statusbytes zwischen 0xf8 und 0xff, handelt es sich um System Realtime Messages. Diese können jederzeit in die Übertragung eingeschoben werden, ohne eine eventuell laufende Nachricht zu beeinträchtigen. So kann z.B. ein Note-On Status übertragen werden, dann das erste Datenbyte für Note-on, jetzt eine System Realtime Message, z.B. MIDI-Clock, und dann das zweite Datenbyte für Note-On, beide Messages werden vom Empfänger vollständig und korrekt erkannt, und der Running Status nach dieser Übertragung steht auf "Note On", da System Realtime Messages keinerlei Einfluss auf Running Status haben, und natürlich auch selber keinen Running Status nutzen können.

Eine System Realtime Message kann auch während einer System Common Message auftreten, dies wird wohl am Häufigsten bei SysEx-Messages der Fall sein, da diese möglicherweise relativ lange zum Übertragen brauchen, aber ein MIDI-Clock (0xf8) sofort durchkommen muss, da diese Message eben in Echtzeit (realtime) behandelt werden muss. Nach dieser Realtime-Message wird die Übertragung der SysEx-Message ganz normal fortgeführt.

Nun zu den einzelnen Message-Typen

=== 0x80 - Note Off ===

Wie oben beschrieben, besteht das Note-Off-Event nicht nur aus dem Byte 0x80, sondern aus dem Bereich 0x80 bis 0x8f, weil in den unteren 4 Bits der MIDI-Kanal codiert ist. Dies trifft für alle weiteren Voice Messages zu und wird daher nicht bei jeder Message neu erwähnt.

Das Note-Off Event kennt 2 Datenbytes als Parameter. Das erste ist die Notennummer von 0 bis 127, das zweite die Geschwindigkeit, in der die Taste losgelassen wird, auch Release Velocity genannt, ebenfalls im Wertebereich von 0 bis 127.

Note-Off teilt dem Empfänger mit, dass der Ton mit der angegebenen Note gestoppt werden soll. Im Prinzip ein "Gate Off", die Release-Phase der Hüllkurve setzt ein. Einzige Ausnahme von der sofortigen Behandlung des Note-Off Events ist die Verwendung eines Sustain Pedals. Ist dieses eingeschaltet, soll sich der Empfänger nur dieses Note-Off-Event an einem geeigneten Ort aufbewahren, bis das Sustain Pedal abgeschaltet wird, erst dann wird auch der Ton abgeschaltet. Dieses Verhalten ist aber vom Empfänger abhängig, und möglicherweise auch auf Patch-Ebene steuerbar, so macht es bei einem Klavierpatch sicherlich sinn, das Sustain-Pedal zu nutzen, bei einer Bassdrum aber eher nicht.

=== 0x90 - Note On ===

Das Gegenstück zu Note Off, hier wird dem Empfänger mitgeteilt, dass ein Ton zu spielen ist, also Gate eingeschaltet wird und ein Trigger abgesetzt wird. Als Parameter werden auch hier 2 Datenbytes übertragen - die Notennummer und die Anschlagsstärke, auch Velocity genannt. Wie üblich sind beide Datenbytes im Wertebereich 0 bis 127. Einen Sonderfall stellt aber die Velocity 0 dar. Wie oben bei Running Status beschrieben, stellt ein Note-On Event mit der Verlocity 0 eigentlich ein Note-Off Event dar. Entsprechend wird es dann auch als Note Off behandelt, die Logik mit dem Sustain Pedal greift auch hier, der einzige Unterschied zu einem echten Note Off ist das Fehlen der Release Velocity. Der Empfänger könnte hier einen Standardwert annehmen, sofern er überhaupt die Release Velocity auswertet.

=== 0xa0 - Aftertouch ===

Dieser Nachrichtentyp ist nicht der Aftertouch, wie ihn die meisten kennen, sondern der selten zu findende polyphone Aftertouch. Diese Message hat einen Bezug zu einer gespielten Note, daher wird dieses Event direkt von der zugehörigen Taste generiert, und nicht wie beim Channel Aftertouch vom gesamten Keyboard. Entsprechend kennt diese Message 2 Datenbytes, das erste ist die Notennummer, auf die sich der neue Druck bezieht, das zweite ist der Druck, der auf die Taste ausgeübt wird, im Wertebereich von 0 (sehr leicht) bis 127 (sehr stark).

=== 0xb0 - Control Change ===

Eine Control-Change-Nachricht gibt Informationen über einen Controller, dessen Wert sich geändert hat. Der Controller kann dabei so ziemlich alles sein, von einem einfachen Schalter, der nur 2 unterschiedliche Werte kennt, über ein Potentiometer als analoges Eingabegerät, ein Drehencoder als virtuell-analoges Eingabegerät, oder auch völlig obskure Geräte wie der Abstand der Hand zur Antenne bei einem Theremin-ähnlichem Eingabegerät. Bekannte Controller sind das Modwheel und die MIDI Volume, beides wird jeder schon einmal benutzt haben. Die vordefinierten Controllernummern werden später noch behandelt.

Die Nachricht beinhaltet neben dem Statusbyte auch 2 Datenbytes, das erste ist die Controllernummer, das zweite der Controllerwert, wieder beide im Bereich 0 bis 127. Negative Controllerwerte gibt es offiziell nicht, zu diesem Thema jedoch später mehr.

=== 0xc0 - Program Change ===

Dient zum Umschalten des Sounds bei Synthesizern, kann aber auch anderen Funktionen zugeordnet sein, z.B. die Controllerzuordnung bei einem MIDI-Controller. Generell wird hiermit ein Stück Konfiguration ausgewählt, sei es ein Patch, ein Preset, ein Program, wie auch immer es beim jeweiligen Gerät genannt wird.

Die Message verwendet nur ein Datenbyte, die Programmnummer, wieder im Bereich 0 bis 127. Dies muss keinen echten Zusammenhang mit der auf dem Display angezeigten Patchnummer des Gerätes haben, da die Hersteller die unterschiedlichsten Formen der Datstellung verwenden. Nur sehr wenige geben ihren Patches Nummern von 0 bis 127, häufiger gesehen ist der Bereich 1 bis 128, also ist die Anzeige auf dem Display 1 höher als die eigentlich übertragene Programmnummer. Andere Hersteller arbeiten nicht direkt mit dem Dezimalsystem, sondern kennen Patches von 11 bis 88, wobei jede der beiden Ziffern nur die Werte 1 bis 8 kennt, was insgesamt 64 Kombinationsmöglichkeiten entspricht. Wird also Program 0 angesteuert, entspricht dies dem Displaywert 11, Program 1 wäre 12, Program 8 wäre 21 bis hin zu Program 63, was dem Display 88 entspricht. Damit sind nur 64 verschiedene Programme möglich, was mit den anderen 64 gemacht wird, bleibt dem Gerätehersteller überlassen, entweder werden alle Werte >= 64 einfach ignoriert, oder sie erfüllen den gleichen Zweck wie die Werte 0 bis 63, also sind im gesamten Wertebereich alle Patches doppelt vorhanden, oder es kann damit zusätzlich noch eine Bank umgeschaltet werden, womit das Display vielleicht von A11 bis B88 geht, wobei A11-A88 die Programs 0 bis 63 sind, und B11-B88 die Programs 64 bis 127.

Wieder andere Geräte kennen die Patches 0 bis 99, hier werden dann Werte ab 100 möglicherweise ignoriert, das genaue Verhalten ist immer herstellerabhängig.

=== 0xd0 - Channel Pressure ===

Hier ist nun der Aftertouch, den jeder kennt, der Channel Aftertouch, offiziell in der MIDI-Sprache auch Channel Pressure genannt. Er verhält sich an für sich wie der oben erwähnte Aftertouch, gilt jedoch nicht pro Note, sondern für die gesamte Voice, also alle zur Zeit gespielten Noten. Dadurch, daß er damit keinen Notenwert übertragen muss, verwendet er auch nur ein Datenbyte, eben den Druck aufs Keyboard im Bereich von 0 (sehr leicht) bis 127 (sehr stark).

=== 0xe0 - Pitch Wheel ===

Hier kommt nun die erste Ausnahme aus der Welt der 7bit-Übertragung. Da ein Pitch Wheel eine möglichst hohe Auflösung haben sollte, ist dieser Controller als eigenständige Sonderfunktion definiert worden. Er verwendet 2 Datenbytes, die zusammen den 14bit-Wert ergeben. Dazu wird dieser 14bit-Wert in der Mitte geteilt, das erste Datenbyte stellt die Bits 6-0 dar, das zweite Datenbyte die Bits 13-7. Der Empfänger nimmt also das zweite Datenbyte, schiebt es 7 Bits nach links und heftet unten das erste Datenbyte an, um wieder einen 14bit-Wert zu bekommen.

Eine weitere Ausnahme stellt die Tatsache dar, dass das Pitch Wheel sowohl positive als auch negative Werte senden kann. Die Mittelstellung bedeutet dabei genau 0. Da negative Werte bei MIDI nicht vorgesehen wird, wird der Wert einfach von 0 bis 16383 gesendet, der Empfänger weiss aber, da es sich um das Pitch Wheel handelt, dass er von dem empfangenen Wert nochmal 8192 subtrahieren muss. Somit entsteht ein Wertebereich von -8192 bis +8191.

=== 0xf0 - SysEx Start ===

Nun kommen wir von den Voice Messages zu den System Common Message, und dabei auch sofort zu dem kompliziertesten Message-Typ. System Common Messages enthalten keinen MIDI-Kanal, darum gilt für alle folgenden Messages nicht obige Regel, dass die unteren 4 Bits der MIDI-Kanal sind, sondern bei allen Messages ab hier ist das komplette Statusbyte angegeben.

[[SysEx]] ist eine der Erweiterungsmöglichkeiten des MIDI-Protokolls. Hier kann man sich eigene Messages definieren, die darüber hinaus auch keine feste Datengrösse haben, sondern beliebig viele Datenbytes verwenden können, da es einen weiteren Status zum Beenden dieser Message gibt. Es werden also alle Bytes zwischen dem Status 0xf0 und dem abschliessenden Status 0xf7 als Daten einer SysEx-Message behandelt.

Damit es keine Kollisionen durch Wildwuchs in den übertragenen Daten gibt, und Hersteller 1 eine gut gemeinte Message implementiert "Schalte Displaybeleuchtung auf rot um", während Hersteller 2 genau die gleichen Daten verwendet, um "leite Selbstzerstörung ein" zu formulieren, was zu gewissen Komplikationen im Studio-Setup führen könnte, gibt es eine zentrale Verwaltung bei der [http://www.midi.org/ MMA], der MIDI Manufacturers Association, die jedem Hersteller eine eigene Kennung zuweist. Diese Liste kann auch jeder [http://www.midi.org/about-mma/mfr_id.shtml hier] anschauen.

Entsprechend ist es quasi Gesetz, dass diese Hersteller-Nummer direkt auf den Status 0xf0 folgt, um vorab eine Selektierung nach Hersteller vorzunehmen.

Schaut man sich die Herstellernummern (die bei der MMA nicht bis in alle Ewigkeit zurück zu reichen scheint, da es noch viel mehr reservierte Herstellernummern gibt, z.B. ist in der Liste Sequential oder Moog gar nicht zu finden) genauer an, erkennt man ein einfaches Muster:

Es fing an mit den Erfindern von MIDI, Sequential Circuits. Sie haben die Herstellernummer 1. Ab hier zählt es aufwärts, bis 0x18, EMU. Dann kommt 0x20, Bon Tempi, ein europäischer Hersteller, bis hin zu Waldorf, 0x3e, ebenfalls europäisch. Ab 0x40 wirds japanisch - Kawai hat diese ID, wie man auch bei der MMA nachlesen kann. Also sind die Hersteller-IDs an glatten Bereichsgrenzen (wenn man es hexadezimal liest) in Regionen unterteilt. Da zu erwarten war, dass 32 Hersteller pro Region knapp werden könnte, wenn die Verbreitung Computergesteuerter Musikinstrumente zunimmt, wurde ein Sonderfall eingeführt - ist das erste Byte nach dem Status 0xf0 ein 0x00, so handelt es sich um eine lange Hersteller-ID, die direkt auf die 0x00 folgt. Damit wurden zu dem Bereich der bisherigen 127 Hersteller nochmal weitere 16384 Hersteller oben drauf gelegt. Bei dieser langen Hersteller-ID erkennt man aber auch wieder das klassische Schema, 0x00 und 0x01 sind USA, 0x20 ist Europa, und ein Vertreter aus dem japanischen Raum mit langer Hersteller-ID ist auch als Beweis vorhanden - 0x40 ist wieder die japanische Region.

Nach diesem Abschweifen in die Zahlenspiele, die nur verdeutlichen sollen, dass Herstellernummern > 0 mit diesem einen Byte abgeschlossen sind, bei der Herstellernummer 0 aber nochmal 2 Bytes für die lange Herstellernummer folgen, geht es nun weiter.

Bisher haben wir also 0xf0 und die Herstellernummer, entweder in einem oder in 3 Bytes. Was nun danach kommt, bleibt voll und ganz dem Hersteller überlassen, er darf hier tun und lassen, was er will, sollte aber natürlich schon beim ersten Gerät sicher stellen, daß er auch noch ein zweites Gerät auf den Markt bringen kann, ohne Probleme mit seinen Messages vom ersten Gerät zu bekommen. Daher ist in den folgenden Bytes üblicherweise noch eine vom Hersteller vergebene Modellnummer vorhanden, diese kann ein Byte sein, wenn der Hersteller in seiner gesamten Existenz nur 128 verschiedene Geräte bauen möchte, oder auch 2 Bytes, wenn er mehr einplant. Natürlich kann er auch einen Wert als Sonderfunktion frei lassen, um später mal auf lange Modellnummern zu wechseln, wie es die MMA bei den Herstellernummer getan hat. Es gibt hier keine feste Definition.

Ausserdem ist möglicherweise noch eine weitere ID vorhanden, eine Gerätenummer. Diese sagt nichts über den Gerätetyp aus, sondern stellt eine weitere Identifikation dar, da es durchaus vorkommen kann, dass in einem Setup mehrere identische Geräte eines Herstellers vorhanden sind. Damit nicht alle diese Geräte gleichzeitig auf die Message reagieren, was in vielen Fällen unpraktisch sein könnte, gibt es noch die Geräte-ID. Diese ist in etwa zu vergleichen mit dem MIDI-Kanal, aber auch hier gibt es keine feste Definition, es hat sich aber eingebürgert, nur die Werte 0 bis 126 für Geräte-IDs zu verwenden, und die 127 als Spezial-ID für "an alle". Dadurch kann man sich z.B. 127 identische Soundmodule ins Rack (bzw. die Racks) packen, alle an einem MIDI-Kabel laufen lassen (unrealistisch, es geht um die Theorie :), und jedem Gerät aufgrund seiner ID gezielt seine ganz persönliche Konfiguration zuschieben, aber z.B. ein Firmware-Update auf Geräte-ID 127 loszuschicken, womit alle Geräte gleichzeitig ihr Firmware-Update durchziehen.

Übrigens gibt es auch spezielle Herstellernummern für Hobbyzwecke und Entwicklung. Der Hersteller 0x7d ist für Eigenbauten zu empfehlen, die aber niemals das eigene Setup verlassen sollten. Sobald etwas auf den Markt kommen soll, ist es notwendig, sich bei der MMA eine eigene Herstellernummer registrieren zu lassen.

Darüber hinaus gibt es noch 2 Hersteller-IDs für Sonderfälle, also Erweiterungen des MIDI-Standards, die herstellerunabhängig sind und ihrerseits auch wieder in separaten Standards festgeschrieben sind. Hierzu gibt es die Hersteller-IDs 0x7e und 0x7f. Bei diesen Hersteller-IDs ist es auch fest definiert, dass als nöchstes Byte die Geräte-ID kommt. Da es keine Modell-ID geben wird, weil die Messages ja herstellerunabhängig und damit auch geräteunabhängig sind, reicht diese Geräte-ID, quasi der Kanal, auch aus, um gezielt bis zu 127 Geräte zu adressieren. 127? Ja, nicht 128, weil die 127, wie oben schon beschrieben, bedeutet, daß das Gerät auf jeden Fall auf diese Message hören soll, unabhängig von der konfigurierten Geräte-ID.

Zu den Einsatzfällen dieser IDs gehören die GM-Spezifikation, der Sample Dump Standard und einige weitere nützliche Helferlein, die dem Musiker, der mit der ganzen EDV so wenig wie möglich zu tun haben möchte, das Leben etwas einfacher machen. Stichwort "Scanne MIDI-Bus" - hierfür gibt es einen Identity Request. Allerdings ist der bei vielen Geräten, vor allem älteren Modellen, nicht implementiert, weshalb hier auch gerne andere Mechanismen verwendet werden.

So haben wir also nun ausgiebig das Thema SysEx-Message behandelt, ohne wirklich sehr viel darüber zu wissen. Schauen wir die Erkenntnisse einmal kurz anhand einer Message an:

f0 00 20 32 15 01 20 00 00 24 72 65 76 20 52 31 f7
| | | | | | | --------------------------- |
| | | | | | | | + Ende der SysEx-Message
| | | | | | | + Daten
| | | | | | + Kommando ans Gerät "Konfigurationsdaten"
| | | | | + Geräte-ID 1
| | | | + Modell - BCR2000
| | +--+ Hersteller - Behringer
| + Verwende lange Hersteller-ID
+ Start der SysEx-Message

Dies sollte alle beschriebenen Sachverhalte an SysEx-Messages ausreichend verdeutlichen. Das grössere Thema Datencodierung wird später noch im Detail behandelt.

=== 0xf1 - MTC Quarter Frame ===

Diese Message gehört in die Kategorie der MTC-Messages, die später beschrieben werden. Ihr folgt ein Datenbyte, welches den Time Code darstellt.

=== 0xf2 - Song Position Pointer ===

Für MIDI-File-Player oder Sequencer steuert dieses Kommando die Position im Song. Der Wert wird dabei in 2 Datenbytes übertragen, die sich wie beim Pitch Wheel zu einem 14bit-Wert zusammen setzen. Die Einheit des Wertes sind MIDI Beats, die 1/16tel-Noten entsprechen.

=== 0xf3 - Song Select ===

Dies ist vergleichbar mit dem Program Change, dient aber der Auswahl des Songs bei einem MIDI-File-Player oder Sequencer. Dem Status folgt ein Datenbyte, welches die Songnummer im Bereich 0 bis 127 angibt.

=== 0xf4 - undefiniert ===

Dieses Status-Byte ist nicht definiert. Einige Hersteller verwenden die nicht definierten Message-Typen für eigene Funktionen, bei denen es nicht erwünscht ist, große Datenmengen wie bei SysEx zu übertragen. Insbesondere, wenn diese Statusbytes für interne Kommunikation, z.B. zwischen einem MIDI-Interface und einem Rechner verwendet werden, und nicht an externe MIDI-Geräte geschickt werden, spricht nichts gegen eine solche Verwendung. Ansonsten sind die Reaktionen auf diesen Status undefiniert und daher sollte dieser Status auch nicht in der freien Wildbahn auftauchen. Da die Funktion dieses Status undefiniert ist, gibt es auch keine Aussage, wie viele Datenbytes dahinter folgen dürfen. Da aber dieses Statusbyte offiziell sowieso niemals auftauchen wird, weil es ja undefiniert ist, ist dieser Informationsmangel auch zu vernachlässigen. Bei Empfang eines undefinierten Statusbytes kann aber auch nichts passieren, das Gerät sollte diesen Status ignorieren, ausserdem wird dadurch der Running Status zurück gesetzt, womit es gleichgültig ist, wie viele Datenbytes auf diesen Status folgen - für den Empfänger ist es ein undefinierter Status, also werden alle Datenbytes ignoriert, bis wieder ein gültiger Status kommt.

=== 0xf5 - undefiniert ===

Siehe 0xf4

=== 0xf6 - Tune Request ===

Es gibt in der Tat ein dediziertes Kommando, welches einen Synthesizer dazu veranlassen sollte, seine automatische Stimmfunktion zu starten. Wie viele Geräte dieses Feature wirklich implementiert haben, ist ungewiss, es ist auch keine Funktion, die bei den üblichen MIDI-Tools in Form eines deutlich sichtbaren "TUNE!"-Buttons sofort aufzufinden ist. Dennoch kann man sie natürlich mal an seinen Gerätepark schicken und schauen, ob das eine oder andere Gerät drauf reagiert. Ein Datenbyte benötigt dieser Status nicht.

=== 0xf7 - SysEx End ===

Dieser Status beendet eine SysEx-Übertragung, siehe auch 0xf0.

=== 0xf8 - MIDI Clock ===

Hier kommt nun die erste System Realtime Message. Ab hier folgen nur noch Realtime Messages, die entsprechend auch keine Datenbytes verwenden, da sie einen Running Status oder sonstige Übertragungen nicht beeinträchtigen und jederzeit "dazwischengeworfen" werden dürfen.

MIDI Clock ist eine Message, die von einem Master in regelmässigen Abständen verschickt wird. Sind mehrere Geräte zusammen geschaltet, sollte nur ein Gerät diese Messages verschicken, dieses ist dann der Master, meistens ein Sequencer. Die anderen Geräte, die Slaves, können sich anhand dieser Clock-Messages auf den Master synchronisieren. Somit sind als Slaves weitere Sequencer oder z.B. Arpeggiatoren einsetzbar. Damit das unter den Herstellern auch problemlos funktioniert, ist fest definiert, welchen Zeitabstand der Clock zu bedeuten hat. Pro Viertelnote gibt es exakt 24 Clocks. Das bedeutet, 6 Clocks sind eine 1/16tel-Note, 96 Clocks ein kompletter Takt.

=== 0xf9 - MIDI Tick ===

Ähnlich wie beim MIDI Clock dient diese Message der Synchronisation. Entgegen dem MIDI Clock ist sie jedoch nicht abhängig von einer Geschwindigkeit, die an einem Sequencer eingestellt wurde, steht damit nicht in Relation zu Notenlängen, sondern ihre Zeitbasis ist einfach die Zeit. Ein MIDI Tick wird alle 10ms geschickt, sofern ein Sender diese Message überhaupt schickt.
MIDI Tick wird in Verbindung mit MIDI File Playern zusammen mit den Messages Song Position Pointer und einigen nachstehenden Messages zur Synchronisation verwendet.

=== 0xfa - MIDI Start ===

Für MIDI-File-Player oder Sequencer bedeutet dieses Event "Fange bei Song Position 0 an, abzuspielen".

=== 0xfb - MIDI Continue ===

Startet ebenfalls die Wiedergabe eines Songs oder einer Sequenz, aber nicht an der Position 0, sondern an der aktuellen Position, die vorher möglicherweise durch Song Position Pointer gesetzt wurde.

=== 0xfc - MIDI Stop ===

Stoppt die Wiedergabe des Songs oder der Sequenz.

=== 0xfd - undefiniert ===

Wie 0xf4 und 0xf5 ist dieser Status nicht definiert und taucht daher üblicherweise auch nirgendwo auf. Da er sich aber unter den System Realtime Messages tummelt, kann sicher gesagt werden, dass er keine Datenbytes verwendet, falls er doch einmal irgendwo auftauchen sollte.

=== 0xfe - Active Sense ===

Ein gerne gehasstes Feature von MIDI, was eigentlich vom Gedanken her gar nicht so unsinnig ist. Nicht viele Geräte übertragen diese Message, sie wird auch gerne als Busblockade angesehen. Dabei handelt es sich nur um ein einzelnes Byte, welches auch eher selten übertragen wird, und daher schon eine nicht unerhebliche Anzahl Geräte notwendig sind, die alle parallel auf das gleiche Kabel ballern, um eben dieses Kabel dicht zu machen. Active Sense wird, wenn überhaupt, mindestens einmal innerhalb von 300ms gesendet, wenn innerhalb dieser Zeit keine anderen Daten gesendet wurde. Der Status dient also der Erkennung der Anwesenheit eines Gerätes. Man stelle sich folgendes einfaches Szenario vor:

Ein Masterkeyboard ist via MIDI an einen Klangerzeuger angeschlossen. Und das schon ausreichend lange, dass man da auch öfter mal Staub gewischt hat, und sich vielleicht der Stecker am MIDI-Out am Keyboard langsam etwas gelockert hat. Nun spielt man so eifrig vor sich hin, der Stecker wird ordentlich erschüttert (Nahaufnahme, wie in den Filmen, wo der Zuschauer schon weiss, dass gleich was passiert, aber das Opfer noch nicht), und wenn man gerade mit sämtlichen 10 Fingern mal so richtig in die Tasten haut, fliegt, natürlich nach ordnungsgemässer Übertragung aller 10 Note-On-Events, der Stecker endgültig raus. Ohne Running Status darf man nun in einer möglicherweise nicht unerheblichen Geräuschkulisse erstmal den Stecker wieder suchen, weil das Abschalten des Klangerzeugers vielleicht den Edit Buffer in den Tod reisst, in dem man sich gerade aufwändig einen tollen Sound gebaut hat. Also gut, Lautstärke runter drehen, Stecker suchen und wieder einstecken. Danach Lautstärke wieder rauf, alle Töne, die gerade gespielt werden, nochmal anschlagen, und hoffen, dass der Note-Off, der aus dem Loslassen resultiert, auch wirklich die Töne im Klangerzeuger wieder abschaltet. Es gibt nämlich auch Geräte, die den gleichen Ton mehrmals spielen können und für jeden Note-On eines Tones auch einen Note-Off haben wollen, bis wieder ruhe ist.

Bleibt also noch der Controller "All Notes Off", zu dem wir später kommen.

So, und die Moral von der Geschicht - Mit Active Sense wär das nicht passiert. Ausgehend davon, dass alles von den Herstellern richtig implementiert wurde, hätte der Klangerzeuger nämlich gemerkt, dass er Active Sense Messages bekommt, und wenn er eine gesehen hat, kann er auch davon ausgehen, dass weitere kommen werden. Also schaltet er seinen Sicherheitsmechanismus ein. Dieser ist einfach ein Countdown. Wenn innerhalb einer Sekunde keine Daten empfangen werden, schaltet er alle spielenden Noten aus. Da in den Ruhephasen, wo es keine Daten zu übertragen gibt, nach spätestens 300ms ein Active Sense kommt, ist gewährleistet, dass die Sekunde nicht ohne Daten verstreichen wird. Fällt dann doch der Stecker raus, kommt der Active Sense auch nicht mehr an - das Gerät kann die Noten abschalten.

Wenn ein Gerät seit dem Einschalten keine einzige Active Sense Message empfangen hat, bleibt der Sicherheitsmechanismus natürlich deaktiviert, weil dann sein Sender keinen Running Status abschickt.

Somit ist das Mysterium um diesen scheinbar nutzlosen Message-Typ auch geklärt. Richtig eingesetzt könnte er einige Unannehmlichkeiten einschränken, die allerdings in der oben beschriebenen Form wohl auch eher selten vorkommen werden.

=== 0xff - Reset ===

Der Name ist Programm - es gibt ernsthaft eine MIDI-Message, die dazu dient, das Gerät zu resetten. Und sie hat keine ID und keinen Channel, resettet also gleich alle Geräte am MIDI-Kabel (oder je nach Routing auch an mehreren Kabeln).

Dieser Status ist an für sich in der Realtime-Kategorie mehr als Fehl am Platz. Wir haben oben gelernt, dass Realtime Messages den Running Status nicht unterbrechen. Nehmen wir an, es läuft eine SysEx-Übertragung, und mitten drin, aus heitetem Himmel, kommt die Realtime-Message "Reset". Von irgendeinem Gerät, was über einen Merger mit dran hängt. Ohne Kenntnis des Senders der SysEx-Nachricht. Der Empfänger tut, wie ihm befohlen, Resettet, wodurch der Running Status natürlich verloren geht, geschweige denn von der laufenden SysEx-Übertragung, die damit auch gewaltsam beendet wurde. Sehr blöd, wenn nun der Sender der SysEx-Message auf eine Quittung des Empfängers wartet, und sich davon auch nicht durch ein Bedienelement (ausser dem Ein/Aus-Schalter) abbringen lässt.

Abgesehen von dieser etwas unsinnig erscheinenden Tatsache ist die Definition des Kommandos genau "setze das Gerät in einen Zustand zurück, der dem nach dem Einschalten entspricht".

== Viele Wege, die Daten zu verpacken ==

Daten sind nicht immer in 7bit-Werte zu verpacken. Ein Firmware-Update verwendet z.B. ziemlich sicher 8bit-Werte, diese können sogar Teile von 16 oder 32bit-Werten sein. Vermutlich hat noch keiner etwas von einer 7bit-CPU oder einer 14bit-CPU gehört, es gibt sie dann doch eher in Ausführungen mit 8bit, 16bit, 32bit und auch 64bit, mal abgesehen von etwas aus der Mode gekommenen 4bit-CPUs und einigen Exoten der Vergangenheit mit 36bit oder ähnlich Krummen Daten.

Also müssen größere Werte sinnvoll in MIDI-Datenbytes verpackt werden, die zwangsläufig nur 7 Bit groß sind, weil das oberste Bit ja für die Unterscheidung zwischen Statusbyte und Datenbyte verwendet wird.

Nun gibt es viele verschiedene Strategien, wie diese Verpackung genau aussieht. Einige Varianten zielen dabei auf möglichst platzsparende Übertragung ab, weil die Messages entweder möglichst kurz bleiben sollen, oder ausreichend große Datenmengen übertragen werden sollen, bei denen sich Varianten, die die CPU weniger belasten, als große Verschwendung darstellen, die sich direkt auf die Dauer der Übertragung auswirkt.

Generell funktioniert also das Verpacken der Daten durch Umsortierung der Bits. Die Werte werden aufgeteilt in mehrere kleine Portionen, die alle maximal 7 Bits gross sind, und dann in mehreren Datenbytes verschickt. Wenn es dann an ganze Patches geht, wo die Breite der Werte sicherlich schwankt, kann das sogar so weit getrieben werden, dass alle Werte zusammen nur noch eine riesengrosse binäre Zahl darstellen, indem sie aneinender gehängt werden, und diese riesige Zahl in 7 Bit breite Pakete zerhackt wird.

Die gängigen Techniken werden nun in den folgenden Abschnitten beschrieben

=== 14bit-Werte ===

Wie schon weiter oben beschrieben, sind 14bit-Werte relativ häufig, gerade an Stellen, wo entweder die Auflösung oder einfach der Wertebereich mit 7 Bits nicht erreicht werden kann. Hierbei fällt die Teilung relativ einfach, weil sich 14 Bits sehr schön in 2 gleiche Teile zu 7 Bits zerlegen lassen. Fangen wir ein mal mit ein wenig Binärmathematik an, ausgehend von dem Beispielwert 0x3456:

0x3456 = 0011010001010110 in Binär
= 00110100 01010110 die beiden Bytes des Wertes, wie der Computer ihn verarbeitet
= 00 1101000 1010110 die Aufteilung in maximal 7 Bit große Pakete

Bei der Aufteilung dieser 16bit-Zahl bekommen wir, wenn wir auf 7 Bit Paketgröße umstellen, natürlich 3 Pakete, wovon eines nur 2 Bits gross ist. Da wir die 16bit-Zahl aber nur zu 14bit nutzen, können wir die obersten beiden Bits einfach weglassen und bekommen dadurch die beiden 7bit-Pakete.

In welcher Reihenfolge diese beiden Datenbytes nun übertragen werden, bleibt der Implementierung überlassen. Fest vorgegeben ist dies bei den oben erwähnten MIDI-Messages wie Pitch Bender und Song Position Pointer, hier wird erst das niedrige Byte, also Bits 6-0, danach das höhere Byte, Bits 13-7, gesendet. Schweift man nun ab in die EDV, wird diese Reihenfolge auch als "Little Endian" bezeichnet. In genau dieser Reihenfolge speichern z.B. die Intel-CPUs in den PCs ihre Zahlen im Speicher ab. Bei 32bit-Zahlen sind es entsprechend 4 Bytes, das erste enthält die Bits 7-0, das nächste die Bits 8-15 und so weiter. Das Gegenteil dazu wäre "Big Endian", wie es z.B. von den PowerPC-CPUs der bisherigen Macs und auch der 68000er-Serie der Macs vor den bisherigen Macs verwendet wird. Damit werden vielleicht auch die Probleme deutlich, die der Umstieg von Apple auf Intel-CPUs so mit sich bringen könnte :)

Zurück zum Thema - die Reihenfolge könnte ein Hersteller genau von der Arbeitsweise seiner im Gerät eingesetzten CPU abhängig machen. Ist es für ihn vorteilhafter, erst das höhere Byte, danach das niedrigere zu erhalten, weil er mit einer Big Endian CPU arbeitet, hat er es vielleicht so definiert. Wie das Gerät die Daten erwartet, steht üblicherweise in der MIDI Implementation zum Gerät beschrieben, die aber leider nicht jeder Hersteller mitliefert.

=== 8bit-Werte ===

Da ein Byte genau 8 Bits hat, kann es durchaus vorkommen, dass Daten 8 Bits verwenden. Hier gibt es 2 gängige Varianten, ein Byte mit 8 Bits in 2 Bytes mit 7 Bits zu zerlegen. Die 7:1-Variante, wobei ein Paket 7 Bits enthält, das andere 1 Bit, und die 4:4-Variante, wo die 8 Bits in 2 Nibbles, also 4bit-Werte zerlegt werden. Letztere ist kein größeres rechnerisches Problem, der Wert 0xab wird z.B. in 0xa und 0xb zerlegt, welches der beiden Datenbytes zuerst kommt, liegt in der Entscheidung des Herstellers.

Bei der 7:1-Variante wird es etwas komplizierter, weil es hierfür 2 Varianten gibt es kann ja auch 1:7 aufgeteilt werden, wonach dann noch die Reihenfolge hinzu kommt, in der die beiden Teile gesendet werden, was insgesamt 4 Möglichkeiten ergibt, dieses eine Byte zu versenden. Nimmt man die beiden Nibble-Varianten hinzu, gibt es also 6 Möglichkeiten, diese Bytes zu versenden:

0xab = 10101011 binär
= 1010 1011 bei der Aufteilung in Nibbles, erst das obere, dann das untere
= 1011 1010 bei der Aufteilung in Nibbles, erst das untere, dann das obere
= 1 0101011 bei der 1:7 Aufteilung, erst der obere Teil, dann der untere
= 1 1010101 bei der 1:7-Aufteilung, erst der untere Teil, dann der obere
= 1010101 1 bei der 7:1-Aufteilung, erst der obere Teil, dann der untere
= 0101011 1 bei der 7:1-Aufteilung, erst der untere Teil, dann der obere

Natürlich könnte man auch ganz abwegige Aufteilungen wie 3:5 verwenden, diese sind jedoch eher unüblich, da sie den Rechenaufwand zum zerlegen und wieder zusammensetzen der Daten unnötig vergrößern würden.

=== Datenblöcke mit mehreren 8bit-Werten ===

Hier kennt die Vielfalt der Datenverpackung nun keine Grenzen mehr. Man könnte jedes Byte wie oben bei den 8bit-Werten beschrieben, verpacken. Damit würde jedes zweite übertragene Byte aber 6 ungenutze Bits übertragen. Daher wird bei Datenblöcken üblicherweise anders gearbeitet. Gehen wir einmal von 4 Bytes aus, was z.B. einer 32bit-Zahl entspricht, nehmen wir mal 3 Milliarden, um mal wieder dezimale Zahlen zu verwenden:

3000000000 = 0xb2d05e00, oder in 4 Bytes nach Big Endian 0xb2, 0xd0, 0x5e, 0x00

Ausgehend davon, dass wir die Leitungskapazität so gut wie möglich nutzen wollen, gibt es nun 2 gängige Aufteilungen. Die eine nimmt diese komplette 32bit-Zahl und teilt sie in 7bit-Blöcke auf:

0xb2d05e00 = 10110010110100000101111000000000 = 1011001 0110100 0001011 1100000 0000

Das Resultat sind also 5 MIDI Datenbytes, die zu übertragen sind. Hierbei haben wir die Zerlegung jetzt oben angefangen, man kann sie auch unten anfangen und erhält

0xb2d05e00 = 10110010110100000101111000000000 = 1011 0010110 1000001 0111100 0000000

Wiederum können diese 5 Bytes nun vorwärts oder rückwärts geschickt werden.

Eine andere gängige Technik ist es, die Bytes zu "köpfen", also die von jedem Byte das oberste Bit abzuschneiden und all diese Bits zu sammeln. Etwa auf diese Art:

0xb2d05e00 = 10110010110100000101111000000000
= 0110010 1010000 1011110 0000000 = 0x32 0x50 0x5e 0x00
+ 1 1 0 0 = 1100 = 0x0c

Wieder bekommen wir 5 Bytes heraus, die wieder in einer theoretisch beliebigen Reihenfolge übertragen werden können. Diese Codierung wird gerne für echte binäre Daten wie Firmware-Images verwendet. Dabei ist nicht zwangsweise das oberste Bit gekappt, es könnte genau so gut das unterste Bit sein, ausserdem ist die Reihenfolge der eingesammelten einzelnen Bits auch Sache der Implementierung, sie könnten auch "rückwärts" in den Korb geworfen werden, und hinzu kommt noch bei der Reihenfolge, dass die gekappten Bytes zwar meistens in einer definierten Reihenfolge, also vorwärts oder rückwärts, gesendet werden, aber das Byte mit den gekappten Bits entweder davor oder danach gesendet werden kann.

Wenn man nun etwas nachrechnet, kann man diese Komprimierung so weit treiben, dass man die Bandbreite optimal ausnutzt, wenn man mit Blöcken zu 7 Bytes arbeitet. 7 Bytes sind insgesamt 56 Bits, teilt man diese in 7bit-Werte auf, bekommt man 8 Bytes (zu 7 Bits) als Ausgabe. Damit wird kein einziges Bit verschenkt.

=== Gemischte Datentypen ===

Was häufig bei Patch-Daten vorkommt, sind viele verschiedene Werte, die auch unterschiedliche Wertebereicht haben können. So ist vielleicht ein Filter-Cutoff ein 9bit-Wert, ein VCA-Level ein 4bit-Wert, lassen wir mal die Vorzeichen noch ausser Acht, haben wir auf jeden Fall viele verschiedene Werte in den unterschiedlichsten Längen. Die einfachste Methode, diese zu verpacken, wäre die Bildung einer riesengrossen binären Zahl und deren Aufteilung in 7bit-Pakete. Also die 9 Bits mit den 4 Bits zusammen kleben, wir erhalten 13 Bits. Und diesen Wert können wir schon wieder als 14bit-Wert interpretieren und in 2 7bit-Hälften verpacken.

Oft wird hier aber auch die Sortierung der Daten mit einbezogen. Bildet man eine riesengrosse Binärzahl, muss man möglicherweise sowohl auf Sende- als auch auf Empfangsseite eine ganze Menge Bits herumschieben, damit sie an den richtigen Positionen innerhalb der Bytes oder auch 16bit- oder 32bit-Wörtern liegen. Daher kann eine trickreiche Sortierung der Daten hier auch einen gewissen Gewinn bringen. CPUs ist es oft möglich, die beiden Nibbles eines Bytes in einem Befehl zu vertauschen. Daher bietet es sich natürlich insbesondere an, 4bit-Werte zusammen mit 3bit-Werten in ein 7bit-MIDI-Datenbyte zu stecken. Und es gibt ja auch 1bit-Werte, z.B. eine Schalterfunktion wie "VCO Sync an/aus". Diese einzelnen Bits kann man dann noch in entstehende Lücken hineinstecken, da sich einzelne Bits oft auch von den CPUs sehr schnell ansteuern lassen.

Nun ist hoffentlich genug Verwirrung gestiftet, um klar zu machen, dass gemischte Daten, wie sie eben bei kompletten Patches vorkommen können, auf jeden Fall ein intensives Studium der Hersteller-Dokumentation und ein gutes Verständnis für [[Bits und Bytes]] voraussetzen, da es hier keine generellen Regeln mehr gibt.

== Darstellung negativer Zahlen und Tricks für Controllerboxen ==

Wie schon in [[Bits und Bytes]] beschrieben, gibt es mehrere Varianten, negative Zahlen im Computer darzustellen. Und leider verwenden die Hersteller auch alle diese Möglichkeiten, insbesondere bei [[SysEx]], wo sie nicht unbedingt Rücksicht auf andere nehmen müssen, und daher sehr nah am Format arbeiten, wie die CPU im Gerät die Daten selber verarbeitet.

Leichtes Spiel haben wir mit Controllern, die einfach einen Offset verwenden. Der Pitchbender ist solch ein Beispiel, sein 14bit-Wertebereich langt von 0 bis 16383, und um den Wert zu nutzen, zieht das Gerät einfach die Mitte, 8192, davon ab und bekommt so seine negativen und positiven Zahlen. Der Controller, der den Pitchbender sendet, zeigt aber möglicherweise 0 bis 16383 an, weil er von negativen Zahlen nichts wissen will. Das ist dann aber eher ein Schönheitsfehler.

Und genau mit solchen Schönheitsfehlern können wir auch weiter arbeiten. Was mit 14bit funktioniert, geht natürlich auch mit 7bit ganz problemlos. Ein Controller, dessen Wertebereich von 0-127 geht, kann seinen Nullpunkt ebenfalls in der Mitte haben, also bei 64. Der Controller schickt 0-127, das Gerät zieht 64 ab und bekommt den Wertebereich -64 bis 63.

Aber was, wenn das Gerät mit "echten" negativen Zahlen arbeitet? Wir wissen, dass bei vorzeichenbehafteten Zahlen im Computer immer das oberste Bit entscheidet, ob die Zahl negativ oder positiv ist. Dies ist völlig unabhängig davon, ob die Zahl nun 32, 16, 14, 7 oder 5 Bits groß ist. Ist sie vorzeichenbehaftet, ist das oberste Bit das Vorzeichen. Schauen wir also einen 7bit-Controller mit Vorzeichen einmal in binär genauer an:

-64 = 1000000
-63 = 1000001
-62 = 1000010
...
-1 = 1111111
0 = 0000000
1 = 0000001
...
62 = 1111110
63 = 1111111

So sieht das also intern im Computer aus. Die Software weiss, dass die Zahlen vorzeichenbehaftet sind, und kann entsprechend damit arbeiten. Aber wir haben es doch sehr schwer, einen MIDI-Controller mit diesem Format zu bestücken, wenn er es nicht von sich aus unterstützt, seine Firmware also die Fähigkeit besitzt, mit negativen Zahlen umzugehen.

Da gibts aber einen relativ einfachen Trick, der zumindest mit den [[B-Control]]-Boxen von [[Behringer]] zu realisieren ist. Diesen Controllern ist es erst einmal egal, ob ein Controller 7bit oder 14bit breit ist, man konfiguriert einfach einen Wertebereich. Natürlich gilt dies nicht für die Konfiguration für Program Changes und Controller, wie man sie offiziell konfigurieren kann, hier wird auch eine solche Zahlendarstellung kaum eingesetzt, sondern es geht nur, wenn man vollen Zugriff auf die Zusammenstellung seiner MIDI-Message hat, was beim B-Control mit dem '''.tx'''-Parameter möglich ist.

Der Controller braucht einfach die Möglichkeit, auf bestimmte Bits innerhalb seines Wertes zugreifen zu können, und die Möglichkeit, die beiden Endwerte des Controllers frei zu setzen. Dann können wir nämlich einfach mit folgender Überlegung arbeiten:

Schauen wir den Wert für -64 an, er lautet binär 1000000, das ist, wenn wir es als vorzeichenlose Zahl interpretieren, einfach 64. Fein, es ist auch die kleinste Zahl, die wir benötigen, also konfigurieren wir 64 als Minimalwert für den Controller. Gehen wir nun ganz naiv an die Sache dran - die Differenz zwischen den beiden Werten, die wir übertragen wollen, ist genau 127: 63 - -64 = 127. Ohne viel zu denken, konfigurieren wir also den Maximalwert des Controllers ebenfalls mit dieser Differenz. Der Minimalwert ist 64, addieren wir 127, bekommen wir 191. Also rein damit, Maximalwert ist 191.

Jetzt moment... 191 ist ja viel zu groß, können wir über MIDI ja gar nicht übertragen, da wir nur Werte unter 128 übertragen können. Also kommt nun des Tricks zweiter Teil - wir übertragen nur die Bits 6-0, was beim B-Control z.B. mit dem Schlüsselwort '''val0.6''' zu erreichen ist. Das oberste Bit lassen wir dabei unter den Tisch fallen, wir übertragen es überhaupt nicht. Schauen wir also nun die generierten Werte einmal genauer an:

64 = 01000000 = 0 1000000
65 = 01000001 = 0 1000001
66 = 01000010 = 0 1000010
...
127 = 01111111 = 0 1111111
128 = 10000000 = 1 0000000
129 = 10000001 = 1 0000001
...
190 = 11111110 = 1 1111110
191 = 11111111 = 1 1111111

Die erste Spalte sind die dezimalen Werte, die der Controller generiert und das Display vom B-Control auch anzeigt, wenn man es ihm nicht verbietet. Die zweite Spalte sind die selben Werte in binärer Darstellung. Und die dritte Spalte ist ebenfalls die binäre Darstellung, der übersicht halber ist hier aber das höchste Bit, welches wir nicht übertragen, separat gestellt. Wir übertragen nur die 7 Bits ganz rechts. Wenn wir diese Zahlen mit den Zahlen oben vergleichen, die das Gerät erwartet, erkennen wir einen 100%igen Treffer.

Der B-Control hat auch den Vorteil, dass seine Anzeige im LED-Ring grundzätzlich von Minimalwert bis Maximalwert geht, gleichgültig, in welchem Bereich diese beiden Werte liegen. Also einfach das Display abschalten, damit die störenden um 128 daneben liegenden Werte nicht angezeigt werden, der LED-Ring zeigt die richtige Position an, das Gerät empfängt die Daten so, wie es sie haben möchte, schon kann man die vorzeichenbehafteten Zahlen nach dieser Methode auch sauber übertragen.

Als kleiner Wermutstropfen bleibt aber zu sagen, dass dies nur in gewissen Wertebereichen möglich ist. Diesen Trick können wir bei 14bit-Controllern nicht anwenden, weil dazu 15bit Wertebereich am Controller notwendig wären, was aber nicht geht. Eine mögliche Konfiguration wäre noch ein 8bit-Controller, benötigt einen 9bit-Wertebereich, und wir können 8bit-Werte sauber senden und dabei das neunte Bit weglassen, die nächste Stufe wäre dann ein 12bit-Controller mit Vorzeichen, benötigt 13bit Wertebereich, und 12 Bits kann man über die Nibbles auch sauber isolieren.

Mit geschickten Konfigurationen kann man sich hier übrigens auch Sonderkonstellationen zusammen bauen. Das Beispiel für einen 5bit-Controller mit Vorzeichen wäre relativ einfach. Wertebereich -16 bis +15, -16 ist binär 10000, ohne Vorzeichen sind das 16, +15 ist binär 01111, wir nehmen unsere "Dummy-1" mit hinzu, 101111, ergibt 47, die Differenz passt, 31, aber halt. Geht so ja nicht, weil die Dummy-1 mit übertragen werden würde, weil sie mit in den zu übertragenen 7 Bits liegt. Hätten wir das Beispiel mit einer 4bit-Zahl mit Vorzeichen gestartet, hätten wir hier ein Nibble verwenden können, um nur die Bits 3-0 zu übertragen.

Leider hilft es auch nichts, die Dummy-Bits aus dem sichtbaren Bereich auszulagern, weil rein binär nach dem Wert 11111 grundsätzlich 100000 erscheinen wird, womit innerhalb des 7bit-Wertes ein Bit erscheint, was da nicht hin gehört, der Wert ist nicht 0, wie er sein sollte.

Das sollte aber niemanden daran hindern, es auszuprobieren. Wenn die Bits 6 und 5 an der Stelle, wo der 5bit-Wert mit Vorzeichen reinkommt, ungenutzt sind, und nirgends steht, dass die unbedingt 0 sein müssen, hilft ausprobieren weiter. Möglicherweise werden diese beiden Bits vom Gerät einfach ignoriert, so daß unser Trick dennoch funktionieren kann.

[[category:Tricks]]

MIDI Format

2007-01-07T16:27:05Z

MIK: /* Darstellung negativer Zahlen und Tricks für Controllerboxen */

MIDI Format

2007-01-07T16:22:06Z

MIK: /* Darstellung negativer Zahlen und Tricks für Controllerboxen */

MIDI Format

2007-01-07T15:48:10Z

MIK: /* Viele Wege, die Daten zu verpacken */

MIDI Format

2007-01-07T14:48:38Z

MIK:

MIDI Format

2007-01-07T14:43:35Z

MIK:

MIDI Format

2007-01-07T13:49:48Z

MIK:

B-Control-Tokenreferenz

2007-01-07T12:01:00Z

MIK: /* Argumente des tx-Parameters */

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
:Funktion bisher noch ungeklärt.

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

[[category:Tricks]]

B-Control-Tokenreferenz

2007-01-07T12:00:28Z

MIK: /* Argumente des tx-Parameters */

B-Control-Tokenreferenz

2007-01-07T11:49:50Z

MIK: /* Argumente des tx-Parameters */

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
:Funktion bisher noch ungeklärt.

== 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
:Funktion noch nicht genauer ermittelt, möglicherweise lässt sich hier noch etwas am Timing der Message drehen.

B-Control-Tokenreferenz

2007-01-07T11:10:21Z

MIK:

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
:Funktion bisher noch ungeklärt.

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

;<arg> ntimes
:Funktion noch nicht genauer ermittelt, möglicherweise lässt sich hier noch etwas am Timing der Message drehen.

B-Control-Tokenreferenz

2007-01-07T11:02:56Z

MIK: /* Argumente des tx-Parameters */

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
:Funktion bisher noch ungeklärt.

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

;<arg> ntimes
:Funktion noch nicht genauer ermittelt, möglicherweise lässt sich hier noch etwas am Timing der Message drehen.

B-Control-Tokenreferenz

2007-01-07T09:44:07Z

MIK: /* $button <arg> */

B-Control-Tokenreferenz

2007-01-07T09:14:37Z

MIK:

B-Control-Tokenreferenz

2007-01-07T08:34:37Z

MIK: Tokenreferenz BCR2000/BCF2000

MIDI Format

2007-01-06T20:38:50Z

MIK:

MIDI-Grundlagen in Arbeit

B-Control-Tokenreferenz

2007-01-06T20:38:34Z

MIK:

B-Control Tokenreferenz in Arbeit

B-Control-Konfiguration

2007-01-06T20:37:47Z

MIK: /* Weitere nützliche Kommandos */

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 - 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. [http://www.midiox.com/ MIDI-OX], unter MacOS X [http://www.snoize.com/SysExLibrarian/ 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!

[[category:Tricks]]

B-Control-Konfiguration

2007-01-06T20:17:29Z

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

B-Control-Konfiguration

2007-01-06T20:16:13Z

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

Bits und Bytes

2007-01-06T19:16:15Z

MIK:

Um die genauen Abläufe innerhalb des MIDI-Protokolls zu verstehen, und vor allem, um zu wissen, auf welche verschiedenen Arten Zahlen in der digitalen Welt dargestellt werden können, sollen hier einige Grundlagen erläutert werden, um dieses Wissen aufzubauen.

== Digitale Darstellung von Werten im Computer ==

Digital ist abgeleitet von dem lateinischen Wort "Digitus", der Finger, da nicht nur früher, sondern auch heute in Abwesenheit eines Taschrechners gelegentlich die Finger zum Rechnen herangezogen werden. Und auch, wenn Finger an für sich analoge Gerätschaften sind, geht es hier um die digitale Nutzung "an" oder "aus".

Einen Unterschied gibt es aber zwischen dem Menschen un dem Computern bei der Nutzung der Finger zum Zählen. Während unsere Finger zum Zählen alle die gleiche Wertigkeit haben, also 4 erhobene Finger den Wert 4 darstellen, geht der Computer hier sparsamer mit seinen Finger, die wir in Zukunft wieder ordentlich "Bits" nennen werden, um. Bits werden zusammengefasst zu Bytes (also der Hand, wenn man so will). Ein Byte hat 8 Bits. Um hier jetzt nicht nur von 0 bis 8 zählen zu können, hat jedes Bit in diesem Byte eine besondere Wertigkeit. Das unterste Bit, auch Bit 0 genannt, hat den Wert "1". Hiermit lassen sich Werte von 0 bis 1 darstellen, also wird als nächstes Bit (Bit 1) eines mit dem Wert "2" benötigt. Jetzt haben wir 2 Bits, eines kann 0 oder 2 bedeuten, eines 0 oder 1. Durch deren Addition können also die Werte 0, 1, 2 und 3 dargestellt werden, das nächste Bit (Bit 2) bekommt also den Wert 4, womit wir bei nun 3 Bits Werte von 0 bis 7 darstellen können, 8 Möglichkeiten also. Berechnet ist das einfach 2 ^ Anzahl Bits. Womit wir bei den 8 Bits genau 256 Möglichkeiten haben, Werte von 0 bis 255.

Wie man schon an der Numerierung der Bits sieht, fangen Computer immer bei 0 an zu zählen. Und es ist auch gut so. Nicht jeder kennt spontan die Antwort auf die Frage "welche Wertigkeit hat Bit 4?". Mathematisch kann diese Antwort aber einfach ermittelt werden - 2 ^ 4, also 2 * 2 * 2 * 2 = 16.

Und die negativen Zahlen? Jetzt wird es etwas kompliziert. Wir haben insgesamt nur 256 Möglichkeiten mit unseren 8 Bits. Die haben wir schon von 0 bis 255 verbraten. Also haben wir nichts mehr übrig für negative Zahlen. Also werden die gleichen 8 Bits an den Stellen, wo negative Zahlen benötigt werden, einfach ein wenig anders verwendet. Eine einfache Methode wäre die Verschiebung des Wertebereichs. Wenn wir von den 0 bis 255 einfach 128 abziehen (weils in Bits so ne schöne glatte Zahl ist, 2 ^ 7), dann haben wir einen Bereich von -128 bis 127. Das ist ja einfach. Zu einfach. Es funktioniert nämlich ganz problemlos, aber bringt andere Probleme mit sich, wenn an Stellen in einem Programm beide Arten von Zahlen verwendet werden sollen, die mit Vorzeichen und die ohne Vorzeichen. Daher arbeitet ein Computer heutzutage mit dem Standard, daß die Werte von 0 bis 127 in beiden Reihen gleich aussehen. Unterschiedlich wirds erst ab 128. Hier ist in der Reihe ohne Vorzeichen der Wert 128 gemeint. In der Reihe mit Vorzeichen jedoch -128. Also kommt direkt nach der 127 die -128, wenn man das so durchzählt. Wie unpraktisch. Es gibt aber an einer anderen Stelle wieder mehr Ordnung - wenn man bei -128 anfängt, zu zählen und bis -1 zählt, da sind dann alle Bits auf "an". Der nächste Wert wäre, da wir keine weiteren Bits haben, dann alle Bits "aus". Und das entspricht der 0. So, nun ist sicherlich der Zeitpunkt erreicht, wo es etwas unübersichtlich wird, daher wird nun in den nächsten Bildern verdeutlicht, wie so ein Byte genau "funktioniert".

Note to myself: bilder malen und hier einfügen :)

== Ein Streifzug durch die Zahlensysteme ==

Wem jetzt alle Zahlen hier "krumm" vorkommen, weil wir ja Zahlen wie 10, 20, 100, 1000 als "glatt" betrachten, dem sei mit einem neuen Zahlensystem geholfen: dem Hexadezimalsystem. Das Hexa hat nichts mit dem Hexer zu tun, sondern steht schlicht und einfach für "6". Entgegen unserem Dezimalsystem, welches 10 verschiedene Werte pro Stelle umfasst, verwendet das Hexadezimalsystem 16 verschiedene Werte. Rechnet man nun herum, kommt man auf folgende Stellenwertigkeiten, zuerst im Dezimalsystem, dann im Hexadezimalsystem

10 ^ 0 = 1
10 ^ 1 = 10
10 ^ 2 = 100
10 ^ 3 = 1000

16 ^ 0 = 1
16 ^ 1 = 16
16 ^ 2 = 256
16 ^ 3 = 4096

Mehr brauchen wir im Moment nicht, mit diesen Stellenwertigkeiten kann man schon 16 bit darstellen, bei MIDI haben wir es höchstens mit 14 bit zu tun. Wo wir gerage bei Zahlensystemen sind...

2 ^ 0 = 1
2 ^ 1 = 2
2 ^ 2 = 4
2 ^ 3 = 8

Das haben wir doch vorhin im Prinzip schon gesehen. Richtig. Das Binärsystem, so heisst dieses Zahlensystem, wenn man die Bits einzeln schreiben will.

Der einzige Haken an der Sache ist nun, dass wir nur die Ziffern 0-9 kennen, was ist also mit den 6 neuen Werten für das Hexadezimalsystem? Ganz einfach, sie heissen A, B, C, D, E und F.

Im Prinzip kann man sich nun Zahlensysteme zusammen basteln, wie es einem Gefällt. Radix 26 z.B. mit "Ziffern" von A-Z, Radix 36 mit Ziffern von 0-9 und A-Z, man kann das Spiel recht weit treiben, die unterschiedlichsten Zahlensysteme sind im Einsatz. Und wenn man nun den deutschen Begriff "Radix" vom mathematischen Fachwort auf ein allgemein verständliches Wort umsetzt, kommt "Basis" heraus, englisch "base", und damit ist "base64" auch ein Zahlensystem. Dieses wird im Internet sehr viel verwendet, z.B. um Daten so zu codieren, dass sie sich mit einem Zeichenvorrat von 64 Zeichen darstellen lassen, egal, welchen Wertebereich die ursprünglichen Daten umfassten. Dass hier 64 verwendet wurde, liegt auch wieder an den Bits. 64 ist eine "glatte" Zahl für den Computer, sie entspricht genau dem Wertebereich, der mit 6 Bits darstellbar ist. Dadurch ist es sehr einfach, durch eben diese 64 zu teilen. Nimmt man ein Byte, und will es durch 64 teilen, sind die obersten beiden Bits des Bytes das Ergebnis (natürlich 6 bits nach rechts, also in Richtung Bit 0, geschoben), und die unteren 6 Bits der Rest.

All das klingt vielleicht etwas sehr abgeschweift, aber gerade bei SysEx kommt der Fall sehr oft vor, dass auf solche Arten Bits herumgewuchtet werden müssen, um mit den 7 zur Verfügung stehenden Bits für Daten alles abbilden zu können, was man so übertragen möchte. Und dazu gibt es die unterschiedlichsten Varianten, wo das Byte, welches übertragen werden soll, "durchgesägt" wird, je nachdem, wie viel Arbeit sich die Firmware des Zielgerätes machen möchte, um seine Bytes wieder zusammen zu setzen.

Apropos Firmware - diese ist immer in kompletten Bytes vorzufinden (intern sind das vielleicht sogar 16 oder 32 Bits, mit denen gearbeitet wird, dabei werden mehrere Bytes zusammen gefasst). Um diese effizient zu übertragen, werden z.B. 7 volle Bytes hergenommen, bei allen die Köpfe (also Bit 7, das höchste Bit) abgeschnitten, diese 7 gekürzten Bytes raus geschickt, und danach die 7 abgeschnittenen Bits in einem weiteren MIDI-Byte übertragen. Dies ist die effizienteste Art, 8bit-Daten via MIDI zu übertragen.

Für den nächsten Abschnitt ist es noch wichtig, wie hexadezimale Zahlen zu erkennen sind. Dazu gibt es mehrere Varianten, wovon die Folgenden die gängigsten sind:

;0xff
:ein vorangestelltes "0x" kennzeichnet die Hexadezimalzahl. Hauptsächlich in Programmiersprachen verwendet, C, C++, Java als Beispiele.

;FFh
:alternativ auch ffh, FFH, ffH, es spielt keine rolle, ob die Zeichen groß oder klein sind. Diese Schreibweise ist schon etwas betagter, findet sich aber in einigen MIDI-Dokumentationen bei den SysEx-Definitionen. In diesem Falle also ein der Zahl folgendes "h" oder "H" als Kennzeichnung.

;$ff
:auch schon etwas betagt, das vorangestellte Dollarzeichen kennzeichnet die Zahl als hexadezimal.

Generell ist es übrigens gleichgültig, ob die "Ziffern" A-F groß oder klein geschrieben werden.

== Ein paar Übungen ==

Bevor es nun ans SysEx-Rechnen geht, schauen wir uns mal noch ein paar kleine Rechnungen mit hexadezimalen Zahlen an.

;rechne die Zahl $5e ins Dezimalsystem um
:Rechenweg: die rechte Stelle hat die Wertigkeit 1 (16 ^ 0), die linke die Wertigkeit 16 (16 ^ 1). Das E hat den Wert 14. Weil nach der 9 das A kommt, also den Wert 10 hat, B ist 11, C ist 12, D ist 13, E ist 14 und F ist 15. Also haben wir für diese Zahl folgendes zu rechnen: 5 * 16 + 14 = 94. Wer es nicht glaubt, schaltet seinen Windows/Mac-Rechner auf "Wissenschaftlich" oder "Programmierer" um und kann dann zwischen hexadezimalen und dezimalen Zahlen umrechnen.

So, jetzt den automatischen Umrechner aber wieder weg, hier gehts weiter:

;rechne die Zahl 123 ins Hexadezimalsystem um
:Rechenweg: die dritte Stelle von rechts im Hexadezimalsystem entspricht 256 (16 ^ 2), also können wir das ignorieren, fangen wir mit der zweiten Stelle von rechts mit der Wertigkeit 16 (16 ^ 1) an und dividieren unsere 123 dadurch. Das Ergebnis ist 7 (die Nachkommastellen hier bitte wegwerfen, nichts runden!). Da ein Taschenrechner meistens nicht den Rest anzeigt, ist jetzt nur der im Vorteil, der auf dem Papier klassisch dividiert hat, er kennt den Rest schon. Der Rest muss ihn ausrechnen, indem er die 7 * 16 von den 123 substrahiert, danach lautet der Rest lautet 11. Also haben wir unsere beiden Stellen, 7 und 11, im Hexadezimalsystem bedeutet das dann 0x7b.

Da war doch noch was mit negativen Zahlen? Jetzt wirds fies!

;rechne die Zahl aah (vorzeichenbehaftet 8bit) ins Dezimalsystem um
:Rechenweg: Wir wissen aufgrund des Bit7, dass es sich um eine negative Zahl handelt. Wir wissen, dass 80h -128 ist, 81h ist -127, das geht weiter bis ffh, was -1 ist. Also können wir relativ einfach rechnen, indem wir das Bit7 weglassen, und den Rest zu -128 dazu addieren. Bei aah wäre das dann 2ah zum Rechnen. 2ah ist 2 * 16 ^ 1 + 10 * 16 ^ 0 = 2 * 16 + 10 * 1 = 32 + 10 = 42. Und jetzt addieren wir -128, bzw. substrahieren 128. Das Ergebnis sind -86. Um das jetzt mit dem Taschenrechner nachzuvollziehen, muss die hexadezimale Zahl "aa" möglicherweise mit "f"s aufgefüllt werden, damit der Rechner auch eine negative Zahl erkennt, weil er möglicherweise nicht nur mit 8 bit, sondern mit 16, 32, oder gar 64bit arbeitet. Der Windows-Rechner ist übrigens scheinbar generell zu doof dazu, aber wenn man die -86 nach hexadezimal umrechnet, bekommt man die "AA" mit nem haufen führender "F"s raus.

So, nun kann jeder für sich noch ein wenig experimentieren, und vielleicht auch einfach herausfinden, wieso man bei negativen Zahlen so viele 1-Bits links anflanschen kann, wie man möchte.

B-Control-Konfiguration

2007-01-06T18:22:09Z

MIK:

B-Control-Konfiguration

2007-01-06T17:55:39Z

MIK:

B-Control-Konfiguration

2007-01-06T16:47:17Z

MIK:

B-Control-Konfiguration

2007-01-06T16:27:57Z

MIK: /* Analyse eines Dumps vom B-Control */

Benutzer:MIK

2007-01-06T10:20:10Z

MIK:

Aktuelle Projekte hier im Wiki:

[[B-Control-Konfiguration]]

BC-Convert

2007-01-06T10:06:45Z

MIK: B-Control format converter instructions

This utility is able to convert the configuration of the [[B-Control]] series MIDI controllers between native [[SysEx]] format and a text file, which can be edited by any editor to change the configuration without having to fiddle around with the cumbersome built in user interface.

The current version 0.3 of BC-Convert can be found [http://b-control.mik-music.org/ here].

For a small documentation of the usage, read the following.

<pre>aphrodite:~/Documents/SysEx Librarian michael$ ./bc-convert -h
BC-Convert Version 0.3 (C) 2006 Michael Kukat
Usage: ./bc-convert [options]
Error: Help requested
Options:
-i <input file> Input file (default stdin)
-o <output file> Output file (default stdout)
-d <device id> Device ID (used on SysEx output only)
-m <model id> Model ID (used on SysEx output only)
-s Force SysEx output (default autodetect)
-t Force text output (default autodetect)

-s and -t can't be used together for obvious reasons.
aphrodite:~/Documents/SysEx Librarian michael$ </pre>

This is a command line tool, which has been compiled for MacOS X and Win32. No Drag&Drop or other funny stuff, just the command line. The following options can be used:

'''-i <input file>''' - gives the file to read for conversion.

'''-o <output file>''' - gives the file to write to. WARNING! This file will be overwritten!

'''-d <device id>''' - used on text to SysEx conversion only, sets the device ID of the device to configure. This is the configured ID less one. So if you configured ID 1 on your B-Control, use -d 0 for the converter. This argument is optional, by default, 127 is assumed, which talks to all B-Control devices on the MIDI interface you are sending the SysEx file on.

'''-m <model id>''' - very similar to the -d option, but sets the model ID. Usually, this is 20 for BCF2000 and 21 for BCR2000. Set to 127 by default, which in conjunction with the default device ID of 127 talks to all B-Control devices on the MIDI interface you are sending the SysEx file on.

'''-s''' - This forces conversion from text to SysEx, usually, the auto detection mechanism is able to recognize the conversion direction.

'''-t''' - The opposite of -s, this forces SysEx to text conversion.

The text format is quite simple, it contains the data encapsulated in the SysEx messages of the [[B-Control]]. As an addition, the converter has some features to simplify your life, it ignores blank lines and is able to strip off comments from your text, which the B-Control might not understand, but which help you to keep your files readable. By first converting a preset to text, you get somthing like this in your text file:

<pre># Generated by BC-Convert. Input was DeviceID 0, ModelID 21

$rev R1
...</pre>

The first line is a comment and will not be sent with the SysEx data. The second line is blank and will also net get sent. In detail, the parser works the following way:

First, isolate the complete line. Next, scan from the start of the line for a character starting a comment. This is the hash (#) and the semicolon (;). The semicolon should no longer be used, as it might disappear somewhen, so please only use the hash to start a comment. If one of those characters is found, the line is scanned backwards skipping all white spaces (blanks and TABs). The comment including all leading white spaces is stripped off.

If after this something is left over, it is written to the SysEx file.

So comments can be used like in the following example:

<pre># This is my test configuration

$rev R1 # Start BCR configuration
$preset # Start preset configuration
.init # Clear current edit buffer

#-------------------------
# Encoder 1 - MIDI volume
#-------------------------

$encoder 1 # Start encoder configuration
.easypar CC 1 7 0 127 absolute
.showvalue on
.mode 12dot/off
.resolution 96 96 96 96
.default 100

$end # End of BCR configuration</pre>

As you can see, everything can be well-formatted and commented this way. For a list of possible tokens which can be used in the configuration file, see [[B-Control-Tokenreferenz]].

[[category:Tricks]]

B-Control

2007-01-06T09:42:42Z

MIK:

B-Control is the name of a series of MIDI controller boxes and audio interfaces made by [[Behringer]]. The devices share all the same design and parts of the electronics, and currently are available in the following flavours:

[http://www.behringer.com/BCF2000/index.cfm BCF2000] - [[MIDI]] controller, provides 8 rotary encoders with push button function, lots of puttons and 8 motorized faders.

[http://www.behringer.com/BCR2000/index.cfm BCR2000] - The same like the BCF2000, but with 24 more rotaty encoders instead of the 8 motorized faders.

[http://www.behringer.com/BCA2000/index.cfm BCA2000] - Less functionality as a MIDI controller, its primary purpose is an [[USB]] audio interface.

[http://www.behringer.com/BCN44/index.cfm BCN44] - With a different design, as it is optimized for small size, this is another MIDI controller box.

[[Category:Hardware]]

B-Control

2007-01-06T09:40:59Z

MIK:

B-Control

2007-01-06T09:40:30Z

MIK:

B-Control is the name of a series of MIDI controller boxes and audio interfaces made by ((Behringer)). The devices share all the same design and parts of the electronics, and currently are available in the following flavours:

[http://www.behringer.com/BCF2000/index.cfm BCF2000] - [[MIDI]] controller, provides 8 rotary encoders with push button function, lots of puttons and 8 motorized faders.

[http://www.behringer.com/BCR2000/index.cfm BCR2000] - The same like the BCF2000, but with 24 more rotaty encoders instead of the 8 motorized faders.

[http://www.behringer.com/BCA2000/index.cfm BCA2000] - Less functionality as a MIDI controller, its primary purpose is an ((USB)) audio interface.

[http://www.behringer.com/BCN44/index.cfm BCN44] - With a different design, as it is optimized for small size, this is another MIDI controller box.

B-Control

2007-01-06T09:39:51Z

MIK:

B-Control is the name of a series of MIDI controller boxes and audio interfaces made by ((Behringer)). The devices share all the same design and parts of the electronics, and currently are available in the following flavours:

(http://www.behringer.com/BCF2000/index.cfm BCF2000) - ((MIDI)) controller, provides 8 rotary encoders with push button function, lots of puttons and 8 motorized faders.

(http://www.behringer.com/BCR2000/index.cfm BCR2000) - The same like the BCF2000, but with 24 more rotaty encoders instead of the 8 motorized faders.

(http://www.behringer.com/BCA2000/index.cfm BCA2000) - Less functionality as a MIDI controller, its primary purpose is an ((USB)) audio interface.

(http://www.behringer.com/BCN44/index.cfm BCN44) - With a different design, as it is optimized for small size, this is another MIDI controller box.

Behringer

2007-01-06T09:31:39Z

MIK:

[http://www.behringer.com/ Behringer] is a manufacturer of a large number of audio electronics devices for the studio and/or the stage. They are able to have a quite low price range for their products by developing the products in Germany while producing them in Asia.
[[category:Manufacturer]]

Behringer

2007-01-06T09:30:13Z

MIK:

B-Control-Konfiguration

2007-01-06T09:25:50Z

MIK:

B-Control-Konfiguration

2007-01-06T09:03:59Z

MIK:

B-Control-Konfiguration

2007-01-06T08:43:40Z

MIK: