Bugtracker DMXControl 3

Im folgenden thread ausführlich beschrieben:

https://forum.dmxcontrol-projects.org/index.php?thread/13008-channel-overview-werte/&pageNo=2#post110915

In meinen Posts vom 4.dezember 2017 ist ein Projekt angehängt und dazu die Vorgehensweise, den Fehler zu reproduzieren.

Der Fehlerdialog ist schlecht designed!

Mein Hintergrundbild in der Stageview wird nach dem Laden des Projekts nicht angezeigt.

Seltsamerweise wird es, nachdem ich in Windows einmal in den Energiesparmodus geschaltet und den Laptop dann wieder eingeschaltet habe, angezeigt.

Für Effectwheel die gleiche Systematik einbauen wie für Gobowheel (Zusammenfassen der Eigenschaften mit Subproperties)

Referenz:  FS#3089  (Screenshot unten in den Comments)

Wenn man während einer laufenden Cuelist Kanalwerte anpasst, springt der Wert bei einer Änderung durch die Cuelist zurück auf den letzten von der Cuelist gesetzten Wert und fadet von dort zum neuen Wert.

Beispiel:
Generic Dimmer, Cuelist mit 2 Cues: Dimmer 100% und Dimmer 0%, Cuelist auf “Priority update on Go” und Programmer-Priority auf Normal

Fall 1: Änderungen vor Start der Cuelist
Über Programmer Dimmer auf 50% - Dimmer 50%
Cue 1 (Dimmer 100%) → Dimmer fadet von 50% auf 100% (So soll es sein)

Fall 2: Änderungen während laufender Cuelist
Cue 1 (Dimmer 100%) → Dimmer 100%
Über Programmer Dimmer auf 50% → Dimmer 50%
Cue 2 (Dimmer 0%) → Dimmer springt zurück auf 100% (Cue 1) und fadet von dort auf 0% (So sollte es nicht sein)

https://forum.dmxcontrol-projects.org/index.php?thread/13013

Trägt man ein Fanning in die Go-To-Time, Go-Back-Time und Release-Time ein, so wird dies zwar akzeptiert und auch gespeichert. Der Kernel verwendet aber nur die erste Zahl des Fannings als entsprechende “Arbeitszeit” und ignoriert das Fanning komplett.

Hier sollte entweder eine Fehlermeldung aufkommen, dass eine solche Eintragung nicht zulässig ist oder dieses Feature unterstützt werden.

Ich habe gerade im Forum das Thema Versionierung und Art der Speicherung im Forum gefunden

https://forum.dmxcontrol-projects.org/index.php?thread/12810-vorschlag-umbau-der-projekt-speicherverwaltung-in-dmxc3/

Dies hier mal als Ticket, damit das nicht in Vergessenheit gerät.

Relative Änderungen (vor allem bei Bewegungen) sollten in Cues speicherbar sein. Dies wird benötigt, um einen Bewegungseffekt in einer Cuelist zu erstellen und mit einer anderen Cuelist dann die eigentliche Position vorzugeben. So ist man nochmal deutlich freier, was das Wiedergeben von gespeicherten Effekten angeht. So könnte man beispielsweise mit einer Cuelist die “Position” eines Effekts vorgeben und dann mit einer zweiten Cuelist den Eigentlichen Effekt (z.B. einen Kreis). Gerade wenn man mehrere Positionen hat, an denen man Bewegungen darstellen möchte, muss man nicht für jede Position erneut alle Bewegungen in Cuelists erstellen sondern nur eine neue Cue in einer Cuelist mit der weiteren Position. Außerdem wären dann auch Überlagerungen wie beispielsweise als Position eine Kreisbahn, auf die dann relativ ein weiterer Kreis aufgeprägt wird etc.

Damit der Installations-Manager die Plugins für DMXControl 3 automatisch in die richtigen Verzeichnisse kopieren kann, muss eine Hilfsdatei erstellt werden, dessen Inhalte es zu definieren gilt. Folgende Informationen könnten möglicherweise hilfreich sein:

• Art des Plugins (Kernel, GUI)
• Angabe der Verzeichnisse der Dateien
• Author
• Plugin-Version
• kompatible DMXControl-Version
• Checksumme für die im ZIP-Archiv enthaltenden Daten

