Bugtracker DMXControl 3

Der Export eines gesamten Projekts mit mehreren Versionen schlägt mit einem Timeout fehl. Das liegt an den bisher nicht verwendeten Deadlines im gRPC. Das muss refactored werden.

Es sollte im Input Assignment einen Node geben, über den man die Info erhalten kann, ob gerade eine Projekt Warnung aktiv ist und auch die Info welche. U.A. könnte man auch für jede Warnstufe alle entsprechenden Warnungen als Liste ausgeben (noch zu diskutieren). So könnte man auf die verschiedenen Warnstufen z.B. auf dem Softdesk entsprechende Warnungen anzeigen

Die Midi-Implementierung ist buggy und sollte zumindest auf einen Stand gebracht werden, dass sie an sich funktioniert. Dieses Ticket sammelt verschiedene Dinge, die mir aufgefallen sind und die ich fixe (als Dokumentation zum Testen).

1. Das Midi-Feedback ist doppelt, sprich einmal über den Midi-Teil selbst und einmal über das IA. So lässt sich die Rückmeldung über das IA aktuell effektiv nicht durchführen weil der rückgemeldete Wert aus dem IA teilweise über die Midi-Teil-Interne Rückmeldung überschrieben wird. Das führt dazu, dass der Status eine laufenden Cuelist nicht korrekt mit einem hellen Button symbolisiert werden kann
2. Der Midi-Teil aktualisiert aktuell bei einer Midi-Message am Input (egal ob von einem Button, Fader oder Encoder) alle definierten Buttons statt nur das entsprechende Control. Das führt in Verbindung mit nachfolgendem Problem zu “Geisterauslösung”
3. Aktuell sind Input- und Feedback-Wert zu einem Wert zusammengefasst (zumindest bei Buttons, bei anderen Controls TBC). Das entspricht nicht ganz der Erwartung, weil so unter gewissen Umständen (bei einem Update des Buttons am Input, siehe z.B. vorherigen Punkt) zu einer falschen Auslösung kommen kann. Daher sollte es getrennte Pfade für Input und Output geben

Laut Code sollten x und y vom Typ double sein (was auch Sinn ergibt). Wenn man aber versucht, einen Fload-Wert in den Eigenschaften des Nodes in die Zellen für x und y einzutragen, meckert DMXC, dass der Wert keinem gültigen Int32 entspricht. Wurde da zu viel optimiert? Erwartet wird, dass an dieser Stelle direkt Float-Zahlen eingegeben werden können.

Der neue Chaser-Effekt hat Probleme bei Gruppen in Gruppen mit der Einstellung “Parallel Groups”. Dabei flackert er, als ob die Geschwindigkeit “unendlich” wäre. Alle anderen Modi funktionieren.

Voraussetzung / Umgebung

• Moving Head / Scanner hat zwei Goboräder
• 2 Cuelists, die auf LTP stehen

Reales Verhalten

Wird ein Gobo auf Goborad 1 durch Cuelist A gesetzt und anschließend ein weiteres Gobo auf Goborad 2 durch Cuelist B, so wird gleichzeitig das Goborad 1 auf “Offen” gesetzt. Ein vergleichbares Verhalten tritt auf, wenn zuerst Goborad 2 gesetzt wird und anschließend Goborad 1. Dann wird Goborad 2 auf “Offen” gesetzt.

Erwartetes Verhalten

Werden die Gobos explizit auf einem Goborad gesetzt, ist die Annahme, dass explizit dieses Gobo auf diesem Rad gesetzt werden soll. Daher darf es dadurch keine Auswirkungen auf das andere Goborad haben und eine andere Cuelist sollte das andere Rad unabhängig setzen können.

Anmerkung

Im Anhang ist ein Testprojekt, mit dem alle möglichen Kombinationen von Goborad 1 und 2 getestet werden können

Folgendes vorgehen:

1. 8 Scheinwerfer anlegen inkl. Gerätegruppe
2. In die Stage View gehen und die Gerätegruppe auswählen
3. Chaser Effekt auf den Dimmer legen
4. Chaser Effekt über das “X” im Device Control entfernen

⇒ Der letzte eingeschaltete Scheinwerfer bleibt an und dessen Dimmer wird nicht wie erwartet auf 0 zurück gesetzt.

s.o.

