Automatische DDF-Generierung durch die Open Fixture Library

Hallo liebe DMXControl-Community!

Ich bin einer der Entwickler der Open Fixture Library. In unserem Open-Source-Projekt sammeln wir Gerätedefinitionen (Fixtures) in einem von uns erstellten einheitlichen Format, das dann automatisch in Fixtures für Lichtprogramme wie e:cue und QLC+ exportiert wird. (Das heißt, dass bspw. der Elation Platinum HFX in unserem JSON-Format gespeichert wird, dann aber als UserLibrary.xml für e:cue oder .qxf-Datei für QLC+ heruntergeladen werden kann.)

Wir sind gerade dabei, auch eine Unterstützung für DMXControl hinzuzufügen! Das bedeutet, dass unsere 141 Fixtures (Tendenz steigend ) dann auch als DDF3-Dateien heruntergeladen können, sobald wir fertig sind. Im Entwicklungsprozess werden wir sicher noch ein paar Fragen zum DDF-Format haben (eine davon auch jetzt schon), deswegen wäre es super wenn wir hier im Forum etwas Support bekommen könnten.

Wem das Projekt gefällt und gerne etwas dazu beitragen möchte, kann ganz einfach neue Geräte mit unserem Online-Fixture-Editor hinzufügen – oder ihr gebt uns ein Feedback, wenn ihr einen Fehler entdeckt oder euch etwas nicht gefällt. Wer Erfahrung mit JavaScript/NodeJS hat, kann auch gerne zur Codebase beitragen. Wir freuen uns über Beiträge aller Art!

Nun zu meiner Frage zum DDF-Format: Ich bin mir nicht sicher, wie ich mit Multibeam-Geräten wie z.B. der GLP Impression X4 Bar 10 umgehen soll. DMXControl 3.1 unterstützt wohl noch kein Multibeam und ein Workaround ist es, für jeden Beam ein eigenes DDF zu erstellen. Allerdings habe ich in vielen Gerätedefinitionen wie auch im (geprüften) DDF dieser GLP-Bar gesehen, dass für jeden Beam/Pixel ein weiterer <functions>-Tag erstellt wird. Wird dies tatsächlich von der Software unterstützt? Oder ist das die Syntax, die dann von DMXControl 3.2 unterstützt wird? Oder ein Relikt aus DMXC2-Zeiten?

Tatsächlich ist der Workaround mit mehreren DDFs gar nicht so einfach in unsere automatische Generierung einzubauen. Was, wenn wie beim Robe Robin LEDWash 600 die RGB-Channel für die einzelnen Beams in der Mitte sind? Oder wenn die Channel-Reihenfolge „Dimmer 1, Dimmer 2, Dimmer 3, Rot 1, Grün 1, Blau 1, Rot 2, Grün 2, Blau 2, Rot 3, Grün 3, Blau 3“ ist? Die Alternative mit mehreren <functions>-Tags wäre mir also deutlich lieber.

Danke im Voraus!

Felix

Quote from nutzer99

Hallo Felix,

Das klingt ja nach einem sehr spannendem Projekt. Für den ersten Schritt würde ich dir empfehlen, dass du dir in unserem Wiki einmal die Tutorials anschaust zu den DDFs. vlt kann da LightningBrothers da weiterhelfen.

Danke für den Tipp! Das Wiki mit der DDF-Dokumentation hat mir tatsächlich in der Entwicklung schon viel weitergeholfen.

Quote from nutzer99

Was aber vlt. wichtig für euch ist: Bei den DDFs sind die Unterfunktionen an manchen Stellen wichtig. Da die HAL (Hardware Abstraction Layer) mit Eigenschaften von Geräten arbeitet und nicht mit DMX Werten / Kommentaren. Das heißt es reicht an manchen Stellen nicht aus "Lampe Aus" und "Lampe Ein". Aber da seid ihr anscheinend schon vorbereitet. Bei Prisma und Shutter etc. habt ihr das ja soweit schon umgesetzt.

Richtig, unser Format ist zwar DMX-Kanal-orientiert, aber mittels genauer Typen und weiteren Attributen der Unterfunktionen können wir inzwischen recht genau und maschinenlesbar darstellen, was ein Channel macht.

Quote from nutzer99

Übrigens ist die Erstellung der Geräte über Web sehr schick gelöst! Das ist sehr userfreundlich und einfach zu bedienen!

Danke, schön zu hören!

Quote from Soon5

Hallo Felix.

Auf jeden Fall cooles Projekt das ihr da habt. Was wichtig wäre ist eine Versionsunterstützung. DMXControl 3 entwickelt sich ständig weiter. Ein Beispiel sind die von dir angesprochenen Multibeam fixtures. Aktuell werden die noch nicht so unterstützt wie wir das wollen. Man kann zwar mehrere function-tags im DDF anlegen aber das UI unterstützt solche Geräte noch unzureichend. Wir haben aber dazu schon viele Ideen und einiges schon umgesetzt. Da wir aber aktuell noch viele andere Baustellen haben muss das noch etwas warten. Ergo wäre es wichtig das euer Generator für verschiedene DMXControl 3 Versionen exportieren kann weil eben das Gleiche Gerät in einer zukünftigen Version ein anderes DDF hat um die dann verfügbaren Funktionen zu nutzen.

