DMX Stream als Datei ?

[Stephan]

Hi Experts,
für ein neues Projekt möchte ich die einen DMX-Daten als Datei abspeichern können.
Ist so etwas schon vorgesehen?
Wenn ich das richtig verstanden habe, könnte man so etwas als Ausgabeplugin realisieren.
Gibt es so etwas vielleicht schon ?

Ciao Stephan

[Christian]

Hi,

so etwas gibt es bislang noch nicht, aber man sollte es sicher ohne weiteres programmieren können. Leider fehlt mir die Zeit ein Modul selbst zu schreiben, aber hier sind einige Infos zur Entwicklung eines eigenen Plugins für den PC_DIMMER:

http://www.pcdimmer.de/index.php/pcdimm ... ntwicklung


ciao,
Christian

[Stephan]

Vielen Dank.

Kannst Du vielleicht noch ein paar Tipps geben, welche Funktionen benutzt werden müssen.
Reicht dazu die Implementierung der Funktion DLLSendMessage() aus ?

Ciao Stephan

[Christian]

Hi,

ja, über DLLSendMessage bekommst du alle DMX-Werte, aber auch andere Informationen zugesandt. Du musst auf die folgende Nachricht überprüfen:

Code: Alles auswählen

MSG_ACTUALCHANNELVALUE=14; // Data1=Integer, Data2=Integer

Du bekommst ja folgende Variablen geliefert:

Code: Alles auswählen

procedure DLLSendMessage(MSG:Byte; Data1, Data2:Variant);stdcall;

MSG, Data1 und Data2. MSG muss also gleich 14 sein, dann erhälst du neue Kanalwerte. Data1 enthält dann den Kanal und Data2 den eigentlichen DMX-Wert.


dein Code könnte z.b. so aussehen:

Code: Alles auswählen

procedure DLLSendMessage(MSG:Byte; Data1, Data2:Variant);stdcall;
begin
  if MSG=14 then
  begin
    MeinDatenspeicher[Zeitindex][Integer(Data1)]:=Integer(Data2);
  end;
end;

Zeitindex wäre z.B. eine Variable im Millisekundentakt. Mit dem Befehl Integer() castest du die Variant-Variable als Integer, damit du in Delphi auf das Array-Element zugreifen kannst.


Viele Grüße und Erfolg,
christian

[Stephan]

Hi,
vielen Dank für die schnelle Antwort. Das hilft mir schon weiter.

Was ich allerdings noch nicht verstehe, ist dieser Zeitindex.
Ist DMX nicht so aufgebaut, dass es ein kontinuierlicher Datenstrom ist?
Dann ergibt sich der Zeitpunkt der Aktualisierung eines Kanals ja automatisch durch die Anzahl der übertragenen Kanäle.
(d.h. wenn es wieder von vorne anfängt).

Ciao Stephan

[Christian]

Hallo,

nunja, die Hardware gibt alle DMX-Kanäle kontinuierlich aus. Die Software sendet allerdings nur bei Änderungen die Kanalwerte zu den Plugins. Damit wird eine Menge an Informationen eingespart und Rechnerressourcen bleiben frei. Deshalb muss ein entsprechendes Zeitraster implementiert werden, damit man einen zeitlichen Ablauf erzeugt. Es muss also wie bei einer Audio- oder Videodatei ein fester Grundtakt vorhanden sein, auf den die DMX-Werte aufgezeichnet werden, da dieser nicht vom PC_DIMMER vorgegeben wird.

Das lässt sich aber ohne weitere Probleme über einen einfachen Timer und eine dabei inkrementierte Variable erledigen.


viele Grüße,
Christian

[Stephan]

Ok, das erklärt einiges.

Wenn ich nun einen Dimmer-Kanal im 10ms Abstand verändere, müssten ja nun alle 10ms neue Werte bzw. Messages ausgegeben werden.
Ist dies möglich ?
Oder was ist die maximale Refreshrate?
Bzw. in welchem Intervall muss ich den Timer laufen lassen?
Meine bisherigen Versuche mit einem 10ms Timer und Kanaländerung von 50ms waren leider nicht sehr erfolgreich.
Der Timestamp zwischen den einzelnen Messages ist leider nicht konstant.

Zusätzlich noch eine andere Frage:
Wie funktioniert es mit dem Fading über DMX?
DMX kennt ja nur Kanalwerte. Wie kann ich dann Fading realisieren?
Oder is das ein Gerät mit 3 Kanälen (Startwert, Endwert, Zeit) ?