s.o.

Wie im Video in  FS#4657  zu sehen ist, haben die “Back”-Button im Cuelist Editor und in den Executoren ein unterschiedliches Verhalten. Beim Back-Button im Cuelist Editor ist es ein “Go Back”, sprich die vorherige Cue wird selektiert und ausgeführt. In den Executoren ist es ein “Back”-Button ohne die “Go”-Komponente. Wir sollten besprechen, ob das nicht vereinheitlicht werden soll oder die jeweils andere Variante bei den Executoren und dem Cuelist Editor als weitere Varianten verfügbar gemacht werden.

Alle Effekte und Filter funktionieren nach dem Prinzip, dass sie einen gewissen eigenen Wert auf den Basiswert der Geräteeigenschaft aufaddieren. Alle Effekte und Filter? Nein, einen gibt es, der anders arbeitet: Der Random Value Filter. Der Min-Wert des Random Value Effekts überschreibt hart den Basiswert. Das ist inkonsistent zu den anderen Effekten und Filtern. Der Min-Wert wird aber auch nicht benötigt, weil man ja den Basiswert hat. Daher sollte der Min-Wert Eintrag in dem Effekt entfernt werden und dafür zur Abwärtskompatibilität den Min-Wert in den Basiswert kopieren. Man müsste überlegen, ob letzteres ok ist oder ob man entsprechend einen Eintrag in die ToDos machen sollte.

Wie Patrick sagt, sind die CTO Filter trotzdem Farbfilter. Allerdings macht es hier keinen Sinn, diese Filter mit in die automatische Farbmischunng zu nehmen. Ergo sollten einzelne Farbfilter von der automatischen Farbwahl ausgeschlossen werden können und nur bei einer direkten Anwahl auswählbar sein.

Im angehängten DDF habe ich sowohl Farbkanäle als auch 2 Farbräder (nach dem Hinweis von Patrick, dass die virtuellen CTO-Filter eher ein virtuelles Farbrad sind als ein Farbkorrektur-Kanal). Das DDF kann ich so ohne Probleme in DMXC laden. Mit dem DDF funktioniert es, die Farbkanäle anzusteuern. Auch der Support-Kanal steht da auf dem richtigen Wert. Es funktioniert ebenfalls, die virtuellen Rainbow-Effekte durchlaufen zu lassen (auch hier wird der Support-Kanal korrekt gesetzt). Es funktioniert aber nicht, die CTO-Filter auf dem einen virtuiellen Farbrad bzw. die Farben auf dem anderen virtuellen Farbrad anzusprechen. Der entsprechende Kanal wird zwar korrekt gesetzt, der Support-Kanal wird aber nicht gesetzt und bleibt auf seinem bisherigen Kanalwert.

Edit: Ich habe das DDF mal mit dem hal-Parameter aus  FS#4639  ergänzt und noch einmal angehängt

Aktuell kann die Farbe eines Buttons nur beim Lumos Style aus dem Input Assignment heraus gesetzt werden. Andere Styles haben wieder andere Funktionen, die sonst nicht vorhanden sind. Das muss dringend vereinheitlicht werden und der Style sollte wirklich nur das Erscheinungsbild und nicht auch die Funktionalität beeinflussen.

Beim Duplizieren einer Cuelist, bei der Tracking deaktiviert ist, wird diese Einstellung nicht in die zweite Cuelist übernommen. Der Haken ist zwar nicht gesetzt, aber trotzdem reagiert die Cuelist wie eine mit aktivem Tracking (siehe Diskussion Arne ⇔ JP)

Damit die Übersetzung (u.a. die T-Klasse) auch in anderen Teilen von Lumos und anderen Programmen wie z.B. dem DDFCreator verwendet werden kann, müssen die Übersetzungsfunktionen in eine separate Library (und evtl. separates NuGet-Paket) ausgelagert werden.

Der Color Scroll Filter bietet aktuell keine Einstellungsmöglichkeit für die Breite der Elemente.

Außerdem kann er nur die Colorlist in einer Art und Weise durchspielen. Er sollte die Einstellungsmöglichkeiten des Color Chasers für Play Mode und Index Offset erhalten.

Das Kommando “shutdown” ist eigentlich sehr unüblich für Konsolenanwendungen. Gebräuchlicher sind “exit” oder “close”. Diese sollten als weitere Möglichkeiten hinzugefügt werden.

