Bugtracker DMXControl 3

Following discussion with JP on the forum, I’m posting this feature request here.

It would be useful to be able to achieve the following effect using the chaser effects:

https://vimeo.com/676900437/6d03543b2e

JP suggested this could be implemented as a ‘Fill’ option on the chasers.

As an example using the Colour chaser, the chaser should change the colour of each device to the next colour on the colour list, in selection order, until all devices have been changed, and then repeat with the next colour on the list.

This should work in combination with the play mode to set the direction that the fill happens in - forward, reverse, bounce or random.

This could also work with the standard chaser to apply the fill effect to dimmer intensity.

Ich habe festgestellt, dass der Parameter “Play Mode” des Color Chasers sich ausschließlich auf die Wiedergabereihenfolge der zugeordneten Color List bezieht. Ich habe bei aktiviertem “Use Device Index” aber keine Möglichkeit, eben diesen zu beeeinflussen. Egal ob Play Mode “Normal”, “Bounce” oder “Reverse”: die optische Laufrichtung des Color Chasers bleibt immer die selbe.

Daher wünsche ich mir für den Color Chaser im Endeffekt alle Parameter zusätzlich, die in den neuen Chaser Einzug erhalten haben:

• Fade Curve
• Break Steps
• Break Time
• Size
• Step Size
• Play Direction (Play Mode für Device Index)

Hinter dem Parameter Play Direction versteckt sich zum einen eben die bis dato fehlende Ansteuerung des Device Index, zum anderen aber auch die bereits für den einfachen Chaser implementierten Play Modes inklusive der Möglichkeit, per csv-Datei weitere eigene zu hinterlegen. Wenn ich dies richtig überblicke, können die Play Modes des neuen Chasers 1:1 auf den Color Chaser zur Ansteuerung des Device Index übertragen werdem.

Durch dieses Update könnte es eventuell sein, dass der bis dato vorhandene Parameter “Index Offset” überflüssig wird, weil er in einer der neuen aus dem neuen Chaser übergeht.

Ich lege ein neues Projekt und füge einem neuen Softdesk mehrere Controls hinzu. Dann schließe ich nur die GUI, während das Softdesk weiterhin im Designer geöffnet und das Projekt noch nicht gespeichert ist. Nach dem Neustart der GUI (den Kernel habe ich nicht beendet) sind alle neu eingefügten Controls verschwunden. Habe ich alternativ statt neue Controls hinzuzufügen auch nur bereits existierende Controls geändert (zum Beispiel verschoben), sind diese Änderungen ebenfalls nach dem Neustart der GUI weg.

Folglich fehlt ein entsprechender Befehl vom Softdesk Designer an den Kernel, das aktuelle Softdesk beim Beenden der GUI zu speichern. Denn wenn ich den Softdesk Designer vor dem Schließen der GUI manuell schließe, wird das Softdesk entsprechend im Kernel zwischengespeichert.

Aus den beigefügten Log-Files geht nicht hervor, dass das Softdesk beim Schließen der GUI automatisch gespeichert wird. Dafür wird aber in Folge dessen bemängelt, dass das in der ersten Session noch angelegte Control nach dem Neustart der GUI fehlt:

2021-03-29 11:31:46,518 [Main GUI] ERROR Lumos.GUI.WindowManager - Error when instantiating Object from persistString: Lumos.GUI.Windows.Softdesk.Designer.SoftdeskDesigner#c8aa2b0d-a9e3-4e64-98ef-47dcf6744d18
System.Reflection.TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht. ---> org.dmxc.lumos.Kernel.Exceptions.NotExistingException: Can't find a SoftdeskModel with ID c8aa2b0d-a9e3-4e64-98ef-47dcf6744d18
   bei Lumos.GUI.Windows.Softdesk.SoftdeskWindow.getSoftdeskModelFromID(String id) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\LumosGUI\src\Windows\Softdesk\SoftdeskWindow.cs:Zeile 71.
   bei Lumos.GUI.Windows.Softdesk.Designer.SoftdeskDesigner..ctor(String id) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\LumosGUI\src\Windows\Softdesk\Designer\SoftdeskDesigner.cs:Zeile 83.
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   bei System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   bei System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes, StackCrawlMark& stackMark)
   bei System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
   bei System.Activator.CreateInstance(Type type, Object[] args)
   bei Lumos.GUI.WindowManager.GetContentFromPersistString(String persistString) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\LumosGUI\src\WindowManagement\WindowManager.cs:Zeile 1817.

