Bugtracker DMXControl 3

Das Projekt liegt in der Cloud (im üblichen Ort). Wenn man versucht, aus der Main Cuelist die Cue “ES.01.10: Einlass” in den Cue Timing Editor zu laden, dann fliegt folgende Exception:

2024-04-13 18:25:34,465 [Main GUI] ERROR Lumos.GUI.Run.GuiRunManager - Unhandled Exception: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei Lumos.GUI.Windows.SceneList.SceneEditView.<>c.<SceneEditView_Shown>b__12_1(IDevicePropertyFacade c) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Windows\SceneList\SceneEditView.cs:Zeile 57.
   bei System.Linq.Enumerable.WhereSelectArrayIterator`2.MoveNext()
   bei System.Linq.Enumerable.<DistinctIterator>d__64`1.MoveNext()
   bei System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
   bei System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
   bei Lumos.GUI.Windows.SceneList.SceneEditView.<SceneEditView_Shown>d__12.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Windows\SceneList\SceneEditView.cs:Zeile 57.
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.AsyncMethodBuilderCore.<>c.<ThrowAsync>b__6_0(Object state)

Aus der Async-Function kommen einzelne null Einträge raus, was dazu führt, dass beim Abrufen des DisplayNames die Exception fliegt.

Aktuell wird das Dirty Flag gesetzt, wenn sich der Play-State des Timecode Players verändert oder die Position des Zeitmarkers. Das macht aber eigentlich nicht so viel Sinn und wird auch in anderen Programmen (z.B. DaVinci, Adobe Premiere, Adobe Audition,…) nicht so gemacht. Ich will ja eigentlich nur Änderungen an der Timecode-Show an sich speichern, aber nicht, ob die Show gerade läuft oder nicht. Aktuell wird nämlich dadurch im Hintergrund auch automatisch Autosave aktiv, was beim reinen Abspielen einer Show ja aber keinen Sinn ergibt.

Normalerweise ist der Kernel ab DMXControl 3.3.0 versteckt beim Start. So sieht man allerdings Fehler nicht mehr direkt, sollten diese im Kernel (oder im Umbra) auftauchen. Solche Fehler sollten zwar nicht so häufig auftreten. Wenn es passiert, sollte ein User in der GUI darüber informiert werden. Allerdings ist es sehr nervig, wenn während der Show ein Fehler auftritt und dann ein Popup / eine Message hochpopt. Daher sollte dafür ein Icon unten rechts als Ausrufezeichen in rot erscheinen, und beim Draufklicken sollte eine Info kommen, wo Fehler aufgetreten sind (nur dass und nicht welche). Man kann vielleicht noch eine “Show Kernel” oder “Show Umbra” Funktion anbieten. Aber das nur optional, wenn das einfach möglich ist

Die neuen Master bieten neben den neun Einstellungen für HSV, CMY und RGB auch die Möglichkeit, die RGB+ Farben einzustellen. Allerdings macht es keinen Sinn, Einen Fader für eine RGB+ Farbe darzustellen, wenn es im Projekt kein Gerät gibt, welches diese ausgeben kann. Es sollte also eine Möglichkeit geben, entweder selbst einzelne Farben auszublenden oder nur diese anzuzeigen, für die es auch Einstellungsmöglichekten bei den Geräten gibt.

Bisher können schon verschiedene Layouts in einem Projekt gespeichert werden. Allerdings ist es noch nicht möglich, eines der Layouts als Startup-Layout für ein Projekt zu definieren. Es sollte eine Einstellungsmöglichkeit geben, in der man auswählen kann, ob ein spezifisches Layout geladen werden soll oder das zuletzt verwendete. Für ersteres muss dann auch noch ein Handling für nicht mehr existierende Layouts implementiert werden. Siehe dazu auch: https://youtu.be/aXtpf6tv3Cw?t=8542