Vielen Dank für die tolle Unterstützung.
Ciao Stephan

[Christian]

Hi,


zunächst einmal zur zweiten Frage: das Faden wird beim PC_DIMMER vom Dimmerkernel erledigt, an dem ich mehrere Tage programmiert habe bis er stabil lief. So einfach ist es dann nämlich doch nicht mehrere hundert Kanäle zeitgleich oder versetzt mit den unterschiedlichsten Fadezeiten zu faden. Kurzgefasst habe ich einen Timer, der mit 1ms Auflösung einen Grundtakt liefert. Nun prüfe ich jede Millisekunde, ob der aktuelle Wert dem zu erreichenden Wert entspricht. Ist dies nicht der Fall wird die Differenz zum Sollwert berechnet und entsprechend über die gewünschte Zeit ein Stückchen davon inkrementiert oder dekrementiert. Soweit das Faden.

Nun liefert der PC_DIMMER den Plugins natürlich völlig willkürlich neue Signale. Somit musst du dein eigenes Raster entwicklen. Da laut DMX-Standard eine maximale Refreshrate von 44Hz (also 22,72ms) möglich ist, sollten sogar 20ms völlig ausreichen. Nun kann der PC_DIMMER aber mehrere hundert Werte bei schnellen Fades innerhalb dieser 22ms senden. Du müsstest diese Werte also sammeln und beim nächsten "feuern" deines 20ms Timerintervalls in eine Variable für diesen Zeitschritt speichern. Da DMX512 eh nur mit 22,72ms arbeitet wirst du keinen Auflösungsverlust feststellen.

Beim Abspielen brauchst du dann nur wieder einen weiteren 20ms Timer laufen lassen und deine abgespeicherten Werte wieder aufrufen und an den PC_DIMMER oder direkt die Hardware zurückzusenden. Fertig. Allerdings kommen da ohne Datenkomprimierung oder eine effiziente Datenverwaltung schon ein paar Bytes pro Sekunde zusammen:

Auflösung: 20ms (50Hz)
Datenmenge pro Takt: 512 Byte
Daten pro Sekunde: 50
Datenrate: 25 kByte/s

Datenmenge für z.B. 10 Minuten: 14,6 MByte


Naja, schlimmer als ein Video ist da ja nun auch nicht

Jetzt programmierst du das noch entsprechend mit Timestamp und in einem Standard-Stream-Format wie ein video ab und du hast eine flexible Lösung DMX-Daten abzuspeichern - irgendwie bekomme ich gerade auch Lust dazu, so eine Funktion fest in den PC_DIMMER zu integrieren.


bis dann,
Christian

[Christian]

Hi Stephan,

ich habe mich am Wochenende mal hingesetzt und mir eine Spezifikation für ein DMX-Streaming-Format ausgedacht. Hier habe ich mal ein wenig dazu geschrieben: http://www.pcdimmer.de/index.php/dmxstream


schau es dir mal an und schreib mir mal, was du davon hälst.

viele Grüße,
Christian

[Ingo]

So, dann werde ich auch mal aktiv
Ich habe das Thema mal verfolgt und mir meine Gedanken gemacht. Da ich vor einiger Zeit schonmal einen eigenen Dimmerkernel geschrieben habe, der einen Server bereitstellt und der von einem PC_DIMMER Plugin (Fade-)Daten bekommt und sie an ein PC_DIMMER-Ausgabeplugin weitergibt (so wie der Netzwerkserver, nur mit Eingriffsmöglichkeit serverseitig), hatte ich mir die Implementation ganz einfach vorgestellt. Ich schreibe einfach die Fadedaten in einen Stream, so bleibt die Datei auch klein. Nur jetzt hänge ich an einer ganz "simplen" Stelle: Ich bekomme irgendwie keine Daten mehr von DLLSendData. Ist an der Stelle was geändert worden, Christian?

Viele Grüße,
Ingo

P.S.: Ich weiß nicht welche Speicher-Variante besser ist , ob alle DMX-Daten oder nur Fadedaten, da letzteres einen Dimmerkernel benötigt. Aber da ich den ja eh schon als Objekt programmiert habe, ist mir das doch lieber .

[Christian]

Hi Ingo,