Im Cuelist Editor gibt es Tooltips, die angezeigt werden, obwohl die Tooltips im Menü deaktiviert sind. Hierbei handelt es sich um die Tooltips der Spalten der Cue-Tabelle (mit der Maus über dem Titel der Spalte hovern, z.B. bei Trigger Value).

Edit: Habe noch etwas ausprobiert. Es scheint so, als ob der Tooltip nach dem Neustart wieder angezeigt wird. Dann muss erst wieder der Tooltip aktiviert und anschließend wieder deaktiviert werden, damit er wieder ausgeblendet bleibt.

Steuert man mit einer Matrix mehrere Geräte oder Sub-Matrizen an, so bleibt die Ausgabe beim Löschen von Werten aus dem Programmer weiter bestehen. Folgendermaßen lässt sich das Problem reproduzieren:

1. Lege 4 Geräte an
2. Lege eine 4×1 Matrix an
3. Patche die Geräte auf die Matrix
4. Wähle die Matrix in der Stage View aus
5. Klicke auf den Lumos Button
6. Stelle eine Farbe für die Matrix ein
7. Gehe nun in den Programmer und lösche den Farbwert für die Matrix

Problem: Die LED-Scheinwerfer behalten nun den letzten Farbzustand, obwohl kein Wert mehr gesetzt ist. Sie gehen erst aus, wenn man den Programmer über “Clear” leert

Erwartetes Verhalten: Die Matrix verhält sich hier wie eine Art Gerätegruppe, wenn also die Werte der Matrix gelöscht werden, muss die Ausgabe der zugeordneten Geräte auch gelöscht werden

Folgendes Vorgehen:

1. Erstelle eine Gruppe mit 10 Generic Dimmern
2. Stelle für die Gruppe einen Dimmerwert von 20 ein
3. Wähle je einen Scheinwerfer aus und setze den Dimmerwert für diese auf 60 und 90
4. Speichere diese Szene in einer Cue
5. Editiere diese Cue über “Edit in Programmer”

Erwartetes Verhalten: Alle Geräte bis auf die separat editierten zeigen in der Stage View den Helligkeitswert 20, die anderen beiden 60 und 90

Tatsächliches Verhalten: Alle Geräte zeigen in der Stage View den Dimmerwert 20 an. Auch die DMX-Ausgabe suggeriert, dass für alle Scheinwerfer der Wert von 20 gespeichert ist und die zusätzlich Werte werden bei der Ausgabe in der Stage View und der DMX Ausgabe ignoriert. Dadurch fällt das Editieren von Cues schwer.

Ein leerer DisplayName in einem Control eines Softdesks führt dazu, dass das Projekt nicht mehr geladen werden kann und sich die GUI mit einer NPE verabschiedet.

Fügt man einen Chaser ein, setzt dessen Duration auf einen Speedmaster und setzt dann die Geschwindigkeit des Speedmasters auf 0 BPM, fliegt eine Exception:

00:15:51 WARN  SceneFadeTicker - Exception triggering Item: Der Wert für einen Int32 war zu groß oder zu klein.
System.OverflowException: Der Wert für einen Int32 war zu groß oder zu klein.
   bei System.Convert.ToInt32(Double value)
   bei org.dmxc.lumos.Kernel.PropertyValue.Filter.ChaserFilter.doFilter(IPropertyValue input, Int64 timeInMs, Int64 delta) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\PropertyValue\Filter\ChaserFilter.cs:Zeile 187.
   bei org.dmxc.lumos.Kernel.PropertyValue.Filter.AbstractEffectFilter.doFilter(IPropertyValue input) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\PropertyValue\Filter\AbstractEffectFilter.cs:Zeile 53.
   bei org.dmxc.lumos.Kernel.PropertyValue.PropertyValue`1.getPropertyValue(Int64 timeInMsAbs) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\PropertyValue\PropertyValue.cs:Zeile 379.
   bei org.dmxc.lumos.Kernel.PropertyValue.PropertyValue`1.setOutputTime(Int64 timeInMsAbs, Double delayPercent, Double fadePercent, Boolean fadeIn, IMixerRegister register, IProcessable fader) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\PropertyValue\PropertyValue.cs:Zeile 323.
   bei org.dmxc.lumos.Kernel.Scene.Fade.FadeDecorator.setOutputTime(Int64 timeInMsAbs, Double delayPercent, Double fadePercent, Boolean fadeIn, IMixerRegister register, IProcessable fader) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Scene\Fade\FadeDecorator.cs:Zeile 97.
   bei org.dmxc.lumos.Kernel.Scene.Delay.DelayDecorator.setOutputTime(Int64 timeInMsAbs, Double delayPercent, Double fadePercent, Boolean fadeIn, IMixerRegister register, IProcessable fader) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Scene\Delay\DelayDecorator.cs:Zeile 37.
   bei org.dmxc.lumos.Kernel.Scene.Fade.AutoFadeDecorator.triggerFade() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Scene\Fade\AutoFadeDecorator.cs:Zeile 33.
   bei org.dmxc.lumos.Kernel.Scene.Fade.AbstractValueFadeDecorator.triggerFade(Boolean& deregister) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Scene\Fade\AbstractValueFadeDecorator.cs:Zeile 191.
   bei org.dmxc.lumos.Kernel.Scene.Fade.AbstractFadeDecorator.trigger() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Scene\Fade\AbstractFadeDecorator.cs:Zeile 63.
   bei org.dmxc.lumos.SceneFadeTicker.processBag(ProcessableTickerBag bag) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Scene\SceneFadeTicker.cs:Zeile 236.

Es wäre gut, wenn der CounterNode noch um einen “Init Value”- und einen “Reset”-Eingang erweitert wird. Aktuell bringt der Counter nämlich wenig, weil man nicht bestimmen kann, ab welchem Wert er zählen soll. Hierfür ist dann auch der Reset-Eingang, um den Counter wieder auf den “Init Value” Wert zurück zu setzen. Erst mit so einem Counter kann man z.B. bei einem Beat entsprechend zählen oder erst eine gewisse Anzahl von Peaks.

Läd man das angehängte Projekt, erscheint eine Fehlermeldung im Log und das Bild mit der Waveform wird nicht angezeigt.

Sowohl bei einer “Drüberinstallation” als auch bei einer Neuinstallation taucht der Fehler

2019-11-17 23:52:35,789 [Main] ERROR org.dmxc.lumos.Kernel.Scene.Fanning.FannedValueManager - 
System.IO.FileNotFoundException: Die Datei oder Assembly "Jace, Version=0.9.0.0, Culture=neutral, PublicKeyToken=null" oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.
Dateiname: "Jace, Version=0.9.0.0, Culture=neutral, PublicKeyToken=null"
   bei LumosLIB.Tools.LumosTools.IsParameter(Object test)
   bei org.dmxc.lumos.Kernel.Scene.Fanning.FannedValueManager.getContainerInstance(String op, EUiValueType uitype, Object[] paras) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Scene\Fanning\FannedValueManager.cs:Zeile 342.

WRN: Protokollierung der Assemblybindung ist AUS.
Sie können die Protokollierung der Assemblybindungsfehler aktivieren, indem Sie den Registrierungswert [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) auf 1 festlegen.
Hinweis: Die Protokollierung der Assemblybindungsfehler führt zu einer gewissen Leistungseinbuße.
Sie können dieses Feature deaktivieren, indem Sie den Registrierungswert [HKLM\Software\Microsoft\Fusion!EnableLog] entfernen.

im Kernel auf. Siehe die Logs.

Packe ich sowohl den Start-Befehl als auch den Stop-Befehl für eine Audiocue in eine Cuelist und springe per GoTo zu einer Cue nach den Stop-Befehl, wird die Audiocue trotzdem abgespielt. Erwartetes Verhalten wäre hier, dass die Audiocue nicht ausgeführt wird, da sie ja eigentlich schon beendet wird.

Selektiert man ein Gerät oder eine Gruppe in der Stage View und macht dann einen Doppelklick irgendwo in der Stage View (nicht auf dem Geräteicon selbst), geht das Gerät / die Gruppe an. Das sollte nicht so sein. Das funktioniert lustigerweise auch, wenn man (nachdem man ein Gerät selektiert hat) in der Folge zuerst einen einzelnen Klick für die Deselektion und dann einen Doppelklick macht. Dann wird das Gerät schon deselektiert, wird aber danach trotzdem angeschaltet (solange das Device Control noch das Gerät anzeigt).