Vergleichbar mit dem colorwheel, das die RGB-channels setzt, bzw. wie amber & co mittels Rampen definiert werden.
Steuert ein (Schiebe-)Regler für die Farbtemperatur die channels für WW und CW.

vg Norbert

Die Möglichkeit einbauen, dass alle Eingaben in den Programmer gefaded werden.

Highlight, Blackout, Preset auch.

Ein cooles und hilfreiches Feature wäre, wenn der Midi-Part die Funktion enthalten würde, einen Midi-Controller “mehrfach” belegen und am Ende in den einzelnen Layouts springen zu können.

Also zum Beispiel ein Layout für bewegtes Licht, eines für LED-PARs und eines für konventionelles Weißlicht. Das Wechseln des Layouts könnte im besten Fall auch mit der Zuordnung von Buttons auf die Layouts gelöst werden.

Beispiel:
Cuelist mode: once
Cue durchklicken bis auf zur letzten Cue. Dann Mode wechseln auf Loop. Cuelist beendet trotzdem.

Oder umgekehrt: Mode loop. Bis zur letzten Cue durchklicken. Mode ändern auf Once. Weiter auf Go drücken. Liste startet trotzdem von vorne.

Bei externen “Controls”, die kein Feedback erlauben (z.B. nicht motorisierte Fader, Potis, DMX-In), gibt es das Problem springender Werte, wenn sich Werte in der Software ändern, aber natürlich nicht am Control selbt. Fasst man das Control das nächste mal an, würde der Wert einfach auf den zuletzt am Control eingestellten Wert springen.
Um das zu umgehen, gibt es z.B. bei der MidiBox verschiedene Modi, die man einstellen kann:

Normal, Snap, Relative, Parallax
http://www.ucapps.de/midibox_tutorial.html (Nach “Normal Mode” suchen)

Diese Einstellung auch in DMXC zu haben (z.B. für DMX-In, wo es prinzipiell kein Feedback gibt, also auch das Pult dieses Verhalten nicht implementieren kann) wäre für mich sehr sinnvoll.
Wahrscheinlich reicht es, das pro MIDI- oder DMX-In-Device konfigurieren zu können, also nicht unbedingt für jedes Control einzeln.

Itemlist Objekte können nicht kopiert/eingefügt werden

Autoprepare funktioniert nur, wenn der Dimmer und der Shutter in der ersten Cue einer Cuelist auf 0 bzw. closed gespeichert werden. Dadurch kann man aber AP in der ersten Cue nicht verwenden und man muss wieder eine zusätzliche Preparation-Cue einfügen. Wenn aber der aktuelle Gerätezustand als virtuelle 0. Cue behandelt wird, kann auch die erste Cue von AP profitieren. Wenn dabei auch die Triggertime berücksichtigt wird, macht das auch bei der ersten Cue in einer Cuelist nichts aus. Außerdem löst man noch frei Haus zusätzlich das Problem, dass man beim Einblenden eines LED-Scheinwerfers jedes mal die Fadetime der Farbe auf 0 setzen muss, damit das sauber aussieht.

Unter dem Ticket  FS#2680  hatte ich vorgeschlagen, den Syntax im Device Control derart zu erweitern, um eine Cue mit folgender Lichtstimmung etwas einfacher programmieren zu können:

• rot, rot, rot, blau, blau, weiß

Da der seiner Zeit vorgeschlagene Syntax möglicherweise zu schwierig ist, kam mit beim Programmieren an einem aktuellen Projekt von mir der entsprechende Gedanke, auch beim Group Handling alternierende Fannings zuzulassen. Um die gezeigte Lichtstimmung zu programmieren, wären folgende Eingaben erforderlich:

• Device Control: 255; 0; 0 # 0; 0; 255 # 255; 255; 255
• Group Handling, Modus Concat Group: 3 # 2 # 1

Lade ich DDFs über die direkte Anbindung in DMXControl 3 aus der DDFLib herunter, werden die XML-Dateien nicht in das klassische Namenschema HERSTELLER GERÄT (MODE) umbenannt, sondern verbleiben im DDFLib-Schema, zum Beispiel DDF-001215.xml.

Getestet mit Build 1492

Ändere ich bei einer aktiven Cuelist während der Ausführung eines Fades die Fadezeit, stoppt die Cuelist.

Der Button im linken Schnell-Menü sollte kontextsensitiv sein. Sprich der Name der aktuellen Cue / des aktuellen Presets sollte angezeigt werden.

