Wichtig:

Das Calpep hat sehr limitierte Öffnungszeiten. Wer also in der ersten Runde an der Bar sitzen möchte, sollte wirklich früh vor Ort sein. Mind. 15 Minuten vor der Öffnung sollte man sich beim Lokal einfinden. Selbst dann ist man nicht an der ersten Position. Die hardcore Fans sind bereits 25-30 Minuten vorher da um als erster die Bar zu betreten.

Ganz klare Empfehlung

Wer in Barcelona ist und das Calpep nicht besucht hat was verpasst. Die Tapas sind fisch, schmecken super lecker und die Stimmung ist einmalig!

Die Website findet ihr hier

Immer wieder die gleiche Story. Nun is es schon einige Male vorgekommen. Das Restaurant Molino in Dietikon hat den Vogel mal wieder abgeschossen. Folgendes hat sich Heute in der x-ten Ausführung zugetragen.

• Wir gingen zu zweit um ca. 11:50 ins Restaurant
• Kurz nachdem wir unsere Plätze eingenommen haben, bestellten wir uns etwas zu trinken.
• Die Getränke kamen zügig und während wir die Getränke in Empfang nahmen bestellten wir unser Mittagessen. Da war es ca. 11.55 und das Restaurant war zu geschätzt 1/3 gefüllt.
• Einmal mehr startet das grosse Warten… Um 12:23 kam das Essen dann und es sah nicht nur so aus, als ob es schon länger gestanden hätte, die Temperatur war auch entsprechend.
• Die banale Entschuldigung: Es sei heute voll… Ok, mittlerweile war die Auslastung auch gut bei 80% nur wurde unser Essen deutlich davor bestellt. Nach der Reklamation ging es nochmals eine entsprechende Zeit, bis mein Essen warm wieder zurück kam.
• Daraus schliesse ich einmal mehr, dass das Essen in der Küche bereit stand, aber der Transport zum Tisch versagte.

Tragisch?!?

Wenn so ein Missgeschick einmal vor kommt, dann kann man das ja verkraften und unter “scheiss Tag” verbuchen. Das tragische an der Sache ist, dass es bis jetzt bei jedem meiner Besuche ein Problem gab. Einmal wurde ich einfach vergessen. Dann durfte man wieder mehr als 1h auf so etwas simples wie eine Pizza warten. Zu guter letzt gibt es nicht einmal ein entgegenkommen vom Restaurant selbst.

Etwas positives gibt es da doch noch. Die Küche kocht wirklich gut, aber der Service verspielt alles!

Konsequenzen

Das Restaurant ist für mich für lange Zeit gestorben. Die Preise sind so undendlich überteuert, wenn man die Leistung dahinter betrachtet. Zum Glück gibt es noch andere gute Restaurants in der Nähe, so dass man getrost auf das Molino verzichten kann. Hervorheben möchte ich das Restaurant Tomate und Heimatt.

So, der Frust ist draussen und evtl. bewahre ich ja jemand anders vor dem Verlust der Nerven

Motivation

Meine Motivation war einfach das Interface von Digital Enlightenment kennen zu lernen und eine .Net Schnittstelle dafür zu bauen. Natürlich hat das neben Spass an der Sache auch noch einen weiteren Grund. Ein weiteres kleines Projekt, was ich momentan baue, ist eine WCF-Abstraktion des DE-Interfaces. Die Idee ist, dass ich ein solches Interface an einem Beliebigen PC anstöpseln kann und ihn über einen Service als DMX-Empfänger zu definieren. Details zu diesem Projekt kommen, sobald es ein Alphastadium erreicht.

Systemvoraussetzungen

Der Wrapper auf die aktuelle Version .Net 4 ausgelegt. Entsprechen wird davon ausgegangen, dass das Framework bereits installiert ist. Auch wird Mono (noch) nicht unterstützt.

Implementierung

Das DE-Interface wurde nochmals gewrappt und verpackt. Hinter dem Wrapper steckt eine komplett asynchrone implementation, welche darauf ausgelegt ist, dass der DMX-Sender nur so wenig wie möglich blockiert.

