Posts by LightningBrothers

    Hallo!

    Die Frage ist aber: möchtest du dies für eine Live-Steuerung nutzen? Wenn ja, dann ist der bessere Weg, Cuelists zu bauen, deren Cues verschiedene Varianten der Fanning-Operatoren zusammen mit den zugehörigen Color Mastern beinhalten. Das könnte dann etwa so aussehen:

    • Cue 1: {ColorMaster 1} > {ColorMaster 2}
    • Cue 2: {ColorMaster 1} <> {ColorMaster 2}
    • Cue 3: {ColorMaster 1} # {ColorMaster 2}

    Der Vorteil des Wegs über Cuelists ist, dass du dann zwischen den verschiedenen Kombinationen auch überblenden kannst.

    Stefan

    Ich habe sie einfach mal (wie ich das aus dem Input Assignment kenne) miteinander verbunden

    Das war genau der richtige Schritt. Durch das Ziehen einer Verbindung weist du die Komponenten an, sich untereinander zu verbinden. Möglicherweise war in einem der Kästen eben eine andere Network-ID eingetragen, weil du vielleicht mal mit einem "verteilten" System gearbeitet hast. Unterscheiden sich diese, bauen Umbra, Kernel und GUI die Verbindung nicht automatisch auf.

    Es gibt aktuell keine Gesamtlautstärke einer Timecode Show

    Deswegen wurde hier bereits das Ticket FS#5410 : Timecodeplayer-Executoren-Fader als Lautstärkeregler der zugehörigen Audiospure(n) aufgemacht.

    Über eine Ausgabe in das Makro-Bitmap bekomme ich die Information über Laufzeit und Status in den Executor. Das sieht dann wie folgt aus:

    Du kannst dein Connectionset noch ein bisschen dahingehend vereinfachen, indem du die RGB-Werte für die verschiedenen Status der Audiodatei direkt im Input Selector einträgst.

    Hallo Uwe!

    An dieser Stelle kommt es immer ein Stück weit darauf an, was du wie mit (d)einem (MIDI-) Controller oder auch im Softdesk machen möchtet.

    Was definitiv nicht dauerhaft sinnvoll ist:

    • Du hast innerhalb eines Verbindungssets mehrere parallele Signalwege ohne Abhängigkeiten untereinander, wo
      • der Button 1 die Szenenliste 1 steuert und darauf reagiert,
      • der Button 2 die Szenenliste 2 steuert und darauf reagiert
    • Temporär kann es mal für Tests helfen, wenn man eine neue Logik aufbaut und die alte noch parallel braucht

    Fazit: ja, die Anzahl der Verbindungssets ist zwar insgesamt sehr überschaubar, aber man brauch für die "Wartung" sehr viel Platz auf dem Bildschirm, es wird schnell unübersichtlich und man kann hier immer nur das gesamte Verbindungsset aktivieren oder deaktivieren.

    Was in bestimmten Konstellationen durchaus Sinn macht:

    • Du hast im Verbindungsset eine größere Anzahl an Buttons, die entweder etwas steuern oder auf etwas reagieren und die in einer unmittelbaren (logischen) Abhängigkeit zueinander stehen, wie
      • du hast mehrere Buttons und auch Fader, um damit das Programmer-Node anzusprechen
      • du hast einen Button, einen Fader und ggf. auch mehrere Master, um ein Szenenlisten-Node zu steuern
      • du baust dir ein Verbindungsset für einen Executor

    Fazit: Hilft in solchen Fällen, "doppelte Informationen bzw. Definitionen" in der Eingangszuweisung zu vermeiden und beschleunigt das Ändern beispielsweise einer Szenenliste. Allerdings braucht man mehr Platz auf dem Bildschirm und man muss je nach Umfang suchen, bis das betreffenden Node gefunden ist.

    Das ist zu empfehlen, wenn es sich im Projekt realisieren lässt

    • Die Verbindungssets nicht nur auf Basis "welche Aktion soll ausgeführt werden" aufzuteilen, sondern auch entsprechend "womit wird die Aktion aufgerufen" - also nach MIDI, Softdesk und Macro Board etc.

    Fazit: Die Anzahl der Nodes pro Verbindungsset sinkt, aber die Anzahl der Verbindungssets insgesamt steigt. Die nachvollziehbare Benennung der Verbindungsset bekommt zunehmend an Bedeutung.

    Das ist in DMXControl 3 auch möglich, eventuell aber

    • Du teilt die Aktionen (Szenenliste starten, Faderwert setzen etc.) und Reaktionen / Feedback (Szenenliste hat den Status ..., Wert des Faderes lautet ...) in zwei Verbindungssets auf.
    • Du möchtest parallel sowohl mit (d)einem MIDI-Controller, einem Softdesk und / oder einem Macro Board arbeiten, deren Buttons etc. am Ende die gleiche Aktion ausführen sollen und du dies der Einfachheit halber für den Moment nicht aufteilst.

    Fazit: Erstes reduziert die Anzahl der Nodes pro Verbindungsset nochmals, mündet aber in vielen doppelten Angaben. Man kann aber sehr feingliedrig sagen, welche Teile arbeiten sollen und welche nicht. Zweiteres hat den unmittelbaren Nachteil, dass du zum Beispiel nicht sagen kannst "ich brauche die Steuerung über das Softdesk nicht und will nur mit MIDI oder Macro Board arbeiten".

    Daran solltest du grundsätzlich denken

    • Benenne deine Graphen und auch deine Bänke sinnvoll, damit du bereits am Namen erkennen kannst, was sie wie wo steuern.
    • Aus der Erfahrung heraus sollten einer größeren Anzahl von Verbindungssets diese auf mehrere Bänke aufgeteilt werden, gerade wenn es das Projekt zulässt

    Ich persönlich entscheide hier immer von Projekt zu Projekt und immer im Abhängigkeit dessen, was ich umsetzen möchte. Daher findet sich in meinen Projekten jede der zuvor genannten Varianten - wobei erste jedoch nur kurz existiert, wenn ich etwas testen möchte.

    Bei der Ausarbeitung dieser Antwort habe ich mich bewusst nicht auf Gerät XY bezogen - dies ist eher eine grundlegende Herangehensweise in der Eingangszuweisung und damit völlig unabhängig vom Gerät etc. mit dem du arbeiten möchtest.

    Hallo!

    Das Verhalten ist so korrekt. Das Position-Panel ist ja nur dann aktiv und „geht mit“ wenn du Werte im Programmer liegen hast - entweder weil du sie über die Gerätesteuerung (Device Control) oder die Steuerungsfenster (Control Pane) eingestellt hast bzw. eine Szene zur Bearbeitung in den Programmer geladen hast. Wählst du dann die betreffenden Geräte in der Bühnenansicht (Stage View) aus, gehen alle Steuerungsfenster mit.

    Alle Master dagegen arbeiten innerhalb von Szenen von Szenenlisten oder werden im Input Assignment verwendet. Egal wie du sie aber einsetzt - es gibt keine Verknüpfung zu den Steuerungsfenstern.

    Stefan

    Guten Abend...

    der erste Punkt für die entsprechende Unterstützung sind in der Tat die Log-Dateien von allen Systemen, wo dieses Problem bis jetzt aufgetreten ist sowie im Idealfall auch die zugehörigen Projektdateien. Wenn daraus nichts direktes ersichtlich ist, müssen in der Tat "schwere Geschütze" aufgefahren werden.

    Stefan

    PS.: Ich habe den Titel des Threads mal um ein Schlüsselwort "Langzeitbetrieb" ergänzt, weil dieser Punkt eben entscheidend für dein Problem ist.

    Hallo!

    Wenn du dich ein bisschen von dem Gedanken löst "Ich will exakt x Sekunden Nebelausstoß und ich will y Sekunden Pause zwischen dem Ausstoß", kannst du es in der Tat deutlich einfacher Lösen. Dafür braucht es

    • drei Cuelists und
    • zwei Fader, um den Wert für den Fade-Factor zwei der drei Cuelists zu manipulieren
    • einen Fader zum Ändern der Intensität sowie
    • zwei Buttons zum Ein- / Ausschalten des "Timers" und zum manuellen Nebeln

    Um nun die Zeit zwischen den Nebelausstößen einzustellen, baust du eine Cuelist, welche

    • als erste Cue eine leere Cue umfasst, der du über die Fade bzw. Wait-Time hauptsächlich mitgibst, wie lange die minimale Zeit für die Pause zwischen zwei Nebelausstößen betragen soll.
    • als zweite Cue eine Special Cue beinhaltet, über die du die eigentliche Cuelist für den Nebenausstoß aufrufst.

    Der Fader vom Softdesk wird dann mit dem Input für den Fade-Factor der Cuelist verbunden. Liegt der Wert bei 100%, läuft die Cuelist mit den entsprechend angegebenen Zeiten. Reduzierst du ihn, läuft die Cuelist entsprechend langsamer. Über den Wertebereich des Faders kannst du hier ggf. einen Mindestwert definieren. Die Cuelist für die Zeit zwischen den Nebelausstößen läuft kontinuierlich im Loop.

    Die Cuelist für den Nebelausstoß läuft immer nur einmal und beendet sich mit der letzten Cue. Deswegen umfasst die Cuelist für den Nebelausstoß ebenfalls zwei Cues, wobei

    • die erste Cue beinhaltet den gewünschten Wert für die Intensität des Nebelausstoß entweder als festen Wert oder in Form eines Parameter-Masters
    • die zweite Cue ist eine leere Cue, die die minimale Dauer des Ausstoß selbst bestimmt

    Analog zur Cuelist für die Pause zwischen den Nebelausstößen verlängerst du mit dem Fade-Factor die Zeit für die Dauer des Nebelausstoßes. Insgesamt liegt die Logik für die Zeit hier eben nun in den Cuelists und weniger im Input Assignment. Aber auch der Vorschlag von MWSysTech ist definitiv nice - lässt sich aber erst ab DMXControl 3.3.1 so realisieren.

    Stefan

    Wenn du mit den Cuelists jedoch die jeweils längste Zeit definieren möchtest geht das auch. Dann musst du mit einem Wertebereich von 1 bis 10 für den Fadefactor arbeiten.

    Ich hatte das mit den Presets analog zur Szenenbibliothek aus DMXC2 verstanden....

    Nein. Hier tickt DMXControl 3 anders.

    Es geht ja nur um referenzierte Presets, da Gerätepresets bei meinem setup keinen Nutzen haben.

    Am Ende macht ein Gerätepreset das gleiche, wenn du es komplett einfügst, wie ein referenziertes Preset. Der einzige Unterschied ist: fügst du dem Preset noch eine weitere Gerätefunktion hinzu (also statt nur Werte für Dimmer auch noch eine Farbe), wird dies von referenzierten Presets direkt übernommen, wenn du die Szenenliste danach erneut ausführst.

    Hallo!

    Es gibt hier mehrere Ansätze:

    • Gerätebilder und Funktionsicons: Du kannst ja in den Presets sehen, welche Geräte mit welchen Eigenschaften in den Prests gespeichert sind. Vielleicht bekommst du dann schon eine erste Idee, wo sie verwendet wurden.
    • Preset bearbeiten: Reicht dir die Information aus den Gerätebildern und Funktionsicons nicht, kannst du das Preset zum Bearbeiten in den Programmer laden. Im gleichnamigen Fenster werden dir dann für die jeweiligen Geräte / Gerätegruppen die exakten Werte für die entsprechenden Funktionen angezeigt.
    • Preset löschen: Wenn du ein Preset löschst, prüft DMXControl 3, wo dieses verwendet wurde. Wird das Preset in einer Szene verwendet, erscheint ein entsprechendes Fenster und zeigt dir die betreffenden Szenen und Szenenlisten an.

    Bevor du hier aber anfängst zu suchen solltest du deinen ganzen Presets einen individuellen Namen geben. Denn eine vierte Möglichkeit ist:

    • Szenen mit Presets bearbeiten: Wenn du eine Szene zum Bearbeiten in den Programmer lädst, wird dir dort neben den Werten für die Funktionen auch der Name des Presets oder der Presets (ja in einer Szene kann man auch mehrere Presets parallel nutzen) angezeigt. Dies gilt aber nur für Presets, die als Geräte-Preset (Device Preset) verwendet werden. Bei referenzierten Presets klappt dies nicht.

    Grundsätzlich macht die Nutzung von Presets in DMXControl 3 nur dann Sinn, wenn du sowohl innerhalb aber auch über mehrere Szenenlisten bestimmte Lichtstimmungen mehrfach komplett oder auch nur in Teilen nutzen (also wiederverwenden) möchtest. Das können zum Beispiel gemischte Farben für LED-PARs oder bestimmte Positionen für Movingheads sein. Auch können in Presets Effekte und Filter gespeichert und dann mehrfach in exakt dieser Konfiguration verwendet werden.

    Hast du aber Szenen nur der Bequemlichkeit als Preset gespeichert und dieses Preset nicht nochmal verwendet, hast du dir so am Ende unnötig Arbeit gemacht und dein Projekt verkompliziert.

    Stefan

    Wenn ich das richtig überflogen habe, arbeitest du du ja aktuell im Netzwerk 0 und im Subnetz 1.

    Funktioniert es, wenn du mal Netzwerk 1 bzw. 2 und Subnetz 0 verwendest? Mit der Konfiguration arbeite ich schon sehr lange mit meinen Art-Net-Nodes (sowohl das Showtec Net 2/3, dem Quad-Node sowie Octo-Node von Ulrich Radig) - und auch gerade in dem Moment wieder, wo ich diesen Post abschicke.