am Ausgabesystem habe ich seit Version 5.0.0 nichts mehr geändert. Aber ich werde sicherheitshalber beim nächsten Öffnen des Codes das nochmal prüfen. Nachteil beim Speichern von lediglich der Fadezeiten: man kann nicht durch die Szenen durchscrollen und damit die Lichtstimmung direkt anschauen. Sollte ich nämlich dieses Streamformat vernünftig hin bekommen, dann ist es nur noch ein kleiner Schritt zu einem vernünftigen Audioeffektplayer, bei dem man die Geräteeigenschaften dann mit der Maus und entsprechenden Liniendarstellungen wie bei Cuebase hinbekommt. Der Audioeffektplayer sollte nämlich mal gründlich überholt werden.


ciao,
Chris

[Bofrost_Mann]

Hallo,

da ich zwar eher aus der Audio-Ecke komme und mich dort einigermaßen mit Datei-Formaten, deren Usability usw. auskenne, möchte ich mich hier mal mit drauf hängen.
Ich habe mir im Wiki, die Vorstellung von dem neuen DMXS angeschaut und an sich ist die Sache sehr gut durchdacht. Dennoch habe ich einen kleinen Punkt gefunden, den ich hier anmerken möchte: in den ID-Tag dieser Dateien gehört meiner Ansicht nach noch mit hinein, welche Geräte an welchem Kanal hängen, d.h. am besten einmal der generische Typ (Pan, Tilt, Dimmer, Gobo, etc.) und einmal der Name des tatsächlich verwendeten Gerätes - dies erstmal nur als Grundidee, die man beliebig verfeinern kann.

Hintergrund der Überlegung, ist, dass man zum einen bei der Bearbeitung weiß, welcher Kanal überhaupt was macht und zum anderen, das Änderungen im Gerätesetup, schneller auch in der DMXS Datei geändert werden können.


Hope to be helpful ...

[Stephan]

Oh, da habe ich ja was ausgelöst

Vielen Dank für das Feedback.
Das Datenformat sieht ganz gut aus.
Momentan wird eine etwas primitivere Variante programmiert.
Den Code kann ich im Lauf der nächsten Tage posten.

Vielleicht sollte ich mal kurz beschreiben, was ich damit anstellen will:
Ich entwickle gerade eine Elektronik zur Ansteuerung von bis zu 50 RGB LEDs und zusätzlich bis zu zwei RGB-Stripes.
Die Konzeption habe ich ich mit einem Freund entwickelt, der sich ein bisschen in Delphi-Programmierung auskennt
und deswegen gerade das Plugin schreibt.
Das Ganze soll selbständig lauffähig sein. Als Mikroprozessor kommt ein ATXMega programmiert in C zum Einsatz.
Also möchte ich den DMX-Stream auf einer SD-Karte speichern. Diese wird dann an die Elektronik angeschlossen, die Daten werden ausgelesen und die LEDs entsprechend angesteuert.

Ciao Stephan

[Ingo]

Zu dem Streamformat hätte ich noch eine Frage: Es sollen immer nur Kanaländerungen übertragen werden. Aber wenn nur die Kanalanzahl in einem Frame übergeben wird, müssen ja auch immer alle nicht geänderten Kanäle bis zum Geänderten mitgeschrieben werden. Ist das so gewollt oder zu vernachlässigen?

[Christian]

Hi Ingo,


ich habe bislang über das eigentliche DMX-Datenpaket nach dem Header noch gar nichts geschrieben. Dort werden die Daten jeweils mit der entsprechenden Kanalnummer gekoppelt abgelegt. Ist zwar Speicherintensiver, aber trotzdem universeller. Somit könnte ein DMX-Datenpaket nach dem Header so aussehen:

BYTE0 , BYTE1 , BYTE2
00000000 00111001 11111111 (Kanal 57 auf 100%)

BYTE3 , BYTE4 , BYTE5
00000001 10101111 11000100 (Kanal 431 auf 77%)


usw. somit hätte man (sofern man das wollte) sogar bis maximal 128 DMX Universes. Theoretisch könnte man nun auch auf 16 Universes (8192 Kanäle) generell beschränken und hätte dann noch pro Kanal 3 Bit frei, mit denen man etwas machen könnte.

Auf jedenfall werden lediglich die Kanäle in den normalen Frames gespeichert, die wirklich geändert werden. Die Keyframes sind dann entsprechend immer von 0 ausgehend bis zu einer (beliebigen) maximalen Kanalzahl, da der letzte Kanal ja im Header des Frames angegeben wird. Im Anhang habe ich mal ne Berechnung der Datenrate durchgeführt. Bei durchschnittlich 30 Kanaländerungen pro Frame und einem Keyframeintervall von 25 komme ich auf 7,2kB/s. Das macht dann rund 0,4MB/Minute. Ist doch ne ganz annehmbare Größe.


bis dann,
Chris