Aktuell wird der Kreis nur kontinuierlich in einer Richtung abgefahren. Einen Ausschnitt wie zum Beispiel einen Bogen kann man aktuell nicht fahren. Daher schlage ich die folgenden Erweiterungen für den Kreis-Effekt vor, um eben auch Teilkreise und Ellipsen fahren zu können:

• Startwinkel (bei AutoCAD ist 0° immer bei 3:00 Uhr und dann gegen den Uhrzeigersinn zunehmend)
• Endwinkel
• Index
• Fahrrichtung (forward, backward, bounce)

Ich stelle mir einen neuen Effekt vor der einen Stern mit n Spitzen erstellt. Der Effekt ließe sich über folgende Parameter manipulieren:

Variante 1: realen Sternen / Design-Sternen

• Anzahl Spitzen, wobei das Minimum bei 3 liegt
• Innerer Radius
• Äußer Radius
• Index
• Phase
• Frequenz

Variante 2: Sternpolygon

• Anzahl Spitzen, wobei das Minimum bei 5 liegt
• Äußer Radius
• Fahrweise (nur außen oder “durch die Mitte” bei zusammenhängenden Sternpolygonen)
• Index
• Phase
• Frequenz

Geprüft mit Build 1602

Im Rahmen der Vorbereitung der Video-Tutorials kam nach einer Diskussion zu den Default-Werten der Cuelists der Wunsch auf, die Optionen

• Use cue time as back time
• Use cue time as goto time

per Default auf true zu setzen. Für einen Einsteiger ist unter Umständen auf den ersten Blick nicht ersichtlich, dass hier für die Cuelist globale alternative Zeiten gelten, wenn man direkt zu einer Cue springt.

Temp-fader für Scenenlisten

Wirkt wie der intensety-master aber auf alle Propertys

{Blub 1} > {Blub 2} führt zu Exception

Ich übergebe dem node eine DeviceID/BeamID und bekomme am Ausgang den aktuellen Wert des in den Parameter ausgewählten Propertys zurück
So kann mann diese werte im InputAssignment benutzen und bsp. eine Matrix als Bitmap an Buttons senden

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.

Ein Kontextmenu für die Windows wie “Project Explorer”,”Channel Overview” usw. erstellen um diese mit “Rechtsklick”→“Schließen” auf deren Reiter schließen zu können.

Export and import App Settings as zip archive. (backup)

Es sollte die Möglichkeit geben einen Wert einer Eigenschaft, z.B. Intensität von Kreis 1 in allen ausgewählten Cues zu ändern. Die solte bedingt erfolgen: Replace Where Value = 80 With 60, oder so.

Hy,

es fehlt irgendwie der Restart-Befehl im Kernel.

Das wäre sehr hilfreich, fals der Kern irgendwie hängt, oder überladen ist.

Einfach “restart” eingeben und enter, und schon wird der Kernel runtergefahren, neugestartet und das Projekt wieder automatisch geladen.

Das ist viel einfacher als den Kernel Runterfahren zu müssen, ihn alleine wieder zu starten und dann noch das zu ladene project eingeben zu müssen.

Würde mich freuen, wenn ihr das einbaut.

Für mein Screenshot-Tool https://github.com/DMXControl/Screenshot starte ich des öfteren den DMXControl Kernel. Leider kann AutoHotkey den Text in der Konsole nicht lesen, sondern nur den Fenstertitel. Ich kann also automatisiert nicht feststellen, wann der Kernel für weitere Aktionen bereit ist.

Ich würde mir folgnde Änderung wünschen:
Während dem Betrieb lautet der Titel der Kernel-Konsole ja folgendermaßen:
> DMXControl Kernel V3.0.6.0 BETA 6 Datum Uhrzeit: Informationen

Ich würde mir wünschen, dass er während dem Startup noch irgendeinen zusätzlichen Text, z.B. starting enthält, der dann verschwindet, wenn der Kernel Startup fertig ist.
> DMXControl Kernel V3.0.6.0 BETA 6 starting Datum Uhrzeit: Informationen

Dann könnte ich automatisch darauf warten, bis das starting verschwindet, und weiß dann, dass der Kernel bereit ist.