Erzeugt man eine Gruppe von Geräten und wendet ein Fanning zwischen zwei ParameterMastern z.B. auf den Dimmer an (also {ParameterMaster 1} < {ParameterMaster 2}), dann wird das Fanning nicht ausgeführt und es erscheint folgende Fehlermeldung im Kernel:

 ERROR AbstractSceneEntry - Error when getting fanned property values: Fanning not possible for that Type: System.String
 org.dmxc.lumos.Kernel.Exceptions.UnsupportedConvertionException: Fanning not possible for that Type: System.String
 bei org.dmxc.lumos.Kernel.Scene.Fanning.LinearFannedValue.getFannedValues(Int32 count) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Scene\Fanning\LinearFannedValue.cs:Zeile 78.
 bei org.dmxc.lumos.Kernel.Scene.Entry.AbstractSceneEntry.getFannedPropertyValue(IRealtimeTimestamp realTimestamp, Boolean includeDisabledDevices) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Scene\Entry\AbstractSceneEntry.cs:Zeile 462.
 bei org.dmxc.lumos.Kernel.Scene.Entry.AbstractSceneEntry.insertOutputValues(Dictionary`2 values, HALTimestamp timestamp, OutputValuesContext context) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Scene\Entry\AbstractSceneEntry.cs:Zeile 722.

Das lässt sich unter anderem mit folgenden Fannings reproduzieren:
<,>,<>,?,…

Interessanterweise ist das | Fanning nicht von dem Problem betroffen

Ändert man die Geschwindigkeit eines SpeedMasters, dann beginnt die Zeit bis zum ersten Beat von neuem. Das ist schlecht, denn damit steht die Cuelist, während man mit dem Fader im Master-Panel die Geschwindigkeit anpasst. Ändert sich die Geschwindigkeit kontinuierlich (z.B. durch einen leicht “wackelnden” Input), bekommt man die Cuelist komplett und dauerhaft zum Stehen. Ich hätte gedacht, dass der SpeedMaster die aktuelle Wartezeit bis zum nächsten Tick noch abwartet und dann beim Tick die Zeit bis zum nächsten Tick aus der aktuellen Geschwindigkeit berechnet. Da das natürlich bei sehr langen Wartezeiten bis zum nächsten Tick (z.B. bei 5BPM) auch entsprechend lange bis zum Tick braucht, kann man ja überlegen, ob man bei niedrigen BPM-Werten häufiger als nur bei den Ticks schaut, ob sich die Geschwindigkeit verändert hat und wenn ja entsprechend reagiert. Aber es gibt ja auch noch andere Möglichkeiten, das abzufangen.

Edit: Habe mal noch ein Video angehängt, in dem man das Problem sieht.

Die Vorschau der Audio-Datei oben rechts im AudioSelector ist CaseSensitive. Werden .wav-Dateien mit groß geschriebener Endung selektiert, erscheint keine Vorschau der Waveform.

Es wäre gut, wenn man die Lautstärke einer Audio Cue per Special Cue setzen könnte. Ähnlich wie bei normalen Cues wäre es auch gut, wenn man eine Fade-Time bestimmen könnte und die Lautstärke fadet beim Einblenden der Special Cue vom aktuellen Wert zum Zielwert der Special Cue.

Es wäre gut, wenn man über die Fade-Time beim Starten bzw. Stoppen eines Audio Cues die Sound-Ausgabe ein- bzw. ausblenden könnte. So ist dann eine Fade-Time von 0 der direkte Start bzw. Stop, während alle Fade-Zeiten >0 das ein- bzw. ausblenden verursacht (ähnlich wie bei einer normalen Cue mit Poperties)

Werden auf eine Gerätefunktion wie den Dimmer ein Effekt wie z.B. ein Sinus gelegt, dann wird im Programmer nur der Grundwert angezeigt. Klar wäre es übertrieben, im Programmer den Effekt zu visualisieren, aber es wäre gut, wenn es im Programmer eine Markierung bei den Einträgen gäbe, die eigentlich einen Effekt enthalten. So wäre klarer ersichtlich, dass ein gespeicherter Eintrag einer Gerätefunktion eigentlich komplexer ist.

Aktuell werden auch z.B. MP3 Dateien im AudioSelector (beim Hinzufügen in die Cuelist) angezeigt. Diese sollten ausgeblendet werden, da diese aktuell nicht unterstützt werden.

Wenn man Wave-Dateien mit dem AudioSelector in eine Cuelist einfügen will, dann werden nur Audio-Dateien angezeigt, bei denen die Dateiendung klein geschrieben ist (xxx.wav). Dateien mit groß geschriebenen Dateiendungen (xxx.WAV) werden nicht angezeigt.

Es gibt ja schon den “Stop all Cuelists”-Button links. Der ist fürs schnelle stoppen richtig und wichtig. Aber da Cuelists auch eine Releasetime haben können, fände ich einen “Release all Cuelists”-Button gut, mit dem man alle Cuelists “langsam” Stoppen kann. Prinzipiell könnte man das auch in den “Stp all Cuelists”-Button ähnlich der “Stop”-Button in den Cuelists integrieren, aber das könnte u.U. zu Verwirrungen führen.

P.S.: Muss nicht mehr in die 3.2

Ich habe zwei Cuelists angelegt. Eine mit LTP, in der ein Dimmerwert von 30% von Scheinwerfern gespeichert ist. Die zweite Cuelist steht auf HTP und die darin enthaltene Cue mit einer langen Einblendzeit legt nun einen Sinus-Effekt auf die Helligkeit der Scheinwerfer. Wenn ich nun die Cuelist “Helligkeit 30%, LTP” ausführe passt alles. Sobald ich aber nun auch noch Cuelist “Hellikeit Sinus, HTP” ausführe, flackert bzw. Springen die Dimmerwerte während dem Einblendvorgang der Cue. Sobald die Cue fertig eingeblendet ist, hört das Flackern wieder auf. Im Channel Overview sieht man, dass da wohl eine Berechnung noch nicht ganz passt, denn der Ausgabewert springt wie bei einem Überlauf nach unten und fadet dann wieder ein Stück ein (passend zum Sinus-Effekt). Im Anhang das Projekt und die Logs.

Hat ein Gerät die DMX-Adresse 16.512, lässt sich das Patching-Window nicht öffnen. Im GUI-Log steht folgender Fehler:

2019-05-27 12:58:14,157 [Main GUI] ERROR Lumos.GUI.GuiActions.ActionItemMetadata - Not catched Exception when invoking AIM: ActDeviceManager: Das angegebene Argument liegt außerhalb des gültigen Wertebereichs.
Parametername: address
System.ArgumentOutOfRangeException: Das angegebene Argument liegt außerhalb des gültigen Wertebereichs.
Parametername: address
   bei org.dmxc.lumos.Kernel.Devices.DMXAddress.FromInt(Int32 address) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\Kernel\Devices\DMXAddress.cs:Zeile 379.
   bei Lumos.GUI.Windows.NewDevice2.setDMXStartAddress(Int32 value) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Windows\ProjectExplorer\NewDevice\NewDevice2.cs:Zeile 565.
   bei Lumos.GUI.Windows.NewDevice2.refreshDMXStartAddress() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Windows\ProjectExplorer\NewDevice\NewDevice2.cs:Zeile 251.
   bei Lumos.GUI.Windows.NewDevice2..ctor(IEnumerable`1 devicesToAdd) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Windows\ProjectExplorer\NewDevice\NewDevice2.cs:Zeile 145.
   bei Lumos.GUI.Windows.NewDevice2..ctor() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Windows\ProjectExplorer\NewDevice\NewDevice2.cs:Zeile 71.
   bei Lumos.GUI.Windows.ProjectExplorer.TreeBranches.DeviceBranch.ShowDeviceManager_Click(Object sender, ActionItemMetadata meta, EMouseButtons buttons, Boolean down) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Windows\ProjectExplorer\TreeBranches\DeviceBranch.cs:Zeile 278.
   bei Lumos.GUI.GuiActions.ActionItemMetadata.Invoke(Object sender, EMouseButtons buttons, Boolean down) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\GUI\GuiActions\ActionItemMetadata.cs:Zeile 362.