Dasselbe gilt auch für den DMX-Empfängerteil. Die Interface-Callbacks sind so minimal wie möglich gehalten, um das DE-Interface möglichst schnell wieder frei zu geben. Die Eventverteilung erfolgt dann asynchron in .net. Natürlich muss das bei der UI-Implementation berücksichtigt werden!

Probleme

Aktuell habe ich noch erhebliche Probleme mit dem DMX-In. Allerdings konnte ich diese Probleme noch nicht 100% loaklisieren. Das Problem tritt auf, wenn das Interface im DMX-in/out läuft und das DMX-Kabel als Loopback angeschlossen ist. Dabei konnte ich schon mehrfach beobachten, dass die Array, in welche die Inputwerte geschrieben werden, komplett gekillt wird. Der Debugger zeigt mir da keine leere Array mehr, sondern einen Integer mit dem Wert 0. Das bringt natürlich .Net ganz schön ins stocken und führt zum Crash. Ob es am Loopback liegt oder ob es sich um ein Problem mit der offiziellen usbdmx.dll von Digital Enlightenment handelt, ist noch nicht ganz klar. Meine Vermutung geht stark in die Richtung DE, da auch die DE-Testapp crashed, wenn das Interface im Loopbacktest läuft.

Die Probleme mit DMX-In gehören der Vergangenheit an. Es war ein Problem im Interop-Code zwischen der .Net-Welt und der nativen Welt. Wenn man ein Objekt nicht explizit reserviert und pinned, kann es sein, dass die Adresse zur Laufzeit ändert. Das findet natürlich die native Welt nicht lustig und schmiert ab.

Ausblick

Da meine persönliche Zeit auch öfters begrenzt ist, kann ich keine Versprechen machen, wann eine neue Version des Codes verfügbar wird. Jedoch werde ich versuchen den Wrapper zu stabilisieren, damit er auch mit ruhigem Gewissen benutzt werden kann.

Danke

Herzlichen Dank von mir an das DMXControl-Team, welche eien tollen Job machen und mich hier bei einem kleinen Eigendau unterstützt haben. Man merke sich: Auch als Dev ist man nicht vor EigenDaus sicher

Download

Der Code ist unter GPLv3 freigegeben und kann bei Sourceforge heruntergeladen werden. Die URL https://sourceforge.net/projects/dedotnet führt direkt zum Projekt.

Beide BCF-2000 über USB angeschlossen

Wenn beide BCF-2000 über USB angeschlossen werden, stehen unter Windows zwei eigenständige BCF-Geräte zur Verfügung. Nun kommt das Problem auf, dass DMX-Control (DMXC) nur ein Gerät auf einmal ansprechen kann. Daher müssen diese zwei BCF über ein “virtuelles Midikabel” verbunden werden und anschliessend über ein “virtuelles Midigerät” für DMXC angeboten werden. Zunächst konfigurieren wir jedoch die BCF-2000 und installieren die Treiber dazu.

Anschluss der beiden BCF-2000

Die Bilder rechts zeigen den Modus der BCF-2000. Sie stammen aus dem offiziellen Handbuch der BCF-2000. Wie die Pulte auf den Modus U1 gestellt werden können ist auch dort zu finden. Im Modus U-1 sind die Midi-Ports des BCF-2000 nicht aktiv. Hier wird lediglich mit dem USB-Port gearbeitet. Die Midiinformationen vom Pult werden direkt an den Computer geschickt. Als Input wird hier lediglich ein Midi-Feedback erwartet. Es wird hier nicht unterschieden, ob ein Signal für den Expander oder nur Feedback ist.

Damit das Anschliessen erfolgreich klappte, musste ich die Geräte gestaffelt anhängen. Erst das Erste Gerät und danach den Treiber dafür (Version 1.2.1.3 ist für den Mehrfachbetrieb erforderlich). Nachdem das erste Geräte erfolgreich installiert ist, kann man das zweite anschliessen. Auch hier muss danach noch der Treiber installiert werden, da Windows wiederum den eigenen Treiber verwenden möchte. Damit alles klappt kann einfach das Setup des Treibers nochmals ausgeführt werden. Im Gerätemanager von Windows sollten dann zwei Behringer Geräte gefunden werden.