Bei einigen Geräten unter anderem von Robe und Martin werden Goboshake, Goborotation und Goboindex in Abhängigkeit des zugeordneten Wertebereichs vom Gobokanal aktiviert. Dabei ist die Goboshake-Funktion meist immer als “Aufsatz” zur Goboindizierung oder Goborotation verfügbar. Diese Konstellation kann aktuell nicht vollständig und vor allem fehlerfrei abgebildet werden.

Um hier die DDFs an dieser Stelle zu vereinfachen, schlage ich folgenden Beispielcode vor (hier für den Robe Robin 600E Spot):

<step type="gobo" mindmx="4" maxdmx="7" val="Robe Robin 600e Spot Gobo 1 (Rad 1).png" caption="Gobo 1">
  <range handler="goboshake" mindmx="4" maxdmx="7" minval="0.0" maxval="0" />
  <step for="goboindex" mindmx="4" maxdmx="7">
    <range handler="goboshake" mindmx="60" maxdmx="69" minval="0.4" maxval="10" />
  </step>
  <step for="goborotation" mindmx="32" maxdmx="35">
    <range handler="goboshake" mindmx="130" maxdmx="141" minval="0.4" maxval="10" />
  </step>
</step>

Dabei wird innerhalb des step für goboindex bzw. goborotation entschieden, in welchem Wertebereich der Goboshake “aufgeschaltet” wird.

Alle anderen Definitionen sind von diesem Vorschlag erst einmal unberührt.

Ich habe mir gerade einen Regentropfeneffekt für LED-BARs gebaut, so wie es ihn auch bei LED-Eiszapfen beim Weihnachtsschmuck gibt. Hierbei kam mir der Gedanke, Cues innerhalb einer Cuelist zu gruppieren. Dies bedeutet, alle Cues mit einem gleichen Group Index werden immer in der Reihenfolge abgespielt, wie sie in der Cuelist sortiert sind. Dieses Feature kommt vornehmlich zum Tragen, wenn man den Wiedergabemodus Reverse, Bounce oder Random wählt. Beispiel:

• Block 1, Szene 1
• Block 1, Szene 2
• Block 1, Szene 3
• Block 2, Szene 1
• Block 2, Szene 2
• Block 3, Szene 1
• Block 3, Szene 2
• Block 3, Szene 3
• Block 3, Szene 4

Ist das Feature aktiviert, besteht die Cuelist effektiv nur aus vier Steps, der nämlich jeweils bei Szene 1 jedes Blocks beginnt.

Dieses Feature ist quasi eine Abwandlung der Möglichkeit mittels Befehlen andere Cuelists zu starten, die vielleicht etwas einfacher zu programmieren und vor allem zu pflegen ist, da sich alles innerhalb einer Cuelist abspielt. Man spart sich hier nämlich das erstellen der unterschiedlichen Cuelists sowie das Verknüpfen untereinander über die Befehle.

Speichert man ein Projekt mit Softdesk ab und öffnet es wieder fehlen einige (Immer andere) Input assignments

Ich hätte gerne die Möglichkeit, Presets per Softpult abzurufen.

So kann Live schnell z.B. eine auswahl von Geräten geändert werden,
ohne das für Auswahl der Geräte die gewünschte Änderung( Farbe/Gobo/Position) als CUE angelegt sein muss.

Für ein Softdesk Only Modus wäre es schön wenn man eine Art LCD Panel in Softdesk anlegen kann um Informationen darzustellen. z.B. Aktueller Manueller Beat.

Getestet mit Alpha 3, Build 11

Aktuell fehlt die oben genannte Funktion komplett. Diese sollte dann auch einfach über das Kontextmenü erreichbar sein.

Getestet mit Alpha 3, Build 11

Persönlich finde die aktuelle Arbeitsweise zum Auswählen der Controls im Softdesk sehr ungeschickt. Ich kann ein oder mehrere Controls nur über ein Auswahlrecht anwählen. Dies finde ich von Arbeitsweise her als eher ungünstig und weniger intuitiv. Ein einfacher Klick auf das Control führt aktuell auch im Designer die entsprechende Aktion aus des Controls, obwohl ich tendenziell dies an dieser Stelle für das Einrichten des Softdesks eigentlich nicht benötige.