Ein (Beispiel-) Projekt kann nicht zur Verfügung gestellt werden, weil wie oben beschrieben zu keinem Zeitpunkt etwas gespeichert wurde.

Im Zuge der Freischaltung der Funktion “Gruppen in Gruppen” (siehe  FS#674 ) soll das Group Handling dahingehend erweitert werden, dass

• eine nachvollziehbare Ansteuerung auch über n Ebenen möglich ist und dabei nicht für jeden Anwendungsfall eine neue Gruppe angelegt werden muss
• ggf. auf unterschiedlichen Ebenen ein unterschiedliches Group Handling ausgewählt werden kann
• das Group Handling weitere Funktionen anbietet

Das beigefügte Projekt soll einen exemplarischen Aufbau zeigen, bei dem die Ansteuerung der insgesamt 100 Beam-MHs und 12 Spot-MHs am Ende durch ein verbessertes und erweitertes Group Handling deutlich variantenreicher erfolgen soll, ohne zusätzliche Gruppen anliegen zu müssen. Insgesamt gibt es bis zur Device-Ebene drei Gruppen-Ebenen. Folgende Szenarien sollten exemplarisch anhand eines Lauflichts einfach darstellbar sein, wobei sich diese Liste ggf. bei weiteren Überlegungen noch beliebig weiterspinnen lässt:
* Lauflicht innerhalb eine gesamte Zeile über die 25 Spalten hinweg (25 Geräte, Laufrichtung links rechts), egal ob nur bezogen auf eine Zeile oder ein paralleles Lauflicht über alle fünf Zeilen
* Lauflicht innerhalb eines Blocks, beginnend oben links, endend unten rechts
* Lauflicht über die fünf / sechs Zeilen hinweg (Laufrichtung oben unten), egal ob nur bezogen auf eine Spalte oder parallel auf allen 20 Spalten
* Lauflicht über alle 24 Einzel-Zeilen, wo immer fünf bzw. drei Geräte gemeinsam ein- und ausgeschaltet werden
* Lauflicht über die vier Blöcke, wo immer 28 Geräte gemeinsam ein- und ausgeschaltet werden
* Gegenläufige Lauflichter aus der oberen Gruppe heraus, wo Zeilen 1, 3 und 5 links-rechts und Zeilen 2 und 4 rechts-links wiedergegeben werden

Wie im Livechat am 19.1. diskutiert fände ich gut wenn es ein Grouphandling gäbe mit dem ich Geräte in einer Gruppe als ein Gerät betrachten kann und gleichzeitig in der “Hauptgruppe” auch einzelne Geräte haben kann. Siehe auch mein Kommentar in ( FS#674 ).

Ich habe in DMXControl 3.2.3 einen Fader im Softdesk der z.B. die Goborotation regelt.
Wenn ich jetzt eine Gerätegruppe in der Bühnenansicht auswähle und die Goborotation über die Gerätesteuerung ändere dann ändert sich auch der Fader im Softdesk.
Es ändert sich allerdings nicht der Fader im Steuerungsfenster für die Gobos.

Ich habe mit LightningBrothers geschrieben und er meint es handelt sich um ein Bug. Er hat mich geben ein Ticket anzulegen. Anbei seine Antwort:

“Ich habe mir das mal angeschaut und festgestellt, dass du einen Bug im Slider gefunden hast. Das Problem tritt auf sobald der Minimalwert unter 0 liegt und du den Style “Rounded” oder “Custom” ausgewählt hast. Änderst du den Style auf “Slim Gnob”, reagiert der Slider auch. Wenn du magst, darfst du hierzu gerne ein Ticket in unserem Bugtracker anlegen, wo du nochmal das Problem beschreibst, im Idealfall ein Beispielprojekt anfügst und auch meine Hinweise / Erkenntnisse mit aufnimmst.”

Stand heute gibt es beim PWM Static nur die Möglichkeit, eine Gruppe von Geräten entsprechend der Position des zugeordneten Parameter Masters “aufzufüllen”. An dieser Stelle wünsche ich mir die Möglichkeit, eine feste Anzahl von Geräten (zum Beispiel 3) mittels des Parameter Masters innerhalb der Gerätegruppe hin- und herzuschieben. Beim Minimal- bzw. Maximalwert des Parameter Masters leuchten dann immer drei Geräte am entsprechend korrespondierenden Ende der Gerätegruppe. Bei 50% würden in der Mitte vier Geräte leuchten (die beiden mittleren mit 100%, die äußeren mit je 50% leuchten), wenn Fade auf True gesetzt ist und die Gruppe eine gerade Anzahl von Geräten umfasst.

Hierzu bedarf es neben dem zusätzlichen Parameter für “Size” auch einen weiteren Eintrag für den Parameter “Direction”, der beispielsweise “Group” lauten könnte. In diesem Zusammenhang wäre zu überlegen, ob nicht eine Umbenennung des Parameters “Direction” in “Play Mode” erfolgt.

Im dynamischen PWM-Effekt müssen diese Ergänzungen nicht vorgenommen werden, weil sich dieses Szenario mit dem neuen Chaser abbilden lässt, sofern der Effekt eben automatisch laufen soll.

Beim Verfassen des Tickets FS#4759 ist mir aufgefallen, dass der neue Chaser um vier weitere Play Modes erweitert werden kann:

• Fill from left (>)
• Fill from right (<)
• Fill from center (<>)
• Fill to center (><)

Diese vier zusätzlichen Play Modes stammen aus dem dynamischen PWM-Effekt. Aus meiner Sicht sind diese vier anderen Play Modes der einzige Unterschied, der zwischen dem neuen Chaser und dem dynamischen PWM-Effekt existiert. Von daher würde ich in diesem Zusammenhang vorschlagen, den dynamischen PWM-Effekt nach der Übernahme der oben genannten Play Modes in den neuen Chaser zu entfernen.

Möchte ich den One Shot Trigger nutzen und füge diesen entsprechend der “Vorgaben” in eine Cuelist ein, funktioniert dieser erst nach dem erneuten Laden des Projekts. Erstelle ich eine neue Szene (egal ob komplett neu oder eine Kopie) mit dem Trigger einer Cuelist hinzu und führe die Cuelist im Anschluss direkt aus, werden die Cues übersprungen. Offenbar überprüft der Trigger nicht die aktuellen Parameter des vorausgehenden Effekts, sobald die Cuelist gestartet wird.

Die einfache Reproduktionsanleitung:

• Beliebigen Effekt wie Chaser oder Triangle auf den Dimmer eine Device Group legen und als Cue in einer neuen Cuelist abspeichern. Trigger ist follow, alle anderen Zeiten 0ms.
• Dummy-Cue mit One Shot Trigger einfügen. Wiederholung beliebig setzen, alle anderen Zeiten auf 0ms.
• Proforma eine dritte Cue zum Beispiel Dimmer 100%, Farbe blau einfügen. Trigger “follow”, Trigger Value 1s, Fade 0ms, Delay 0>5s.
• Cuelist abspielen. ⇒ Ergebnis: man sieht nichts. Auch die letzte Cue “Full on” wird nicht (mehr) vollständig ausgeführt, sofern die Cuelist auf “Release when last cue ends” gesetzt ist.
• Projekt speichern, schließen und erneut laden.
• Cuelist wieder abspielen. ⇒ Ergebnis: Trigger arbeitet wie erwartet und man kann ihn dann auch beliebig verändern. Die letzte Cue wird ausgeführt.

Da es keinerlei Einträge für den Zeitraum gibt, in dem ich dieses Projekt gebaut habe, füge ich keine Logfiles bei. Zur Reproduktion des Fehlers kann das beigefügte Projekt verwendet werden, indem man aus der existierenden Cuelist die Cue mit dem Effekt und die Cue mit One Shot Trigger kopiert und erneut einfügt. Alternativ einfach die Zeiten des Effekts ändern.

Der neue Dialog zum Auswählen eines Hintergrundbildes für die Stage View sollte aus meiner Sicht wie der neue Sound Selector die Möglichkeit erhalten, eine Bilddatei direkt aus dem Dateisystem auszuwählen. Damit entfiele der bislang notwendige Umweg, das gewünschte Hintergrundbild erst anderweitig ins Projekt ins Projekt importieren zu müssen und würde sich zudem eben an die Möglichkeiten im neuen Sound Selector angleichen.

Fehlerbeschreibung

Project laden,
SoftDesk Öffnen
MacroBoardProfil öffnen
Converter-Effecct auf die Matrix in der StatgeView legen und warten bis es knallt

Implement Textures for IA-Nodes.
Textures will be drawn centered. If bigger scale down, always match the original ratio.

Also add Min and Max Heigth/Width ⇒ If 0 ignore else see as hard limit ⇒ Stop drawing nodes after the limit.

Für den fall der fälle, das sich eine Resource ändert, muss es eine möglichkeit geben die verwender der Resource zu informieren, das sich die Resource, die sie verwenden geändert hat.

Möchte man mit einem Projekt an verschiedenen Locations arbeiten, muss man einfach die nicht benutzten Geräte deaktivieren. Hat man aber recht viele Geräte, kann das durchaus auch einmal länger dauern, bis man alle entsprechenden Geräte deaktiviert / aktiviert hat. Daher wäre es gut, wenn man auf irgendeine Art und Weise “Locations” (Name TBD, alternativ tatsächlich “Mute Groups”) im Projekt hinterlegen kann, denen dann einzelne Scheinwerfer zugewiesen werden können. Aktiviert man eine “Location”, werden alle anderen Scheinwerfer deaktiviert, die nicht in der “Location” sind. So muss man nur noch einmalig die einzelnen “Locations” definieren und kann recht schnell zwischen verschiedenen Veranstaltungsorten wechseln.

Weitere Erwartungshaltungen:
- Man kann trotzdem ein anderes Gerät wieder aktivieren, auch wenn es nicht in einer “Location” enthalten ist. Das muss dann händisch passieren und es hat keine Auswirkung auf die Locationzugehörigkeit (beim nächsten Mal muss man es wieder händisch aktivieren, wenn das gewünscht ist)
- Es können auch mehrere “Locations” aktiv sein. Die aktiven “Locations” werden verodert.
- Deaktiviert man alle “Location”, werden alle Geräte aktiviert

Fehlerbeschreibung

Füge ich eine Gruppe in eine Gruppe hinzu ist anschließend Feld Up/Down ausgegraut wenn die Gruppe ausgewählt ist. Liegen einzelne Geräte mit in der Gruppe lassen sich diese verschieben, auch an den Gruppen vorbei.

Bei der Phase kann man zwar den Wert fannen,
z.B. {parametermaster 1} > 0
Das funktioniert auch. Wenn man die Szene abspeichert und das
Projekt wieder öffnet erscheint eine Fehlermeldung:
Value kann nicht für Parameter: Phase geladen werden.

{parametermaster 1} > {parametermaster 1:*2} funktioniert aber.

Weis nicht ob das jetzt überflüssig ist aber ich würd gerne auf das Brainstorming:Gerätefunktionen.
Wäre echt geil wenn dasd alles balt gehen würde.

Das Scrollen und Zoomen funktioniert nicht zuverlässig, aber ohne HotReload schmeiß ich die Karten hin

Im Fenster Device Control ist alternierendes Fanning bei den Werten für die Farbkanäle nur mit zwei Werten möglich, werden mehr als zwei eingegeben (und natürlich durch ‘#’ getrennt) werden beim Bestätigen mit Enter nur die ersten zwei Werte übernommen. Anders ist dies bei der Dimmer-Eigenschaft, hier können auch drei Werte abgewechselt werden. Bitte ausbessern ;)

Im beigefügten Projekt habe ich eine Seitenumschalten zwischen zwei Macroboard-Profilen realisiert, indem ich via eines Counters die Nummern der Macroboard-Profile hoch- bzw. herunterzähle. Die Profile im Projekt sind für ein Stream Deck XL gebaut.

Wechsele ich nun die Seite, muss ich die betreffenden Button 4.8 (Seite vor) bzw. 4.7 (Seite zurück) zweimal drücken. Beim Verlassen der Seite wird der Ausgangswert des Button 4.8 bzw. 4.7 von “True” nicht mehr zurück auf “False” gesetzt. Zu sehen ist dies in dem Connectionset “Page-Navigation”.

Ob dieses Problem mit DMXControl 3.3 auch noch besteht, kann ich erst nach der Freigabe der Aplha 8 prüfen. In der Alpha 7 lässt sich das Projekt auf Grund des mittlerweile behobenen Fehlers aus Ticket  FS#4670  nicht öffnen.

Aktuell verfügen die Macroboard-Profile über kein Eigenschaften-Fenster, wie es eben Devices oder Cuelists der Fall ist. Im Eigenschaften-Fenster der Macroboard-Profilen könnte ich mir aktuell folgende Parameter vorstellen:

• Name
• Macroboard-Profil-Nummer

Insbesondere der Parameter “Profil-Nummer” kann hilfreich sein, wenn man über eine numerische Zuordnung der Profile zu einem Macroboard arbeitet, wie zum Beispiel beim Durchblättern durch mehrere Seiten (respektive Profilen).

Optional würde ich folgende Einstellmöglichkeiten in den Raum werfen:

• Statisches Hintergrundfarbe oder -bild
• Verhalten der Buttons (Push oder Toggle)
• Anzahl der Buttons pro Zeile und Spalte

Man kann unter unter dem Kontextmenü Executer Page einzelne Executoren anlegen, aber nicht im Fenster.

Ist das MPA-Plugin aktiviert, ergänzt es entsprechend ein Icon im Einstellungs-Fenster. Der Name des Icons lautet hier allerdings einfach nur “Plugin”. Es wäre gut, wenn der Titel in “MPA” oder ähnlich versehen wird, damit auch direkt zu erkennen ist, was sich hinter dem Icon befindet.

In DMXC 3.2.2 können bei der Angabe von Mastern im Device Control schon Rechnungen angegeben werden und hier gibt es auch einen Parameter für die Anzahl der Geräte in der angesteuerten Gerätegruppe (CONST). Ich fände es gut, wenn man Rechnungen auch direkt in den Properties angeben könnte. Dies ist dann sinnvoll, wenn beispielsweise ein Effekt per Fanning auf der Phase auf 8 Scheinwerfer verteilt werden soll. Aktuell muss man hier das Fanning entsprechend angeben, wodurch es angepasst werden muss, wenn sich die Anzahl der Geräte in der Gruppe ändert. Durch einen Parameter wie den COUNT Parameter könnte man dies elegant umgehen.

Ein weiterer Anwendungsfall wäre, wenn mehrere Effekte überlagert werden sollen. In diesem Fall muss man das Fanning per Offset verschieben. Man könnte sich Arbeit sparen, wenn man das Offset per Rechnung angeben könnte (natürlich auch für gefannte Werte, um das ganze Fanning zu verschieben). Die Frage wäre noch, ob die Rechnung wenn möglich aufgelöst werden soll oder nicht. Beides hätte seine Vorzüge. Das Auflösen ist übersichtlicher, nicht auflösen könnte bei Offsets deutlich einfacher sein.

Über die Buttons half und double kann man den aktuellen BPM-Wert faktorisieren. Hier wäre es gut, wenn dieser Faktor angezeigt wird. Ein typisches Anwendungsbeispiel ist, dass ich mehrere Speedmaster zwar gleichzeitig Lerne bzw. Synchronisiere, aber jeden Speedmaster einzeln faktorisiere.

Wird im Multiclientbetrieb gearbeitet werden änderungen am Softdesk nicht an andere Sessions publiziert. Auch das Speichern von Änderungen am Softdesk ist so nur auf einem (zufälligen?) Client möglich.

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

Graph ist nach Generierung “Default”.

Sollte der User:
1. Knoten oder Kanten löschen / hinzufügen
2. Parameter von Knoten ändern

Ist Default = false und das wird durch ein Icon in der Headerzeile visualisiert.

Es wäre hilfreich, wenn bereits verwendete Nodes eine Markierung erhalten, dass sie bereits irgendwo verwendet worden sind.

Folgendes Szenario:
Man hat ein 24 Kanal DMX Pult als Input und möchte wissen, ob ich bereits alle Fader verbraten hab, oder ob noch 1/2 frei sind. Dadurch hätte man einen guten Überblick.

Lösungsvorschlag:
Sobald Node irgendwo benutzt wurde, wird der Pfeil orange eingefärbt.

Es wäre super, wenn man innerhalb einer Cuelist auch mit absoluten Zeitangaben arbeiten könnte, die relativ zum Start des Abspielens eine Cuelist zu verstehen sind.

Beispiel: eine Cuelist wird manuell gestartet. 9 Sekunden nach Start soll der zweite Schritt beginnen, 20 Sekunden nach Start der dritte Schritt. Dann wäre es prima, wenn man einfach schreiben könnte:

Cue 1 manual
Cue 2 “absolute follow” 9s
Cue 3 “absolute follow” 20s

wobei sich das “absolute follow” 20s der Cue 3 auf t0 von Cue 1 bezieht.

Es wäre ebenfalls schön, einen Trigger “Absolute Wait” hinzuzufügen.
Dieser soll sich - ähnlich wie “Absolute Follow” - auf eine bereits mehrere Cues zurückliegende Cue beziehen.

Beispiel:
Cue 1 Manual
Cue 2 “(Absolute) Wait” 9s
Cue 3 “Absolute Wait” 20s

Der Triggerwert von Cue 3 bezieht sich dabei auf Cue 1.

Eine erste Diskussion hierzu findet bereits im Forum unter

http://www.dmxcontrol.de/forum/index.php?page=Thread&threadID=8599

statt.

Von Einzelnen Inputs Outputs umbauen in Nodes wie alles andere auch.

Ergänzung des Tickets aus der Entwicklersitzung vom 28.11.2020

• Umbau auf eine Multi-Port-Lösung für Input und Output, sodass jede Eigenschaft getrennt verknüpft werden kann. Am Beispiel des Buttons wäre dies exemplarisch: Anzeigetext, Farbe des Buttons, Status, etc.
• Die Inputs und Outputs bleiben beim Softdesk weiterhin getrennt und werden nicht in einem Node wie zum Beispiel Cuelist, Device o. ä. zusammengeführt.
• Die Inputs und Outputs erhalten einen Legacy Input, welcher nach Umzug aller Verbindungen verschwindet und für neue Knoten auch nicht existiert. Das muss ein Framework Feature werden, da das sicher bei anderen Stellen auch nochmal auftritt.

Als Zeitschiene soll die Version 3.3 angepeilt werden.

Man sollte in Zukunft in der Lage sein mehrere Controls welche man im Softdesk angelegt hat als Template zu speichern.
So muss man diese Controls nicht wieder einzeln einfügen, sondern kann direkt das gesamte Template laden.

Beim Speichern/Laden sollten dann Relative Positionen beachtet werden, Styles und andere Eigenschaften mit übernommen werden und die Template
Dateien sollte auslagerbar sein, damit man diese exportieren/importieren kann.

s. Überschrift

Aus dem Ticket  FS#3851  geht als Folgepunkt hervor, dass der ColorHandlers derart erweitert wird, dass dieser die Farbe auf Matrix und Colorwheel verteilt, ähnlich RGB / Colorwheel Verteilung.

Ziel soll sein, dass man zum Beispiel bei einer LED-Bar sowohl die gesamte LED-Bar mit Hilfe des ColorPickers in einer Farbe einfärben, für die einzelnen Pixel das Matrix-Fenster nutzen oder die Farbe über ein virtuelles Farbrad wählen kann. Ein Beispiel wäre hier zum Beispiel Eurolite LED PIX-12 QCL.

Ein paar Ideen um die Usability des Add Device Fensters zu verbessern. Da man ja während das Fenster offen ist, eh nichts anderes machen kann, könnte man ja den verfügbaren Platz nutzen.

- Vergrößern der “Größer”/”Kleiner” Buttons bei den Int Werten
- Int Werte mit Mausrad erniedrigen/erhöhen
- Mit Tab rechts alle Werte anwählbar machen (aktuell wird “Assign to (new) Group” und “Repeat” ausgelassen)
- Den “Fokus” von Tab überall sichtbar machen (wenn man mit Tab gerade auf z.B. dem “Add Device” oder “⇒ Patching” Button ist, dann ist das für den User nicht ersichtlich)
- Hinzufügen der Geräte bei “Enter” - Standardgröße des Fensters vergrößern
- Hintergrund abdunkeln, damit schneller ersichtlich ist, dass man nur in diesem Fenster arbeiten kann, solange es offen ist

Der Speedmaster kann ja mit DMXControl 3.2.2 nun auch direkt auf einen BPM-Wert gesetzt werden. Hier wäre es hilfreich, wenn der AudioAnalyser diesen ebenfalls direkt so als Input anbieten kann.

Der aktuell vorhandene Zählwert für den Beat lässt den Speedmaster zu sehr springen, was das Ergebnis merklich verfälscht und in einem großen Spektrum stark springen lässt. So habe ich Titel, wo der AudioAnalyzer mit seiner Analyse konstant bei beispielsweise 128 BPM liegt. Der Speedmaster macht daraus allerdings BPM-Werte zwishcen 120 und 160 BPM, je nachdem wie die Zählwerte über den Beat to Bool Konverter am Learn-Input ankommen.

in Folgedem Beispiel wurde eine “Stairville AF-250” verwendet
Beim Timer wird der DMX Kanal immer auf 100% gesetzt für die Aktive Zeit.

Schön wäre es wenn man auch die Menge auswählen könnte wie, 25%, 50%, 75%, 100%. Oder vielleicht sogar eine frei wählbare Menge an Ausstoß.

Hab eine Cueliste im PlayMode Random mit folgenden Cues:

Number; Trigger; Name
0       Go      "Flash White Device 1"
1       Follow  "Flash White Device 1 Release"
2       Go      "Flash White Device 2"
3       Follow  "Flash White Device 2 Release"
4       Go      "Flash White Device 3"
5       Follow  "Flash White Device 3 Release"
6       Go      "Flash White Device 4"
7       Follow  "Flash White Device 4 Release"
8       Go      "Flash White Device 5"
9       Follow  "Flash White Device 5 Release"
10      Go      "Flash White Device 6"
11      Follow  "Flash White Device 6 Release"
12      Go      "Flash White Device 7"
13      Follow  "Flash White Device 7 Release"
...
XX      Go      "Flash White Device Y"
XX +1   Follow  "Flash White Device Y Release"

Ich möchte das bei jedem Go eine Random Cue mit Number%2==0 getriggert wird. (0,2,4,6,8,10,12)

Möchte ich zum Beispiel das Feedback für einen Button dahingehend darstellen, dass dieser in Abhängigkeit seines Status die Farbe wechselt und ggf. auch anfängt zu blinken, wenn er aktiviert ist, benötige ich eine Reihe von verschiedenen Nodes.

Um das Handling gerade über mehrere Connectionsets zu vereinfachen, würde ich mir an dieser Stelle ein Art Makro-Node (oder Baugruppen-Node oder Blackbox-Node) wünschen, dass ich analog zur Siemens S7 an einer Stelle mit mehreren Nodes fülle, die Nodes konfiguriere und dann die Ports angebe, über die ich dann Werte in das Makro-Node hineinschicke und zurück erhalte.

Das Ziel soll am Ende sein, dass man

• nachträglich Teile eines komplexeren Connectionsset in meine anderen Connectionsets einbauen kann
• entsprechend komplexe Teile eines Connectionsets nur einmal ändern muss (Properties der genutzten Nodes selbst als auch Hinzufügen oder Entfernen von Nodes) und diese Änderung sich auf alle Connectionssets auswirken, in dem dieses Makro-Node verwendet wird
• solche Makros auch projektübergreifend nutzen kann und somit wie eine Bibliothek zur Verfügung stehen, ggf. auch über eine Import- und Export-Funktion

In der Stageview sollten selektierte Geräte und Gruppen mit Rechtsklick → Entfernen von der Stageview entfernt werden können.
Eventuell auch mit druck auf die Entf-Taste, wobei das eventuell zu unsicher ist.

Zweiter Contextmenü-Eintrag sollte sein “Copy to StageView X” und “Move to StageView X”

Eine Möglichkeit, ähnlich dem Trigger, der FadeTime nicht eine feste Größe sondern eine Variable/Input aus dem Inputassignment zuweisen zu können
und durch dieses global eine fade Zeit (wie in guten alten Zeiten beim SceneSetter48) einstellen zu können

Moin,
Eine Idee, kann man es Realisieren das die Benennung der Geräte im Stageview ein Zeilenumbruch zu ermöglichen. Als Symbol könnte man im Namen ein Semikolon Nutzen.

Gruß
Max

AudioAnalyser als Auswahlmöglichkeit für BeatSource der CueList hinzufügen. Das ermöglicht vom AudioAnalyser erzeugte Beat-Steuerung, die nicht einen gleichmäßigen Beat erzeugt (wie ManuelBeat oder Speedmaster).
Die Erweiterung ermöglicht evtl. auch anderen Erweiterungen/Plugins sich an dieser Stelle einzubinden.

AL: Vorbereitung erledigt. Frank muss Plugin anpassen

Erwartetes Verhalten der Stage View.
1. Drücken ‘Alle auswählen’: Alle vorhandenen Device Groups werden ausgewählt
2. Drücken in leeren Bereich der Stage View: Alle gewählten Objekte werden abgewählt.
3. Drücken ‘Alle auswählen’: Alle vorhandenen Device Groups werden ausgewählt.

Aktuelles Verhalten der Stage View.
1. Drücken ‘Alle auswählen’: Alle vorhandenen Device Groups werden ausgewählt
2. Drücken in leeren Bereich der Stage View: Alle gewählten Objekte werden abgewählt.
3. Drücken ‘Alle auswählen’: Alle vorhandenen Device Groups Devices werden ausgewählt.

Für Moving Heads ist das aktuelle Position Control mäßig. Hier wäre es super, wenn es ein Control mit Grad Zahlen geben würde, wie der Head wirklich ausgerichtet wird.

s. folgendes Bild:
https://www.lightkeyapp.com/content/01-home/03-creativity2/position-hud.png

Wie bereits mehrfach besprochen sollte DMXC mehrere Modi unterstützen (Anfänger, Fortgeschrittener) sowie evtl. unterschiedliche Standard layouts (Theather, Disko,…)

Entsprechend sollten Elemente angezeigt oder ausgeblendet werden.

Hierzu muss folgendes durchgeführt werden:

1. Definition, welche Gruppen es gibt
2. Definition, was diese Gruppen sehen und was nicht
3. Implementierung des Models

Wichtig ist, dass diese Auswahl nur initial das System konfiguriert. Der User kann jederzeit in den Fortgeschrittenen Modus wechseln und dadurch mehr Dinge angezeigt bekommen.

Der Softdesk Designer braucht einmal einen Rework:

- Liniale Oben/Unten Rechts/Links
- Zoom indicator
- Bereichs indicator
- Scrollbalken im Designer und in der Live ansicht sollten sich unterschieden
- Liste der Auswähöbaren UserControls sollten geordnet werden
- Liste der Properties sollte Gruppiert werden.

Die Größe des Softdesk orientiert sich ja an den Elementen am Rand. Wenn man nun ein solches in die Mitte ziehen will schrumpft das Softdesk gleichzeitig mit und es wird nach links gescrollt. Das ganze geht in ziemlich schnell was ein genaues Positionieren unmöglich macht. Gut wäre es, wenn die Softdeskgröße beibehalten wird, solange das Control noch mit der Maus rumgezogen wird. Erst bei loslassen schrumpft das Softdesk, so kann man es Controls auch am Rand gut verschieben. Außerdem sollte das Softdesk am besten immer am Rand z.b. 50 Einheiten vom Rand des letzen Elements entfernt sein.