Info

Wenn die Pulte das nächste mal angeschlossen werden, sollte darauf geachtet werden, dass der gleiche USB-Port verwendet wird, an welchem die BCF-2000 schon zuvor angeschlossen wurden. Ansonsten kann es sein, dass der Treiber nochmals installiert werden muss!

Software

Als Software für diese virtuellen Midigeräte verwendete ich MidiYoke. Als Verbindungssoftware der virtuellen Midigeräten und den BCFs kommt MidiOX zum Einsatz. Die beiden Tools können auf ihrer offiziellen Seite herunter geladen werden.

MidiYoke

MidiYoke hat sich im Betrieb unter WindowsXP leider nicht als wirklich stabil heraus gestellt. Das kann unter Anderem daran liegen, dass der Treiber schon relativ alt und nicht für WinXP geschweige denn Vista oder Windows 7 geeignet ist. Es gibt zum Glück auch alternativen zu MidiYoke, welche ebenfalls virtuelle Midiports zur Verfügung stellen. Sobald ich Erfahrungen mit einer alternative gesammelt habe, werde ich das hier ergänzen.

MidiOX

MidiOX ist eine super Midischaltzentrale für den PC. Hier können sämtliche Geräte geöffnet und neu geroutet werden. Auch können die Routings so angepasst werden, dass die entsprechenden Geräte auch nur die für sie bestimmten Midibefehle / Feedbacks erhalten. Dabei arbeiten beide BCF2000 mit den gleichen CC Nummern. Das eine jedoch auf Channel 1 und das andere auf Channel 2. Die Routings sind entsprechend gehalten. Antworten an Channel 1 gehen ausschliesslich an das BCF2000, welches für Channel 1 zuständig ist.

Wichtig ist hier, dass für die Kommunikation mit DMXC nicht ein Port, sondern zwei virtuelle Midi-Ports verwendet werden. Dies ist auch auf der Homepage von MidiYoke / MidiOX beschrieben. Verbindet eine Applikation den Input und den Output, kann eine Feedbackschleife entstehen, welche das System auch in die Knie zwingen kann. Daher wird hier der Midi Yoke Port 1 als Output (Input bei DMXC) und der Midi Yoke Port 2 als Input (Output bei DMXC) verwendet.

DMXControl 2.11

Damit DMXControl auch mit den BCF-2000 Kommunizieren kann, muss nun noch die Midifernsteuerung konfiguriert werden. Hier wird als Input der “Midi Yoke Port 1″ gewählt und als Output “Midi Yoke Port 2″. Ist die Midifernsteuerung aktiv sollte man nun auch in MidiOX die Midi-Meldungen sehen, welche von bzw. zu DMXC gesendet werden.

Probleme

Dieser Betriebsmodus funktioniert prinzipiell nicht schlecht. Das Problem besteht mehrheitlich in der Stabilität. Während des Programmierens ist es mehrfach vorgekommen, dass die Midi-Inputs nicht mehr bei DMXC an kamen. Die Midi-Outputs wurden noch durchgeroutet. Somit lies sich ein Fader aus DMXC noch positionieren, aber lieferte keien Signale, wenn er am Pult verändert wurde. Der Treiber des BCF-2000 und MidiOX dürften nicht das Problem sein. Denn die Inputs von den Pulten kam bei MidiOX an und wurde auch an MidiYoke weitergeleitet. Da kamen jedoch die Signale nicht mehr bis zu DMXC durch. Auch dürfte DMXC nicht das Problem sein, denn mit einem BCF läuft die Midi-Steuerung sehr zuverlässig. Daher die Vermutung, dass MidiYoke hier die Signale verschwinden lässt. Dieses hängenbleiben lässt sich durch ein Neustart der Midifernbedienung wieder lösen, ist jedoch nicht so lustig in einer Live-Show.

Ein BCF-2000 über USB angeschlossen und zweites über MIDI