Daher ist mein Wunsch an dieser Stelle, im Designer den Fokus auf die Einrichtung zu legen, sodass ich die Controls nach einem einfach Auswählen per Klick einstellen und ändern kann. Folglich habe ich das Ticket direkt mal mit dem Status “Usability Relevant” versehen.

Getestet mit Alpha 3, Build 11

Es fehlt ein Raster, welches im Rastermaß entsprechend einstellbar ist. Das interaktive Raster bei kleineren Softdesks zwar hilfreich, bei größeren Softdesks mit mehr als 40 Buttons dürfte ein festes Raster aber die bessere Wahl sein, vor allem weil sich so schneller eine akkurate Anordnung der Controls (auch übergreifen über mehrere verschiedene Softdesks) erzielen lässt.

Verändere ich über das Property Grid im Softdesk Designer die Größe eines beliebigen Elements, so ist die Breite oder Höhe nach dem Bestätigen der Eingabe und erneutem Auswählen des Elements um 5 Pixel geringer (je nachdem welche Eigenschaft ich geändert habe).

Dies wirkt sich auch auf die Funktion zum automatischen Anordnen der Elemente mit einem bestimmten Abstand aus. Für einen gewünschten Abstand von 10 Pixeln muss ich einen Wert von 5 Pixeln eintragen.

Ich kann die Softdesk-Elemente aktuell noch nicht in verschiedenen Ebenen anordnen. Dies fällt insbesondere dann auf, wenn ich mit einer Groupbox mehrere Buttons oder Slider optisch zusammenfassen möchte: die Buttons verschwinden im Hintergrund.

Ich setze im Softdesk einen Color Picker ein, um die Farben meiner LED-PARs individuell zu steuern. Wähle ich direkt eine Farbe aus (alte Farbe violett, neue Farbe grün), wird diese Farbe aktuell sofort aktiv gesetzt. Im Live-Betrieb sieht das meiner Meinung nach nicht schön aus. Deswegen der Wunsch, dass die Color Picker eine einstellbare (ggf. globale) Fadezeit erhalten, da ja auch an den meisten anderen Stellen in DMXControl 3 gefadet wird.

Die Fadezeit wird im übrigen dann nicht berücksichtigt, während der Auswahlpunkt mit der Maus gehalten wird. Liegt der Startpunkt allerdings nicht am Punkt der aktuellen Farbe, wird hier selbstverständlich gefaded.

Hallo,

eine Direkteingabe von Werten im Softdesk wäre super.

In DMXC 2 haben sich die getoggelten Buttons automatisch endtoggelt wenn man eine anderen aus der selben Gruppe gedrückt hat. Wäre schön, wenn ihr drüber nachdenken könntet diese Funktion auch wieder einzubauen.

https://forum.dmxcontrol-projects.org/index.php?thread/12494-r%C3%BCckmeldung-an-softdesk-button/

Einfacher Chaser mit Farbwechseln, nicht Beat gesteuert sondern follow 200ms.

Auf den Softdesk einen einfachen Fader der auf die Scenelist Speed wirkt.

Läßt man nun die Liste für eine Zeit (10 Sekunden reichen in der Regel) auf voller Geschwindigkeit laufen, kommt es zu einer Verzögerten Wiedergabe.

DIe läßt sich daran ausmachen, das man nun den Fader runter auf 0 setzt. Der Durchlaufspeed solltealso auch sofort wieder runter fahren, macht er aber nicht, sondern mit verzögerung.

Scheinbar arbeitet DMX Control noch alte Listdurchläufe ab bevor er dann, wenn seine aufholarbeit abgeschlossen ist den Speed wie gewünscht ändert.

Es ist in der Regel unwahrscheinlich, dass man dies in Livebetrieb mal erlebt kann aber unter Umständen vorkommen.

Ein Stop und Neustart des Cue setzt den speed sofort wieder richtig.

s.o., wie unser Position Control.

Ein Button sollte, ebenso wie ein Slider auch, als Output definiert werden können, sodass er an das Ereignis “Cuelist an/aus” geknüpft werden kann.

Siehe dazu auch FS#2719

Es wäre ein tolles Feature, wenn man im fullscreen Mode mehre Seiten hätte, durch die man wischen kann.

Im Softdesk Designer können Elemente nur positioniert, oder neu angelegt werden, wenn das property Fenster ausgeklappt ist.
Sollte kein Bug sondern nen Feature sein, dann würde ich nen “Fix Button” einbauen oder so…