So, wie aktuell Projekte grün markiert werden, wenn sie geladen sind, sollte auch die geladene Version grün markiert werden, damit man dies direkt sieht.

Wird ein Projekt erfolgreich geladen, erscheint die Abfrage, ob das vorherige Layout geladen werden soll. Diese Abfrage erscheint jedoch nur in der GUI, in der das Laden des Projekts ausgelöst wurde. Die Abfrage sollte jedoch in allen GUIs erscheinen. Hierfür bräuchte es einen gRPC-Call, der an alle GUIs geht. Dieser sollte dann die AskLoadProjectLayout Funktion im Window Manager ausführen. Die Project Administration soll dann entweder eine neue “AskLoadProjectLayoutInAllGUIs” Funktion oder direkt den gRPC-Call aufrufen.

Beim erfolgreichen Laden eines Projekts erscheint irgendwann eine Abfrage, ob das letzte Layout geladen werden soll. Zukünftig sollte diese Abfrage ein Dropdown umfassen, in dem alle im Projekt enthaltenen Layouts aufgeführt sind. Hier sollte das zuletzt geladene Layout vorausgewählt sein. Es sollte auch eine Möglichkeit geben, das Laden des Layouts abzubrechen. In Hinblick auf FS#4954 (was im Zuge dieser Integration auch umgesetzt werden kann) wäre gut, wenn es drei Optionen gäbe:

• Jedes Mal nachfragen (Ask) (Standardmäßig eingestellt)
• Immer das letzte Layout laden (Load always last Layout)
• Immer “Layout xyz” laden (Load always “Layout xyz”)
• Kein Layout laden (No Default Layout)

Die Abfrage kommt nur im ersten Fall hoch.

Der Launcher kann aktuell nur eine Version erkennen, anzeigen und starten (im selben Ordner bzw. anhand des Registry-Eintrags). Sobald es mit DMXControl 3.3.1 auch offiziell möglich ist, mehrere Versionen parallel zu installieren (Installer packt dann Registry-Einträge von DMXC 3.3.1 in einen separaten Registry-Eintrag zur 3.3.0). Der Launcher muss einerseits diese neue Struktur unterstützen und andererseits so erweitert werden, dass er dann im Zweifelsfall mehrere DMXC-Versionen anzeigen kann.

Wie in den angehängten Logs zu sehen, dampft bei 2023-07-13 04:28:31,393 der SendDevicePropertyChanges ab (nicht wundern, die Uhr des PCs war falsch). Hier wie besprochen die Logs für die weitere Analyse, warum das der Fall war.

Seit Implementierung von  FS#4973  wird immer die Projekt Administration geöffnet, wenn sich die GUI verbindet und noch kein Projekt geladen ist. Nun soll dieses Verhalten erweitert und einstellbar gemacht werden. Es wird ein GUI Setting benötigt, um wählen zu können, ob die Projekt Administration geöffnet wird (bisheriger Case), ein gewisses Default-Projekt geladen wird (z.B. für Festinstallationen) oder nichts passiert. Für Case 2 muss noch in der Projekt Administration und im Project Store integriert werden, dass ein Default-Projekt ausgewählt werden kann.

Im Timecode Player sind nur Cuelists mit Timecode Trigger erlaubt. Daher können bestehende Cuelists, in denen auch andere Trigger verwendet werden, nicht in den Timecodeplayer eingefügt werden. Es wäre gut, wenn es hierfür eine Art Konvertierung gibt, die das ermöglicht. Am besten mit Abfrage, ob dieser Eingriff wirklich gemacht werden soll, weil das die Cuelist grundlegend ändert. Das aber nur anbieten, wenn das wirklich geht, denn Manual- oder Beat-Trigger können nicht konvertiert werden. Zu klären ist nur noch, ob der Fade-Speed mit eingerechnet wird oder nicht. Möglich wäre auch, diese Funktion als Konvertierungsfunktion im Menü der Cuelist anzubieten