Die Idee hinter diesem Modus ist, dass die Verbindung zwischen DMXC und den beiden BCF-2000 direkt gekoppelt wird. So braucht es keine zusätzliche Software, welche das Midisignal routet oder merged / demerged. Man hängt einfach ein BCF per USB an und das andere über Midikabel. Das benötigt dann zwar noch zwei Midikabel, macht jedoch die Softwareinstallation weniger komplex. Das ist jedenfalls die Theorie und es lässt sich auch alles so konfigurieren, nur gibt es da dann einen kleinen Hickup mit DMXC.

BCF-2000 Konfiguration

Ein BCF2000 wird hier in den USB-Mode U-4 versetzt. Somit wird es für die Erweiterung mit dem zweiten BCF2000 vorbereitet. Das andere BCF2000 wird in den MIDIModus Stand Alone-Mode S-3 gebracht. Anschliessend werden die zwei BCF2000 gemäss Handbuchschema verbunden. Dazu werden zwei MIDI-Kabel benötigt. Sobald die BCF2000 verbunden sind kann das BCF2000 im Modus U-4 an den Computer angeschlossen werden. Auf dem Computer erhält man nun ein einzelnes Geärt.

Achtung

Bevor das eine BCF2000 auf den Modus S-3 gebracht wird, sollten die ControlCodes programmiert werden. Nach dem wechsel erkennt der PC den BCF2000 nicht mehr, da der USB deaktiviert wurde.

DMXC-Konfiguration

Da in DMXControl jetzt nur noch ein BCF2000 zur Auswahl steht, kann direkt dieses Gerät für den Input und Output verwendet werden. Dadurch erspart man sich den Umweg über Midiyoke und Midiox, welche mit mehreren Geräten nicht so stabil laufen. Soweit jedenfalls die Theorie. Auch in der Praxis steht das zur Auswahl und funktioniert als Input.

Probleme

Das Grundproblem bei dieser Lösung ist, dass DMXC das Feedback nicht korrekt generiert. Das über MIDI angeschlossene Pult erkennt das Feedback und setzt die Fader. Das über USB-Angeschlossene Pult erkennt die Feedbackinformationen von DMXC nicht als Feedback und setzt die Fader nicht. Dadurch kann zwar den Input benutzt werden, aber ohne Feedback ist der Spass nicht wirklich gegeben, denn für etwas hat man ja die Motorfader im Pult.

Aktuelle Lösung

Die aktuelle Lösung basiert auf der zweiten Idee gekoppelt mit MidiOX und MidiYoke. Dabei werden die beiden BCF2000 so aufgebaut, dass sie dem Setup des zweiten Versuchs entsprechen. Ein BCF2000 per USB angeschlossen und das zweite über Midi angebunden. Der einzige Unterschied ist, dass das MIDI-Signal zuerst von MIDIOX über MidiYoke nach DMXC geleitet wird. Das Feedbacksignal nimmt den Weg über MidiYoke zu MidiOX und anschliessend zum BCF2000. Das Feedback wird nun von beiden BCF2000 korrekt angenommen. Spannend ist, dass MidiYoke und MidiOX das Signal eigentlich unverändert weitergeben. Auf dem Pfad muss etwas am MidiSignal verändert werden. Was verändert wird und bei welcher Station das genau passiert, kann ich aktuell nicht sagen.

Quellen der Schemabilder

Die Schemabilder stammen aus dem Originalhandbuch von Behringer.

Allgemeines

DMXControl begleitet mich nun schon eine ganze Weile. Anfangs habe ich damit nur relativ kleine Dinge umgesetzt und dabei kam auch selten viel Hardware zum Einsatz. Mittlerweile werden die Events grösser und grösser. Mit dem Event hier habe ich bis dato eine meiner grössten Lichtsysteme betrieben. Nächstes Jahr werde ich das wohl noch steigern können, aber das ist noch Zukunftsmusik. Hier ein kleiner Rückblick.

Setup / Hardware

Bevor auf das einzelne Setup eingegangen wird, hier erst einmal die Hardware, welche für die Show zum Einsatz kam. Es war nicht wenig und hat entsprechend Spass gemacht

Stage

• 24 Par 64 hängend
• 4 Par64 am Boden
• 4 LED Par 56 am Boden
• 4 MAC 250 Krypton
• 2 TourHazer 2
• 4 Eurolite TS-255 Scanner

FOH

• 6 PCs
• 2 MAC 250 Krypton
• 2 Verfolger