Wenn größere Projekte (z.B. das für das Vereinstreffen) geladen sind, dann schlägt das Verbinden mit einem Kernel mehrfach fehl (Kernel lokal separat gestartet), bis endlich die Verbindung korrekt aufgebaut wird. Hierbei ist die Session allerdings schon im Kernel hinterlegt und eine entsprechende Warnung erscheint. Außerdem geht dann im weiteren Verlauf der Update-Button bei der Bearbeitung eine Cue nicht mehr.

Da der Programmer in einer Art Tabelle dargestellt wird, sollte das Mausrad auch eher für das vertikale Scrolling eingesetzt werden als für das Zoomen. Den Zoom würde ich stattdessen auf Strg+Maus-Scroll legen (wie in vielen anderen Anwendungen auch)

Bei vielen Einträgen im Programmer wird zwar die vertikale Scrollbar angezeigt, aber eine horizontale Scrollbar fehlt. So muss man erst mehrfach an verschiedenen Stellen heraus- und hereinzoomen, um diese Einträge sehen zu können. Wie im Bild zu sehen ist, sind Position und auch Teile der Dimmer-Spalte nach links geschoben. Ich habe aber keine Möglichkeit, diese zu erreichen, weder mit den Pfeiltasten, noch mit einer Scrollbar.