Gibt es dann einen Changelog für das DDF-Format? Und werden in der DDFs-Lib dann immer die neuesten Versionen behalten? Momentan sehe ich da nur die Unterscheidung zwischen DMXC2 und DMXC3.

Okay, danke für eure Antworten!

Noch eine Frage: Gibt es ein XML-Schema und/oder einen Fixture-Validator, um DDFs auf Richtigkeit zu überprüfen? Oder geschieht die Überprüfung ausschließlich per Hand?

Wir verwenden bei unseren Plugins automatisierte Tests, um Fehler bei der Generierung von Fixtures leichter zu finden. Bspw. gibt es von QLC+ ein XML-Schema und ein Test-Skript in Python – unsere generierten Fixtures für QLC+ werden dann von uns automatisch gegen Schema und Skript getestet. Ist es irgendwie möglich, dies auch für DMXControl zu erreichen?

Danke für die ausführliche Antwort! Einen einfachen Test, der nur schaut, ob alle Kanäle und Capabilities (Unterfunktionen) vorhanden sind, werden wir eh selbst implementieren bzw. ist es teilweise schon.

Da ich gerade an der ptspeed-Funktion arbeite, stelle ich mir die Frage, ob

<range type="linear" mindmx="255" maxdmx="0" minval="0" maxval="100" />

äquivalent zu

<range type="linear" mindmx="0" maxdmx="255" minval="100" maxval="0" />

ist?

Mit anderen Worten: Soll ich bei umgekehrten Ranges (also fast->slow) immer die DMX-Werte umdrehen oder kann ich auch die DMX-Werte in normaler Richtung belassen und dafür die Speed-Werte umdrehen?

Ich bin gerade dabei, Farbräder (color wheels) einzubauen und stelle mir die Frage, wie man die Farbrad-Drehung von 0 bis 360° einbaut, wie es z.B. der Martin Rush MH3 Beam (Manual) im Colorwheel-Channel (64…127) erlaubt. Mit wheelrotation kann ich eine kontinuierliche Drehung spezifizieren, aber eine statische Drehung anhand eines Winkels geht nicht?

Wen es interessiert – so speichern wir diese Daten in unserem Open-Fixture-Library-Format (→ Quellcode) :

{
  "dmxRange": [64, 127],
  "type": "ColorWheelRotation",
  "angleStart": "0deg",
  "angleEnd": "360deg"
},
{
  "dmxRange": [128, 189],
  "type": "ColorWheelRotation",
  "speedStart": "fast CW",
  "speedEnd": "slow CW"
},
{
  "dmxRange": [190, 193],
  "type": "ColorWheelRotation",
  "speed": "stop"
},
{
  "dmxRange": [194, 255],
  "type": "ColorWheelRotation",
  "speedStart": "slow CCW",
  "speedEnd": "fast CCW"
}

Quote from JPK

Hallo,

doch, das geht auch. Nennt sich im DDF goboindex:

XML

<goboindex dmxchannel="1">
    <range range="360" mindmx="0" maxdmx="127" minval="0" maxval="360" />
</goboindex>

Wie das bei mehreren Kanälen etc. aussieht findest du hier: https://wiki.dmxcontrol.de/wiki/DDF-Synta…Goboindizierung

Das bestimmt aber die Drehung eines einzelnen Gobos, oder? Ich meinte die Drehung des gesamten Gobo- und vorallem Farbrades. Bei einem Farbrad macht es auch keinen Sinn, einen einzelnen Filter zu drehen. Wenn man aber direkt den Winkel des Rades setzen kann, wie es bei manchen Geräten wie dem MH3 eben möglich ist, kann man sämtliche Split-Farben in verschiedenen Verhältnissen (z.B. linkes Drittel Gelb, der Rest Rot) frei erstellen.

Eine weitere Frage habe ich wieder. Und zwar betrifft das Kanäle, deren Verhalten von anderen Kanälen abhängt. Beispiel: Channel 10 vom cameo NanoSpot 120 (11ch) heißt Program und hat ein paar vordefinierte Effekte. Normal ist Channel 11 dann Program Speed. Wenn Channel 10 aber auf einen Wert zwischen 212 und 237 gesetzt wird (Sound Control), ist Channel 11 Sound Sensitivity.

Bei der Open Fixture Library haben wir dies mit so genannten Switching Channels dargestellt: Channel 11 ist entweder Program Speed, oder Sound Sensitivity, jenachdem welchen Wert Channel 10 hat.

Gibt es eine Möglichkeit, dies auch in DMXControl abzubilden? Ich habe gesehen, dass support-Channel und handler wohl in diese Richtung gehen, aber sind diese funktionsunabhängig? Also kann ich zwischen beliebigen Kanälen umschalten?

Danke, das hört sich gut an

In der letzten DDF-Version aus dem verlinkten Thread wird der Kanal 0, der Kanal 1 zwischen Dimmer und Strobe umschaltet, gar nicht in einer eigenen Funktion definiert. Ist dies trotzdem möglich? In meinem Beispiel wäre das ja der Effekt-Kanal, den ich als <rawstep> einfügen würde, und der dann als support-Channel nochmal in Program Speed und Sound Sensitivity jeweils auftauchen würde.