Controller

• Intel Pentium 4 3GHz SingleCore mit HT, 2.5GB RAM, WinXP SP3 inkl. allen Updates
• 2 Samsung widescreens
• 2 Behringer BCF-2000
• 2 Digital Enlightenmen USBDMX-Interfaces (1 Produktiv, 1 Ersatz)
• DMXControl 2.11
• MidiYoke
• MidiOX

DMXControl 2.11 – Probleme / Erfahrungen

DMXControl hat sich bei all meinen Anlässen als sehr zuverlässig heraus gestellt. Ich hatte während der Programmierphase auch schon Abstürze und Probleme, aber während des Live-Betriebs bis dahin nicht. Dies änderte sich mit diesem Anlass. Während der ersten Show hat sich DMXC ganz langsam aber stetig etwas mehr verabschiedet. Das fing mit zunächst als Bedienfehler interpretiertem Verhalten an (z.B. klick auf nen Button musste man zwei mal machen) und endete damit, dass DMXC mit ner Fehlermeldung unsanft starb. Wir hatten Glück und konnten den Absturz gerade sauber umschiffen. Das Publikum hat von unseren technischen Problemen beim Licht nichts mitgekriegt.

Nun stellt sich natürlich die Frage nach der Ursache. Diese wurde mit etwas probieren eingeschränkt. Wann genau die ersten Fehlverhalten von DMXC auftraten kann ich nicht mehr sagen, auch konnten wir das nicht zuverlässig reproduzieren (sonst gäbe es einen Bugreport bei DMXC). Jedoch war ein Schlüsselverhalten, dass das Midifeedback noch lief, aber die Midimeldungen nicht mehr bei DMXC ankamen. MidiOX erhielt die Meldungen noch und leitete sie korrekt an MidiYoke weiter. Da gehen die Midi Meldungen allerdings verloren. Ob der Fehler bei MidiYoke oder DMXC liegt lässt sich nur schwer sagen. Jedenfalls waren die Midiprobleme die Vorboten für den Absturz. Durch ein schliessen des Fensters für die Midifernsteuerung konnte diese ohne kompletten DMXC-Neustart wieder ins Leben gerufen werden.

Das fast gleiche System hat jedoch auch schon einmal ässerst zuverlässig funktioniert. Der einzige Unterschied zum letzten Event war, dass jetzt zwei BCF2000 per USB angeschlossen waren. Beide über USB und über MidiOX gemappt. Anschliessend haben wir den Modus der BCF2000 gewechselt, so dass nur noch ein BCF2000 am USB-Port hing. Damit das Feedback richtig funktionierte musste auch dieses Midisignal über MidiOX geroutet werden. Die Anzahl der Midi Meldungen hat sich daher nicht verändert, nur kommt nun alles über einen USB-Bus und wird auch wieder an einen Anschluss zurück gesendet. Seit dieser Anpassung läuft das System wieder stabil und ohne grössere Probleme.

Mittlerweile habe weitere Events mit zwei BCF2000 gefahren. Jedoch habe ich hier eine Konfigurationsänderung vorgenommen. Das Setup ist im Artikel DMX-Control 2.11 mit 2 BCF2000 beschrieben. Die Konfiguration geht davon aus, dass nur ein BCF2000 per USB angeschlossen wird und das andere über die Midischnittstelle des ersten BCF2000 reingeschlauft wird. Dies hat sich bis heute als recht stabil heraus gestellt.

Ausblick

Die nächsten grösseren Events werden Zeigt, ob wirklich alles so ist, wie es sein sollte und das System wieder stabil läuft. Der Rechner wird bis dahin noch durch einen Cor2 ersetzt, welcher die Leistung mehr als ausreichend bringen sollte. So sollte es möglich sein die Wartezeit auf die schon lange ersehnt Version 3.0 von DMX-Control zu umschiffen.

Es gibt noch einiges zu konfigurieren. Das Templat ist noch nicht ganz so, wie es sein sollte. Auch fehlt noch das eine oder andere Plugin.
Nun hoffe ich, dass ich die Zeit finde, die Seite rasch zu füllen und fertig zu konfigurieren.