DMXControl 3 hat unterschiedliche Properties. Diese müssen visualisiert werden. Im folgenden sollen Vorschläge gesammelt werden, wie diese Visualisierung aussehen soll. Dabei sollen alle wichtigen Visualisierungen mit einem +++ versehen werden Bereits erledigte Visualisierungen sind als solche markiert.

• Color +++ (erledigt)
• ColorTemp (erledigt)
• Cool
• Dimmer +++ (erledigt)
• Effectwheel
• Fan –> num. Fann.
• Filter
• Focus –> num. Fann.
• Fog
• Frost –> num. Fann.
• Gobo +++ (WIP)
• Heat
• Index –> num. Fann. +/-
• Iris –> Darstellung als Iris-Blende analog zur Stage View
• Matrix –> Idealerweise Vorschau der Matrix, welche in dem Eintrag abgebildet ist
• Position +++ (erledigt)
• Prism –> kurzfristig keine Visualisierung, langfristig über ein generisch erzeugtes Bild auf Basis der DDF-Definition
• PTSpeed –> num. Fann.
• Radix –> Idealerweise Vorschau der Radix, welche in dem Eintrag abgebildet ist
• Raw –> num. Fann.
• Rotation –> num. Fann. +/-
• Scale
• Shutter +++
• Strobe +++
• Switch +++ (erledigt)
• Zoom –> Visualisierung eines Lichtkegels analog zum Programmer

Anmerkungen
Num. Fann –> Darstellung als Fanning einfacher numerischer Werte
+/- –> Darstellung wie num. Fanning, jedoch mit positiven und negativen Wertebereich, sodass der 0-Wert auf halber Höhe liegt

Habe DMXC Beta 12 auf einem jungfräulichen Rechner installiert und die Fehler im Anhang sind im Kernel erschienen. Allerdings nur beim allerersten Start. Bei jedem weiteren Start gibt es keine Fehler mehr.

Ich fände es gut, wenn es neben der Releasetime (die letztendlich der Einblendzeit einer Cue aber eben für das Ausblenden entspricht) auch ein Releasedelay gäbe. Hintergrund hierfür ist der Übergang zwischen mehreren Cuelists des selben Typs. Wenn man ein modulares Cuelist-Schema verwendet, hat man mehrere Cuelists, die nur eine Geräteeigenschaft, wie z.B. den Dimmer anspricht. Um einen weichen Übergang zwischen den Cuelists hinzubekommen, muss man die Releasetime der ausblendenden Cuelist und die Fadetime der ersten Cue der einblendenden Cuelist so geschickt wählen, dass der Übergang nicht auffällt. Das Problem ist nämlich, dass man eine zu kurze Releasetime dadurch sieht, dass die Scheinwerfer kurz ausblenden, bis die zweite Cuelist übernimmt und einblendet.

Dieses Problem könnte man mit einem ReleaseDelay und LTP-Cuelists ganz einfach umschiffen, indem man dann das ReleaseDelay auf die gleiche Länge setzt, wie die Fadetime der ersten Cue der einblendenden Cuelist. Die Releasetime würde man dann auf 0 setzen. Dadurch hat man bei LTP einen weichen Übergang, ohne dass die Scheinwerfer kurz ausblenden.

