1. DMXC 3.3.0 RC2
2. Aufgrund der Exportproblematik zusammengeschustert mit angepasster Metadata.json. Version 1.2.18 lädt noch, Version 1.2.19 nicht mehr
Wenn ich mir die Presets.xml in der v19 anschaue, stehen da die beiden Presets aber noch drin 🤔
Ich habe aus meinem Projekt gestern alle Presets gelöscht, die dazugehörigen cuelists entfernt und auch die dazugehörigen devices entfernt (waren für Experimente mit Matrizen, die ich so nun nicht mehr brauche).
Nun kann ich das Projekt nicht mehr laden:
22:40:56 WARN ProjectManager - Error when loading Project Rod24Light: Errors in Project
org.dmxc.lumos.Kernel.Exceptions.ProjectIOException: Errors in Project
at org.dmxc.lumos.Kernel.Resource.LumosIOContext.ThrowOnErrors() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Resource\LumosIOContext.cs:line 227
at org.dmxc.lumos.Kernel.Project.ProjectManager.LoadProjectFromStream(ProjectVersionID id, Stream projectStream, IProgress`1 progress) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Project\ProjectManager.cs:line 458
22:40:56 ERROR ProjectManager - Loading Presets in Project
22:40:56 ERROR ProjectManager - Error loading Presets in Project
22:40:56 ERROR ProjectManager - Loading Presets in Project
22:40:56 ERROR ProjectManager - Error loading Presets in ProjectNun sollte es ja eigentlich gar keine Presets mehr geben - was fehlt hier? Im Bugtracker habe ich dazu nichts passendes gefunden, soll ich das da mit angehängtem Projekt eintragen? Oder hab ich den entsprechenden Bug nur nicht gefunden?
Dass du dann trotzdem einen Dimmer siehst, ist ein Feature von DMXControl 3 - hier werden über den Hardware Abstraction Layer (HAL) verschiedene Funktionen softwareseitig automatisch zur Verfügung gestellt und intern verarbeitet, komplett unabhängig von der eigentlichen DMX-Ausgabe.
In der Kanalübersicht sollte auf den Kanälen, auf denen die Beams liegen, keine Dimmer sein. Das ist doch schon nach der HAL, oder?
Wie sind die Startadressen der Devices?
Also bei mir hat es zumindest nach Kanalübersicht (HW kriege ich erst nächste Woche) funktioniert. Habe den 52-Kanal Modus der Varytec Starbar 12 genommen, einzelne Pixel für RGB und W jeweils als Device Groups hinzugefügt und kann über diese Gruppen Farben und Dimmer inklusive Fannings steuern. Den Dimmer und Strobe Kanal habe ich als einzelnes Control-Device außerhalb der Gruppen hinzugefügt. Der Dimmer pro Pixel sollte dann über die HAL nur die RGBW Werte beeinflussen - damit solltest du den Dimmer im Control-Device eigentlich dauerhaft auf 1 setzen können.
Sofern du den speedmaster nicht manuell auf 123,41 BPM eingestellt hast, sieht es so aus, als würde das trotzdem korrekt ankommen. Wenn du das Projekt lädst, sollte der speedmaster auf 0 stehen. Wenn du dann den Audio analyser startest und der speedmaster nimmt einen entsprechenden Wert an, funktioniert alles.
Was macht denn der Export genau? Da liegen ja auch .dmz Dateien drin mit der metadata.json, die auch bei den Exporten aus dem RC1 (wo das bei uns noch funktioniert hat) vergleichbar sind.
Das es als workaround keine Garantien gibt, ist auch völlig i.o. Danke für die Info!
Das Problem tritt bei mir auch reproduzierbar auf (DMXC 3.3.0 RC2). Hilft es, wenn ich noch logs im Buigtracker dazu ablege? https://bugs.dmxcontrol-projects.org/index.php?do=d…from=&closedto=
Und falls es einen Workaround gibt: Könnt ihr mir den nennen oder auch im Bugtracker dokumentieren?
Der DMXCMixer funktioniert, vielen Dank für den Tipp!
Ich werde tatsächlich eher weniger Verläufe machen (dazu hab ich nicht genug einzelne fixtures), sondern einfach nur dieses Farbschema nutzen um einzelne Fixtures oder Gruppen anzusteuern.
Dabei bin ich noch auf einen Punkt gestoßen: Wenn man zwei Random-nodes mit gleichen Einstellungen mit dem gleichen Trigger ansteuert haben die wirklich sehr häufig den gleichen Wert. Was wird hier als Seed verwendet?
Ich arbeite gerade an einer größtenteils automatisierten Lichtshow und möchte dafür Farbkombinationen (bestehend aus jeweils zwei Farben) speichern und random eine der Farben meinen Devices zuordnen. Mein Gedanke war, hierfür "virtuelle" PARs zu nutzen und eine entsprechende cuelist festzulegen, in der jede Cue einer Farbkombination entspricht. Nun muss ich die diesen PARs zugeordneten Farben auch wieder abrufen. Das funktioniert nicht, in dem ich ein Programmer node hinzufüge, die virtuelle PAR damit verknüpfe und dann versuche die Farbe abzurufen. Der Ausgang des Programmers für die Farbe bleibt dann leer (vermutlich weil die Farbe des PAR über die cue und nicht den Programmer gesetzt wurde). Im Stage view haben diese virtuellen PARs aber die korrekten Farben.
Gibt es eine Möglichkeit, sich über cues die Farben in eine Variable zu schreiben, die ich dann im Input assignment abrufen kann? Ich möchte ungerne für alle Farben und Fixtures cues anlegen, da das in der Kombinatorik sehr viel wird. Habe auch schon gesuch, ob man im cue quasi die aktuelle Farbe in einen ColorMaster schreiben kann, aber nichts gefunden.
Gibt es eine andere Möglichkeit, das gewünschte Verhalten darzustellen? Also eine Liste von Farbkombinationen, die ich dann im Input Assignment abrufen kann?
Vielen Dank! Das hat geholfen.
Um ein bisschen randomisierte Automation in die Show zu kriegen, würde ich gerne eine Variable im Input assignment steuern.
Die Idee: Nach X Beats wird ein Farbwechsel getriggert, und gleichzeitig der Wert von X aus 1,2,4,8,16 neu random berechnet. Diesen Wert muss ich dann ja speichern, um nach den nächsten X Beats wieder eine Änderung zu triggern. Zirkelabhängigkeiten scheinen nicht möglich zu sein, deswegen habe ich es mit einem slider versucht, von dem ich den Wert lese und auch wieder zuweisen will. Das geht aber auch nicht.
Gibt es eine Möglichkeit, Variablen im Input Assignment zu speichern?
Der bisherige Testaufbau:
