Bugtracker DMXControl 3

Ich hab mal wieder ein Problem mit der StageView:

Wenn man in einem Projekt zwei StageViews erstellt, beide mit Lampen füllt und in Tabs eines Panels öffnet, wird immer nur eine angezeigt. Schaltet man zwischen den beiden umher, wird eine (immer die gleiche) ordentlich angezeigt, während die andere zwar eine Menüleiste, aber weder Hintergrundbild noch Lampen noch Gruppen hat.
Welche StageView korrekt angezeigt wird, hängt davon ab, welche nach Programmstart als erstes geöffnet wurde.

Wenn man beide StageViews in zwei Panels nebeneinander öffnet flackert das Bild in einem Panel (das der StageView, die zuerst geöffnet wurde) hin und her zwischen den korrekten Ansichten beider StageViews (also mit allen Lampen und Gruppen). Das andere Panel zeigt den grauen Hintergrund und die Menüleiste.

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.

Moin moin,

Ich hab mal wieder nen Bug ausgegraben, der mich schon seit der 3.0.10 :) stört und auch immernoch auftritt:

Wenn ich 2 Sessions (mit zwei unterschiedlichen Namen benutze, verschwinden auf einmal die Cuelists in der zweiten Session, sobald ich sie versuche zu öffnen.

Um das ganze mal nach zu bauen, hab ich mir einfach ein paar RGB Geräte angelegt, eine Cuelist auf meinem ersten Rechner angelegt und dort einfach nen grün abgespeichert. Danach konnte ich dies noch auf meinem zweiten öffnen. Dann habe ich einfach noch 8 weitere Cuelists angelegt und wollte Random eine Cuelist öffnen und konnt sie im PE nicht mehr öffnen.

Man kann sie zwar unter Windows/Cuelists zwar wiederfinden und öffnen, aber ab einer gewissen Anzahl vermisst man dann halt doch die Ordnerstruktur.

interessant ist auch, dass wenn man auf der zweiten Session Cuelists erstellt, auch diese verschwinden.

Da wir immer mehr eigene Hardware anbieten und auch hin und wieder neue Funktionen in die Devices kommen, welche z.T. eng mit DMXC verknüpft sind (Nodle U1, Sync ausgabe, heartbeat), wäre es vielleicht sinnvoll die jeweils aktuellste Firmware für z.B. das Nodle U1 und dann auch das R4S und zukünftige mit DMXC 3 auszuliefern und eventuell beim Start den User darauf hinzuweisen, das eine neue FW verfügbar ist.

DMXC3 müsste dafür nur eine Datei pro HW haben, in welcher die aktuellen FWs stehen und diese beim Verbinden mit dem Interface abgleichen.
Wurde eine ältere Firmware im Device erkannt, kann wird beim Start der Software und verbinden der HW eine MessageBox geworfen und die Verbindung abgebrochen mit Hinweis auf die neue FW.

Der User kann nun entscheiden ob er die Hardware mit der alten FW verbinden will oder zunächst ein Update machen will.
Bei Update-Entscheidung muss DMXC nur ein kleines von uns mitgeliefertes Programm/Tool/exe starten, welches in einem definierten Pfad im Kernel oder GUI liegt.

z.B. beim U1: kernel/hardware/nodle_u1/update.exe –Serialnumber
oder beim R4S: kernel/hardware/nodle_r4s/update.exe –Serialnumber

Das Programm “update.exe” ruft dann die nötigen subprogramme/Funktionen/etc aus dem Ordner auf, um den User durch den Flashvorgang zu leiten.
Wenn erfolgreich, meldet das Programm “exit 0” oder so zurück und DMXC3 kann mit dem Verbindungsaufbau zur HW fortfahren.
Die Seriennummer oder eine andere Geraetekennung (je nach Device) dient dazu mehrere angeschlossene Geräte zu unterscheiden.

Je nach Gerät passiert das alles nach dem druck auf “Ja Update Jetzt” automatisch, weil der User keine Interaktion mit der HW benötigt.
Die spezifischen Unterschiede für jede Hardware sind von DMXC3 komplett entkoppelt und nur in der update.exe pro Hardware zu warten.
Damit ist das jederzeit austauschbar/anpassbar ohne DMXC und dessen Hardware-Treiber zu beeinflussen.

Als Luxus-Variante könnte in dem “neue FW-Fenster” noch der Changelog bzw. die neuen Funktionen des Firmware drin stehen, die sich DMXC aus besagter Versionsdatei in dem jeweiligen Verzeichnis ziehen kann.

Vorerst nur als Eingabe (Steuerung von DMXControl über MIDI)

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

Man hat die Möglichkeit Gruppen erneut zu gruppieren.
Die Tiefe ist auf unbegrenzt, ausgenommen Schleifen
Auf diese oberste Gruppe koennen auch Effekte gelegt werden.
Ist ein Gerät in mehreren Gruppen, werden nur die Werte aus der ersten Gruppe verwendet.

Da mit dieser Version weitere Master Einzug erhalten, wäre hier eine zentrale Verwaltung für alle Master im Project Explorer hilfreich. Insbesondere für die Speed- und Playback-Master fehlt eine Möglichkeit, diese aus dem Projekt zu löschen.

Daher schlage ich vor, im Projekt Explorer einen weiteren Eintrag mit dem Namen Master sowie mit den festen Unterordnern Group Master, Speed Master, Playback Master hinzuzufügen. In den Unterordnern sind dann folgende Optionen verfügbar / zulässig:

• Group Master: aktivieren und deaktivieren
• Speed Master / Playback Master: neu anlegen, löschen

Da man aktuell Gefahr läuft, sich sein Projekt bei Tippfehlern mit Speed Mastern und Playback Mastern unnötig zu fluten, habe ich diesem Wunsch für den Moment eine mittlere Priorität eingeräumt.

Aus den Softdesk heraus den Manuellen Beat anzusteuern und zu Regeln ist derzeit nicht möglich.

Wenn man FS#2756 (”LCD” Panel im Softdesk) mit der Möglichkeit des Beat Manipulation über Trigger kombiniert, kann man die ganze Beat Steuerung aufs Softdesk legen.

Auch gut möglich wäre die Anpassungen der Einstellungen für den Audio Analyser vom Softdesk aus.

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.

Aktuell kann man bei MovingLights nur pro Gerät einen Offset für Pan und Tilt festlegen. Sollen aber MovingHeads und Scanner gemeinsam in einer Gruppe fahren, müssen im Regelfall die Bewegungen für die Scanner verkleinert werden, damit diese nicht immer in die Anschläge fahren.

Darüber hinaus kann man mit Hilfe der Skalierung für Pan und Tilt in Verbindung mit dem Offset, jedes MovingLight indivuell Positonieren und den Aktionsbereich festlegen.

Die Skalierung für Pan und Tilt sollte jeweils getrennt einstellbar sein. Der Wertebereich sollte effektiv gesehen alle Werte größer 0 zulassen, wobei bei 0 bis 1 der Aktionsbereich verkleinert und >1 entsprechend vergrößert wird.

Hallo,
Ich würde mir wünsche das sich in zukünftigen Versionen Softdesk-Buttons mit Tasten der Tastatur Verknüpfen lassen z.b. in den Properties oder über das InputAssignment

VG Philipp

Es ist möglich mit der Channel Overview Cues und Stageview Einstellungen zu überschreiben, durch auswählen eines Wertes der dann ausgegeben wird. Es sollte möglich sein, dieses überschreiben zu entfernen, so dass die Channel overview wieder nur die Werte anzeigt und ausgibt die von StageView, Cuelists, etc. kommen.
(Analog DMXC2, wenn ich dort die Channeloverview geschlossen habe kan die Frage, Channeloverview gibt noch Werte aus, will ich das beenden? ⇒ Ja)

Es wäre schön, den manuellen Beat über DMX-In erfassen zu können.

Sinnvoll wäre es Variablen in Eigenschaften unterbringen zu können. Eine Variable könnte dann zum Beispiel so aussehen:

$BeispielVariable

Wenn ich so eine Variable nun zum Beispiel einer Phase von einem Effekt zuweise:

0<$BeispielPhase

Könnte ich, wenn ich die Variable einen Input zuweisen könnte, noch nachträglich die Phase des Effektes verändern.
Oder wenn ich meine Movingheads auffächere mit

-20<20

könnte ich dank

-$Fächer<$Fächer

die Fächerung hinterher noch justieren und so mein gespeicherten Szenen super einfach live variieren.

Hab beim Jahrestreffen vergessen was anzusprechen, und zwar den Single Flash bei Strobes.

Ich fänds gut, wann mann den auch ordentlich Visualisiert in der LiveView einbauen würde.

Am beispiel von Henne’s Strobo Mod.

Nach GUI Neustart laufen die mit einem Beat gekoppelten Szenen zwar weiter mit dem eingestellen Beat, die anzeige wird aber nicht in das Panel ‘Manual Beat’ übernommen

Wenn ich die Größe einer Matrix nachträglich über die Properties ändere (egal ob Vergrößerung oder Verkleinerung), kommt diese Änderung im PropertyGrid zahlenmäßig erst an, nachdem ich einmal den Matrix FormEditor geöffnet und mit OK wieder geschlossen habe. Die Matrix-Effekte kommen nach (und auch während) der Änderung allerdings direkt richtig an. In den meisten Fällen sollte dieser Schritt meiner Meinung unnötig sein und könnte aktuell noch zu Verwirrungen führen.

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.

Getestet mit Build 1402

An folgenden Punkten gäbe es weiteren Optimierungsbedarf in den GUI-Dialogen:

• Textfarbe der eingerichteten Interfaces sollte auf schwarz geändert werden, wenn die Hintergrundfarbe hellgrau oder rot ist (Bild 1).
• Wird ein Interface vollständig aktiviert, wird die Hintergrundfarbe nicht in allen Zellen geändert sondern immer nur in der Zelle, die man mit der Maus anklickt (Bild 2).
• Das letter spacing ist in allen Dropdown-Menüs zu groß und die Schriftgröße entspricht nicht der Größe von anderen Texten in Fenstern (Vergleiche Filter mit Programmer im Bild 3 oder View mit Universe.Channel im Bild 4).
• Die vertikale Textausrichtung für Device und Device Groups im Programmer Filter passt nicht (Bild 5 und 6).
• Nachdem die Tooltips im Dark Mode nun von der Texthöhe angepasst wurden, sollte nun der Text auch noch einen Abstand zur äußeren Kante erhalten (Bild 7). Ggf. wäre auch über ein zusätzlicher Schatten oder eine andere Hintergrundfarbe nachzudenken, damit sich der Tooltip besser abhebt.(Wird nicht umgesetzt)
• Die Tabellenzellen sollten ggf. am inneren linken und rechten Rand ebenfalls einen Abstand zum Rand erhalten, um die Lesbarkeit der Werte zu verbesseren (siehe Bild 2, DMX Interfaces sowie Bild 6, Programmer Filter und Bild 7, Cuelist mit Tooltip). Die Schriftgröße darf aber gerne so beibehalten werden.

Temp-fader für Scenenlisten

Wirkt wie der intensety-master aber auf alle Propertys

Einbauen des “OnlyFade” Attributes, damit bei Effekten die Obergrenze sich nur auf den Fader auswirkt.

=⇒ Es geht darum, dass z.B. für Phasenverschiebung der Regler nur von 0 - 720 Grad geht, eine Eingabe von beliebigen Werten aber trotzdem möglich ist.

Der Fehlerdialog ist schlecht designed!

Es wäre gut, wenn man Popup-Fenster wie Settings, oder Cuelist Settings per Esc-Taste schließen könnte.

* “Input Assignment”

• “New Color- Z Gobolist”

Folgende Funktionen sollten enthalten sein:
1. Anzeige des Sessionnamen, IP Adresse, Name des PCs
2. Editierung des Sessionnamen
3. Kicken
4. Einstellung Programmer (separater, oder gespiegelter)

Später auch für Berechtigungen etc

Könnte man für den Warnhinweis den Hintergrund der Fenstertitelzeile (also da, wo im Video vom 22.12. DMXControl 3.2 New Project ...) steht, rot blinken lassen?
So zeigt zumindest eines unserer Datenübernahmeprogramme der Messgeräte den Datenaustausch mit dem MDE an

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”

Zoom und Position und Drehung

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.

siehe oben.

Das zurückstellen der Cuelist-Werte für Intensity, Time und Speed auf 100% ist mit der Maus über den Fader nicht machbar. Nur mit Pfeiltasten geht es einigermassen.
Bitte per Doppelklick auf 100% Reset einbauen !

Bei den Controls fuer Intensity und Strobe sollten (optionale) Buttons sein um automatisch hoch und runter faden zu koennen. Die Fadezeit sollte ueber ein Eingabefeld dort einstellbar sein. So wie man es von den Crossfadern bei vielen DJ-Programmen kennt.

nicht vorhanden

Es kommen ja mit DMXControl 3.2 weitere Master hinzu. Öffne ich nun das zugehörige Master-Fenster, werden mir alle Gruppen entsprechend untereinander angezeigt und jeder Master innerhalb der Gruppe in horizontaler Richtung. Dies führt bei größeren Projekten dazu, dass innerhalb des Fensters viel hin und hergescrollt werden muss, wenn entsprechend viele Master angelegt sind.

Für eine ständige Benutzung im Live-Betriebt wird in der Tat das Softdesk oder ein entsprechender Controller der bessere Ort bzw. Weg sein, die Master anzusteuern. Möchte man aber “mal eben” etwas korrigieren, was weder auf dem Softdesk, noch auf einem anderen Controller liegt, wird dies aktuell in diesem Fenster eher unübersichtlich.

Daher möchte ich anregen:

• Variante 1: Die Masterfenster werden grundsätzlich aufgeteilt und jeder Master erhält sein eigenes Fenster, was sich dann auch beliebig und platzsparender auf dem Bildschirm positioniert werden kann.
• Variante 2: Es wird nur die Aufteilung innerhalb des einigen Masterfensters optimiert und auf zwei Zeilen mit der Aufteilung Special Master und Group Master in Zeile 1 und Speed Master und Playback Master in Zeile 2 reduziert. Da bei DMXControl 3.2 festgelegt werden kann, ob ein Group Master angelegt werden soll und Speed und Playback Master generell Master sind, die vom User manuell erzeugt werden, wird der Platz in dem einen Fenster deutlich besser genutzt und man kommt als User bei kleinen Projekten möglicherweise ohne zu Scrollen an alle erforderlichen Master.

Das Presetfenster soll ähnlich zum Effektfenster:

• Icons (mit vorbereiteten Bildern, oder freihandzeichnen)
• Sortieren nach Geräteeigenschaften, oder Gerätegruppen etc.
• Favoriten für Presets anlegen
• Vorschau der Presets bei Mouseover etc.

Moving Heads und anderes Bewegtes Licht mit Joystick steuern.

s.o.

s.o.

Wie die CPU-Load anzeige im Monitoring fenster, zusätzlich die GPU-Load einbauen für GUI und Kernel

Hab da auch eine Lib die alle gängigen Grafik-Karten-Hersteller abdeckt, aber die bekommen wir nur auf direkte anfrage.
https://www.techpowerup.com/gpuz/

gebraucht für Timecodeplayer.

s.o.

Bei einem Doppelklick auf einen Trackbar eines Propertys dessen Default nicht 0 ist, wird dieser auf 0 gesetzt.

Er müsste aber auf den Defaultvert springen.

Es ist in Verbindung mit dem Softdesk meiner Meinung nach sehr wichtig, Multitouch zu implementieren, da man so zum Beispiel mehrere Buttons gleichzeitig betätigen kann oder einen Button und Colorpicker gleichzeitig zu nutzen.

Man hat 3 Presets erstellt, für Focus, Color und Intensity. Will diese nun auf eine Auswahl anwenden. Nun muss man alle 3 Presets der Reihe nach rüberziehen. Mehrfachselektionen sollten in der Presetliste möglich sein.

Es wäre eine nette erweiterung, wenn mann im Property Grig per rechtsklick auf einen Effekt, den Effect-Typ ändern könnte, z.B. von Sinus auf Swing.

Es wird für den Anfang einen rumimentären Audioplayer geben. Dieser wird dann sukzessive weiter ausgebaut.

Gemäß Diskussion:

(vorerst)
Zuletzt gespeichertes Projekt wird für Kernel zugreifbar gespeichert.
Option: einstellbar, ob vor dem Beenden des Kernels nochmal der aktuelle Stand gespeichert werden soll.
Option: dieses Projekt automatisch beim Start wieder zu laden.

Weiterhin beliebiges Projekt per Startparameter.
=⇒ AL: Started

EDIT/ERGÄNZUNG MARCEL 27.11.2018:

Ich habe zu dem ganzen Projekthandling folgende Idee wie man das Konzept mMn besser gestalten koennte.
DMXC3 wurde als Client/Server konzipiert und ist mMn ein wichtiges Feature, wenn auch (noch) wenig genutzt.

Aktuell wird beim Speichern immer dort eine Kopie erstellt, an deren Ort das Speichern ausgelösst wird. Angenommen wir haben 1 Server und 2 GUIs/Clients:

Client 1 speichert bei sich aus der GUI heraus. Client 2 arbeitet weiter, Client 1 lädt wieder und überschreibt alle Änderungen von Client 2. Und das ohne Rückfrage → Doof

Besser sollte es so sein:

“Projekt speichern” ist bei jedem Client nur noch ein Remote-Befehl an den Server das dieser bei sich in seinem Workdir das Projekt speichern soll.
Ebenso “Projekt laden” öffnet eine Liste und zeigt die auf dem Server abgelegten Projekte an, welche dann auf dem Server geladen werden können.

Neu hinzukommen sollten zwei Einträge:
“Projekt Downloaden/Exportieren” → Packt das Projekt in aktuellem Zustand als ZIP auf dem Server und schickt es an den entsprechenden Client zum runter laden.
“Projekt Hochladen/Importieren” → Lädt ein ZIP und transferiert es auf den Server in das Workdir und macht es somit in der “Remoteliste” zum öffnen verfügbar.

In diesem Zuge kann man darüber nachdenken auf dem Server nicht mehr als ZIP zu speichern und jedes Projekt optional sogar in ein lokales GIT oder ähnlich zu packen. Dann hat man sogar eine Versionierung.

Ich hab mir gedacht das eine andere art der Live View auch sehr interessant wäre.
Als Tabelle wie bei folgendem Bild.

Es wäre schön, wenn in der Cuelist anhand farblich markierter Zellen zu sehen wäre, wie der aktuelle Status der Cues ist.
Momentan ist ja nur Einblenden + aktuell Eingeblendet = Gelb und bereits eingeblendet = Grau (bei multiple fades stimmt das auch nicht)

Ich könnte mir da sowas vorstellen, wie

ist komplett erledigt = grau
ist nicht mehr das zuletzt eingeblendete, aber steuert noch aktiv Werte bei (tracking) =
ist eingeblendet =
wird aktuell eingeblendet =
wird als nächstes eingeblendet =

Es wäre schön, wenn man für eine komplette Cueliste das Timing + die Trigger abschalten und danach mit GO durchlaufen könnte.
Dafür sollte eine konfigurierbare standard Fade Zeit zwischen den Cues verwendet werden (Scheinwerfer schonen)

Es sollte die Möglichkeit geben (wenn Cossfade funktioniert), dass sowohl

-ein mit GO begonnener Fade mit dem/den Crossfader(n) fortgesetzt werden kann/können (damit das nicht versehentlich, z.B. durch berühren der Fader passieren kann, muss vorher die in FS#490 erwähnte Ignore Taste gedrückt werden. Die Fader übernehmen ab dem Punkt, an dem sie den aktuellen Einblendstatus erreicht haben, Fade 40%, Fader übernehmen ab 40% Stellung),

-als auch ein manuell begonnener Crossfade mit GO fortgesetzt werden kann.

Auf FS#280 setz ich noch einen drauf:

Split Crossfade.
Das sind zwei Überblendsteller. Einer zusändig für das aktuell eingeblendete Cue (ich nenns jetzt mal stage) und der zweite für das nächste (preset).

Normalstellung ist Stage 100, Preset 0.
Werden nun beide Steller gleichzeitig bewegt, ergänzen sich beide zu 100%. Es kommt ein ganz normaler Crossfade zu stande. Stage 80% + Preset 20%
Werden diese nun unterschiedlich schnell bewegt, kann z.B. ein Blackout realisiert werden. Stage 0%, Preset 0%

Kreise, die in Preset aber nicht in Stage enthalten sind werden vom PresetSteller ganz normal eingeblendet (Preset 50%, Kreise 50%)
Kreise, die in Stage aber nicht in Preset enthalten sind werden vom StageSteller ausgeblendet.

Eine Überblendung ist abgeschlossen, wenn Stage 0% und Preset 100% sind.

So würde ich mir die Funktion vorstellen

Grob gesagt, linkto gibt an, an welche Stelle gesprungen werden soll und loopcount gibt an, wie oft das passieren soll (0 = infinite)

id    | trigger | value | linkto | loopcount

Cue 1 | manual  |       |        |
Cue 2 | manual  |       |        |
Cue 3 | follow  | 1     |        |
Cue 4 | follow  | 1     |        |
Cue 5 | follow  | 1     |        |
Cue 6 | follow  | 1     | Cue 3  | 0
Cue 7 | manual  |       |        |

1. Go, Cue 1 wird eingeblendet
2. Go, Cue 2 wird eingeblendet
3. Go, Cue 3 wird eingeblendet.
Durch den Trigger follow läuft die Liste automatisch weiter (natürlich kann auch manual, oder ... benutzt werden) nachdem Cue 6 eingeblendet wurde, wird wieder Cue 3 eingeblendet. Ist loopcount > 1 wird der Sprung entsprechend oft ausgeführt.
Bei 0 passiert das unendlich oft. Dann könnte man zwei Fälle unterscheiden:
Alle Cues haben einen automatischen Trigger: GO beendet den Loop und blendet das erste Cue nach dem LinkTo Cue ein
Nicht alle Cues haben einen automatischen Trigger: Da GO bereits verwendet wird um im Loop die Cues durchzufahren könnte z.B. Load Cue 7, GO den Loop beenden.

Die Funktion ist sehr sehr praktisch, wenn auf der Bühne etwas gleiches wiederholt wird. Man hat hier weiterhin die Kontrolle mit GO bzw. (später dann hoffentlich Crossfade ;) ) sowie die gleiche Struktur wie andere Cues.
Außerdem ist man mit dieser Funktion schneller bei einfachen Chasern. Wenn ich weiß, dass die 6er Bar nur kurz während einer Szene ein bisschen blinken soll, muss ich nicht extra einen Chaser dafür anlegen und in die Cuelist einbinden.