In meinem Programmer wird das Tabellengitter und die Tabelleneinträge von einander separiert angezeigt. Das sieht man vor allem, wenn man im Programmer zoomt. Da skallieren die Gitter mit einer anderen Geschwindigkeit wie der Inhalt. Werde heute Abend ein paar Bilder nachreichen.

Die Eingabefelder in den verschiedenen Spalten des Cuelist-Editor haben ein unterschiedliches Eingabeverhalten, vor allem, wenn man auf einen “wait”- oder “follow”-Trigger umschaltet. Bei der “wait”- bzw. “follow”-Time führt jeder Tastendruck sofort zu einer Eingabe, also das Feld wechselt in den “Edit-Modus” und der Inhalt wird mit der Eingabe überschrieben (wie erwartet). Die Standard-Einheit ist Sekunde. Bin ich im “Edit-Modus” des Feldes, verschiebe ich mit den Pfeiltasten den Marker (wie erwartet). Ich hätte aber erwartet, dass man mit Shift+Pfeiltaste Bereiche markieren kann, um sie mit einem Tastendruck zu ändern. Eingabefelder in der “fade”- und “delay”-Spalte verhalten sich wiederum ganz anders. Ist das Feld selektiert und man drückt eine Taste, so wechselt das Feld nur in den “Edit-Modus”, ohne den Inhalt zu überschreiben (nicht erwartetes Verhalten). Die Standardeinheit ist Millisekunde. Ist man im “Edit-Modus” und drückt die Pfeiltaste, um den Marker zu verschieben, wird der Edit-Modus stattdessen verlassen und das nächste Feld wird selektiert (nicht erwartetes Verhalten). Hier sollten die Eingabefelder an die in Windows üblichen Eingabeverhalten angepasst werden.

Editiert man den Namen einer Cue in einer Cuelist, setzt den Marker an die ganz linke Seite und drückt dann die Backspace-Taste, wird der nächste Buchstabe auf der rechten Seite gelöscht. Das erwartete Verhalten (wie in anderen Windows-Edit-Feldern) wäre, dass nichts passiert, weil man ja mit dem Marker schon an der ganz linken Seite ist. Befindet sich der Marker nämlich nicht an der linken Seite, ist das Verhalten wie üblich und es wird jeweils der nächste Buchstabe auf der linken Seite gelöscht.

Ich habe eine Gruppe von MHs mit Farbrad ausgewählt. Dieser Gruppe möchte ich folgendes Fanning über das DC geben

1;1;0.11#0.85;0;0.79#0;1;1

. Bei der Eingabe werden alle Scheinwerfer weiß und folgender Text steht in dem Feld:

Der Index war außerhalb des Arraybereichs.

Folgender Text steht im Kernel:

22:36:13 ERROR FannedValueManager -
System.IndexOutOfRangeException: Der Index war außerhalb des Arraybereichs.
   bei LumosLIB.Kernel.Scene.Fanning.AbstractFannedValueContainer`1.get_FanningValues() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\Kernel\Scene\Fanning\AbstractFannedValueContainer.cs:Zeile 83.
   bei org.dmxc.lumos.Kernel.Scene.Fanning.FannedValueManager.convertToValueInstance(Object value) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Scene\Fanning\FannedValueManager.cs:Zeile 199.

Das angehängte DDF führt bei der Colortemp zu einem Kernelfehler. Wenn nicht so, wie muss ein Feld, welches dem offenen Zustand entspricht, definiert sein?

20:03:52 ERROR ReflectionCommandFactory - TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht.
System.Reflection.TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht. ---> System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei org.dmxc.lumos.Kernel.HAL.Handler.Beam.ColortempHandlerNode.<>c.<getPropTypeInstance>b__9_1(AbstractValue h) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\HAL\Handler\Beam\ColortempHandlerNode.cs:Zeile 91.
   bei System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
   bei System.Linq.Enumerable.Min[TSource](IEnumerable`1 source)
   bei org.dmxc.lumos.Kernel.HAL.Handler.Beam.ColortempHandlerNode.getPropTypeInstance(IDeviceProperty prop) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\HAL\Handler\Beam\ColortempHandlerNode.cs:Zeile 91.
   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 748.
   bei org.dmxc.lumos.Kernel.HAL.Handler.HandlerDependency.<>c__DisplayClass24_0.<getTypeInstance>b__0(IPropertyHandlerNode n) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\HAL\Handler\HandlerDependency.cs:Zeile 303.
   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 357.
   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 303.
   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 379.
   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 445.
   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 379.
   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 247.
   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) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\PropertyValue\PropertyValue.cs:Zeile 45.
   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.OnDeviceAdded(IDevice d) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Project\DeviceManager.cs:Zeile 598.
   bei org.dmxc.lumos.Kernel.Project.DeviceManager.<org.dmxc.lumos.Kernel.Run.IManager.initialize>b__133_1(Object o, ProjectResourceEventArgs`1 args) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Project\DeviceManager.cs:Zeile 1009.
   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 192.
   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 168.
   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 222.
   bei org.dmxc.lumos.Kernel.Project.ProjectContainer`1.Add(T item, Boolean throwEvent) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Project\ProjectContainer.cs:Zeile 116.
   bei org.dmxc.lumos.Kernel.Project.ProjectResource`1.Add(T item) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Project\ProjectResource.cs:Zeile 206.
   bei org.dmxc.lumos.Kernel.Project.DeviceManager.addDevice(IDevice device) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Project\DeviceManager.cs:Zeile 584.
   bei org.dmxc.lumos.Kernel.Project.DeviceManager.createNewDevice(DeviceMetadata data, IDevice parentDevice) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Project\DeviceManager.cs:Zeile 474.
   bei org.dmxc.lumos.Kernel.Project.DeviceManager.createNewDevice(DeviceMetadata data) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Project\DeviceManager.cs:Zeile 445.
   bei org.dmxc.lumos.Kernel.Command.KernelCommandFactory.createDevice(DeviceMetadata m) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Command\KernelCommandFactory.cs:Zeile 1229.
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   bei System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
   bei System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   bei org.dmxc.lumos.Kernel.Command.ReflectionCommandFactory.CommandPropertyBag.Invoke(CommandParameterList list) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Command\ReflectionCommandFactory.cs:Zeile 60.
20:03:52 ERROR Command - Error while invoking Command: createDevice, Paras:
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei org.dmxc.lumos.Kernel.Command.ReflectionCommandFactory.CommandPropertyBag.Invoke(CommandParameterList list) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Command\ReflectionCommandFactory.cs:Zeile 68.
   bei org.dmxc.lumos.Kernel.Command.Command.execute(Object[] paras) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Command\Command.cs:Zeile 120.

Schiebt man in der Stage View ein Gerät links über den Nullpunkt der StageView hinweg, verschwindet das Gerätesymbol (siehe Anhang). Schiebt man es wieder zurück, erscheint es wieder.

Ich habe zwei Modi eines Gerätes in je einem DDF. Es wird aber nur ein DDF von den folgenden angezeigt. Erst, wenn ich im Dateinamen das " (Extended-Mode)” entferne, wird mir dieses DDF angezeigt.

Werden zwei verschiedene Radix Geräte mit verschidenen Pixel- bzw. Segment-Anordnungen ausgewählt, verursacht dies eine Fehlermeldung im Kernel (z.B. mit den beiden DDFs im Anhang).