Aktuell detektiert DMXControl 3 jeden Tastendruck, sollten diese Tasten im Input Assignment verwendet werden. Im Livestream zu den kleinen Helfern in DMXControl 3.3.0 (siehe dazu auch: https://youtu.be/aXtpf6tv3Cw?t=8187) kam die Idee auf, einen Tastendruck nur abzufangen, wenn entsprechende Fenster aktiv sind.

Beim noch einmal über FS#3974, FS#4870 nachdenken (im Rahmen von https://forum.dmxcontrol-projects.org/index.php?thread/16934-cuelist-freigabezeit-verz%C3%B6gerung-dimmer-farbwert ), kam mir folgende zusammenfassende Überlegung: Ideal wäre es, wenn man die Freigabe einer Cuelist generell als weitere Cue ansehen kann (mit allen daraus resultierenden Vor- und Nachteilen). Mit dieser Release-Cue hätte man einerseits die Möglichkeit FS#4870 umzusetzen. Da jede Cue eine Fade Time und eine Delay Time hat, wäre das hier einfach eingebbar. Man müsste noch überlegen, ob man hier auch ein Fanning zulässt wie das bei den Zeiten für andere Cues auch möglich ist. Aber tatsächlich hätte ich damit eigentlich kein Problem, denn dadurch verschiebt man eben nur den Zeitpunkt für einzelne Geräteeigenschaften, wann sie freigegeben werden. So würde dann auch der Cue Timing Editor funktionieren. Mehr noch kann man den Zeitpunkt der Freigabe der Cuelist dann noch feiner einstellen als bisher, denn dann gäbe es nämlich nicht nur “manual only”, “with go” und “when last cue ends”. Stattdessen kann man dann die ganz normalen Cue-Trigger für das Freigeben verwenden. Das einzige, was man überlegen müsste wäre, wie man “manual only” richtig abdeckt. Aber da dürfte eigentlich ein “No Trigger” Eintrag für diese Art von speziellen Cues reichen. So kann ich nie die Release-Cue triggern und die Cuelist nur beenden, wenn ich auf Stop klicke. Dann wir natürlich trotzdem die “Release-Cue” ausgeführt.

Bei manchen Input-Werten kann es vorkommen, dass diese etwas schwanken, gerade bei analogen Spannungswerten. Diese Schwankungen sorgen jedes Mal für eine Werteänderung und triggern so ein Update des ConnectionSets, obwohl dies vielleicht nicht nötig wäre. Daher wäre es gut, wenn es ein Filter-Node gäbe, welches einen Input entsprechend glättet. Hier sollten zumindest ein paar der Glättungsverfahren / Filtertypen implementiert werden (siehe https://de.wikipedia.org/wiki/Gl%C3%A4tten_(Mathematik))

Da gerade im Forum die Frage nach der Performance von DMXControl 3 hoch kam, drängte sich für mich eine Idee geradezu auf: Einen internen Benchmark-Test von DMXControl 3. Sprich ein mitgelieferter, immer gleicher Ablauf typischer Dinge, um herauszufinden, wie performant ein PC ist. Passende Szenarien könnten folgende sein:

• Dauer Programmstart
• Dauer des Ladens eines Demo-Projekts
• Dauer für Hinzufügen von einer gewissen Anzahl an Geräten
• Update-Rate bei paralleler Ansteuerung von verschiedener Anzahl an Geräten (z.B. 10, 50, 100, 500)
• Update-Rate von mehreren Mastern

etc. Diese Liste ist erst einmal zum Brainstorming gedacht und ist weder vollständig noch voll durchdacht, ob ein Punkt wirklich sinnvoll ist. Aber mal so als Idee. Das Ganze kam mir auch vor allem vor dem Hintergrund, dass fast alle modernen Spiele mittlerweile einen solchen Test eingebaut haben.

Überspringt man Audiocues mit GoTo, erscheint eine Warnung im Kernel.

Spielt man im angehängten Projekt die Cuelist ab, erscheinen mehrere Fehlermeldungen und Warnungen im Kernel

00:13:12 WARN  SceneList - Cue Play: Begrüßung.WAV of Type org.dmxc.lumos.Kernel.Audio.AudioScene returned empty OutputValues. This can cause unintended behaviour.
00:13:12 INFO  AudioManager - Start playing Begrüßung.WAV
00:13:24 INFO  AudioManager - Abourt playing of Begrüßung.WAV
00:13:24 ERROR AudioManager - Exception at Play: Begrüßung.WAV
00:13:24 WARN  SceneList - Cue Stop: Begrüßung.WAV of Type org.dmxc.lumos.Kernel.Audio.AudioScene returned empty OutputValues. This can cause unintended behaviour.
00:13:48 INFO  Session - Saved Project to GUI KUECOREI7JPKLT, Path E:\DMXControl 3\Projects\Audiofile Demo 3.2.1 Beta4.zip
00:16:19 WARN  SceneList - Cue Play: Ansage.mp3 of Type org.dmxc.lumos.Kernel.Audio.AudioScene returned empty OutputValues. This can cause unintended behaviour.
00:16:19 INFO  AudioManager - Start playing Ansage.mp3
00:16:21 ERROR AudioManager - Exception at Play: Ansage.mp3
00:16:21 INFO  AudioManager - Abourt playing of Ansage.mp3
00:16:21 WARN  SceneList - Cue Stop: Ansage.mp3 of Type org.dmxc.lumos.Kernel.Audio.AudioScene returned empty OutputValues. This can cause unintended behaviour.

Aus diesem Thread: https://forum.dmxcontrol-projects.org/index.php?thread/15425-par-strahler-lauflicht-mit-geschwindigkeitssteuerung/ kam mir die Idee von "Dimmerkur​ven" für den Trapezeffekt? Sprich der Effekt wird um zwei Dropdown-Einträge erweitert, mit denen man für Fade Up und Fade Down jeweils bestimmen, mit welcher Kurve gefadet wird (linear, Sinus-ähnlich, ….). Dadurch hätte man deutlich mehr Kontrolle über das Verhalten. Das macht natürlich die anderen Effekte nicht überflüssig, weil man da natürlich noch eine feinere Einstellmöglichkeit hat.

Das erste angehängte DDF führt zu einer Exception. Es ist in sofern falsch aufgebaut, als dass ein Step in einem Raw-Bereich ist. Trotzdem darf das nicht zu einer Exception führen.

ProjectLoad: ERROR: Loading Devices in Project(null)ProjectLoad: ERROR: Error loading Devices in ProjectSystem.InvalidOperationException: Handler RawDMXHandlerNode doesn't have any Ranges!
   bei org.dmxc.lumos.Kernel.HAL.Handler.AbstractRangesHandlerNode.getMinValue(String type) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\HAL\Handler\AbstractRangesHandlerNode.cs:Zeile 770.
   bei org.dmxc.lumos.Kernel.HAL.Handler.AbstractRangesHandlerNode.get_MinValue() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\HAL\Handler\AbstractRangesHandlerNode.cs:Zeile 747.
   bei org.dmxc.lumos.Kernel.HAL.Handler.RawDMXHandlerNode.getPropTypeInstance(IDeviceProperty prop) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\HAL\Handler\Generic\RawDMXHandlerNode.cs:Zeile 102.
   bei org.dmxc.lumos.Kernel.HAL.Handler.AbstractHandlerNode.getTypeInstance(IDeviceProperty prop) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\HAL\Handler\AbstractHandlerNode.cs:Zeile 751.
   bei org.dmxc.lumos.Kernel.HAL.Handler.HandlerDependency.<>c__DisplayClass25_0.<getTypeInstance>b__0(IPropertyHandlerNode n) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\HAL\Handler\HandlerDependency.cs:Zeile 300.
   bei org.dmxc.lumos.Kernel.HAL.Handler.HandlerDependency.ForEachHandlerNode[T](Func`2 work) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\HAL\Handler\HandlerDependency.cs:Zeile 354.
   bei org.dmxc.lumos.Kernel.HAL.Handler.HandlerDependency.getTypeInstance(IDeviceProperty prop) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\HAL\Handler\HandlerDependency.cs:Zeile 300.
   bei org.dmxc.lumos.Kernel.HAL.Handler.HandlerRegistry.<>c__DisplayClass24_0.<getTypeInstance>b__0(HandlerDependency h) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\HAL\Handler\HandlerRegistry.cs:Zeile 382.
   bei org.dmxc.lumos.Kernel.HAL.Handler.HandlerRegistry.ForEachHandlerDependency[T](IDevicePropertyBase prop, Func`2 work) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\HAL\Handler\HandlerRegistry.cs:Zeile 448.
   bei org.dmxc.lumos.Kernel.HAL.Handler.HandlerRegistry.getTypeInstance(IDeviceProperty prop) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\HAL\Handler\HandlerRegistry.cs:Zeile 382.
   bei org.dmxc.lumos.Kernel.Devices.DeviceBeam.getTypeInstance(IDeviceProperty prop) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Devices\DeviceBeam.cs:Zeile 245.
   bei org.dmxc.lumos.Kernel.DeviceProperties.AbstractDeviceProperty`1.getTypeInstance() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\DeviceProperties\AbstractDeviceProperty.cs:Zeile 250.
   bei org.dmxc.lumos.Kernel.PropertyValue.PropertyValue`1..ctor(AbstractDeviceProperty`1 prop, Int64 id) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\PropertyValue\PropertyValue.cs:Zeile 54.
   bei org.dmxc.lumos.Kernel.PropertyValue.PropertyValue`1..ctor(AbstractDeviceProperty`1 prop) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\PropertyValue\PropertyValue.cs:Zeile 46.
   bei org.dmxc.lumos.Kernel.DeviceProperties.AbstractDeviceProperty`1.getValueInstance() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\DeviceProperties\AbstractDeviceProperty.cs:Zeile 65.
   bei org.dmxc.lumos.Kernel.Devices.DeviceTools.<createPropertySceneEntries>d__1.MoveNext() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Devices\DeviceTools.cs:Zeile 34.
   bei System.Linq.Enumerable.<SelectManyIterator>d__17`2.MoveNext()
   bei org.dmxc.lumos.Kernel.Devices.DeviceTools.CreateInitializationScene(IDevice device) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Devices\DeviceTools.cs:Zeile 19.
   bei org.dmxc.lumos.Kernel.Project.DeviceManager.ReinitDeviceBaseline(IDevice device) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Project\DeviceManager.cs:Zeile 739.
   bei org.dmxc.lumos.Kernel.Project.DeviceManager.OnDeviceAdded(IDevice d) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Project\DeviceManager.cs:Zeile 625.
   bei org.dmxc.lumos.Kernel.Project.DeviceManager.<org.dmxc.lumos.Kernel.Run.IManager.initialize>b__132_1(Object o, ProjectResourceEventArgs`1 args) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Project\DeviceManager.cs:Zeile 1064.
   bei org.dmxc.lumos.Kernel.Project.ProjectResource`1.OnItemAdded(ProjectResourceEventArgs`1 args) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Project\ProjectResource.cs:Zeile 213.
   bei org.dmxc.lumos.Kernel.Project.ProjectResource`1.ProjectContainer_ItemAdded(Object sender, ProjectContainerEventArgs`1 e) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Project\ProjectResource.cs:Zeile 189.
   bei org.dmxc.lumos.Kernel.Project.ProjectContainer`1.OnItemAdded(T item) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Project\ProjectContainer.cs:Zeile 243.
   bei org.dmxc.lumos.Kernel.Project.ProjectContainer`1.Load(LumosResource data, LumosIOContext context) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Project\ProjectContainer.cs:Zeile 216.
   bei org.dmxc.lumos.Kernel.Project.Project.loadProject(LumosIOContext context) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Project\Project.cs:Zeile 230.org.dmxc.lumos.Kernel.Exceptions.ProjectLoadException: Errors in Project
   bei org.dmxc.lumos.Kernel.Project.ProjectManager.loadProject(String filename, Stream inputStream, String sessionName, Boolean loadId) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Project\ProjectManager.cs:Zeile 312.

Außerdem fliegt auch noch eine weitere Exception, wenn man das leicht angepasste zweite DDF verwendet.

org.dmxc.lumos.Kernel.Exceptions.XmlParseException: Attribute "caption" in Node "step" missing
   bei org.dmxc.lumos.Kernel.HAL.Handler.RawDMXStepHandlerNode.parseXmlNode(XmlNode ddfnode) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\HAL\Handler\Generic\RawDMXStepHandlerNode.cs:Zeile 105.
   bei org.dmxc.lumos.Kernel.HAL.Handler.HandlerRegistry.ParseXmlTree(DDFParseContext context) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\HAL\Handler\HandlerRegistry.cs:Zeile 143.
   bei org.dmxc.lumos.Kernel.HAL.Handler.HandlerRegistry.parseXmlFile(DDFParseContext context) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\HAL\Handler\HandlerRegistry.cs:Zeile 58.
   bei org.dmxc.lumos.Kernel.Devices.DeviceBeam..ctor(IDevice parentDevice, UInt32 beamNumber, DDFParseContext context) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Devices\DeviceBeam.cs:Zeile 92.
   bei org.dmxc.lumos.Kernel.Devices.DMXDevice.parseDDF(XmlDocument ddf, String filename) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Devices\DMXDevice.cs:Zeile 406.
   bei org.dmxc.lumos.Kernel.Devices.DMXDevice.LoadXML(String ddfFile) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Devices\DMXDevice.cs:Zeile 170.
   bei org.dmxc.lumos.Kernel.Devices.DMXDevice.set_DDFSourceFile(String value) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Devices\DMXDevice.cs:Zeile 115.
   bei org.dmxc.lumos.Kernel.Devices.DMXDevice.setParameterInternal(DeviceParameter parameter, Object value, Object& valueToSend) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Devices\DMXDevice.cs:Zeile 310.
   bei org.dmxc.lumos.Kernel.Devices.AbstractDevice.setParameter(DeviceParameter parameter, Object value) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Devices\AbstractDevice.cs:Zeile 1000.
   bei org.dmxc.lumos.Kernel.Devices.AbstractDevice.<>c__DisplayClass121_0.<org.dmxc.lumos.Kernel.Resource.ILumosSaveable.loadFromManagedTree>b__0(String s, Object o) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Devices\AbstractDevice.cs:Zeile 670.
device-->functions-->rawstep-->step

Der Wertebereich der Pan- und Tilt-Eigenschaften von Geräten sollte jeweils mittels einer Ober- und Untergrenze eingeschränkt werden können.

Immer wieder kommt es vor, das man einen Graphen im Input Assignment eines Users debuggen muss. Hierfür braucht man zwingend ein Bild. Allerdings ist das bei komplexeren Graphen manchmal schlecht bis gar nicht zu lesen. Daher wäre es für diese Arbeit sehr wichtig, wenn man einfach die anzuzeigenden Nodes auswählen könnte, dann einen Rechtsklick auf einen der Nodes machen könnte und das als Bild exportieren könnte (egal ob png, jpeg etc.). Hierbei sollte die Auflösung immer so sein, dass man den Text auf jeden Fall lesen kann (also durchaus eine Standardaufösung möglich, dann wird halt das Bild etwas größer). Am Besten wäre es, wenn man auch noch den Ausschnitt mit den Inputs und Outputs der ausgewählten Nodes drauf hat. Wählt man keinen Node aus und exportiert das Bild, dann wird einfach der ganze Graph gespeichert.

Mit einem Doppelklick werden ja Geräte eingeschaltet (Dimmer auf 100% und Shutter auf). Allerdings gibt es keine Maus- und/oder Tastenkombination, mit der man “Nox” betätigen kann. Das würde dann auch im Programmer landen, was für manche Situationen (Theater) sinnvoll ist. Für andere aber nicht. Daher bräuchte es auch noch eine dritte Kombination, um entweder die Dimmer- und Shutter-Werte oder alle Parameter für das entsprechende Gerät aus dem Programmer zu löschen.