Hallo Stefan,
danke für deine Anregung. Werde ich mir zeitnah ansehen. Klingt auf jeden Fall sehr sinnvoll.
Da das Projekt über die letzten Jahre gewachsen ist, fehlt es z.T. an der entsprechenden Struktur bzw. an der eleganten Art der Umsetzung. Daher vielen Dank für den Tipp, um das Projekt wieder etwas abzuspecken.
Danke und viele Grüße
Jonas
Hallo zusammen,
besten Dank für die schnellen und ausführlichen Antworten.
Das beschriebene Vorgehen leuchtet auch vollkommen ein. Ich habe dies bisher auch in meinem Projekt weitestgehend versucht so umzusetzen, jedoch folgen daraus bei mir mittlerweile mehr als 500 Culists und entsprechend unübersichtliche Connectionsets. Auch auf die Ladedauer wirkt sich dies bei meinem etwas schwächeren Laptop mittlerweile aus. Aus diesem Grund bin ich auf die Überlegung gekommen, z.B. bei den Moving Heads verschiedene Fanning-Operatoren mit der gleichen Grundbewegung in eine Cuelist zu packen, auch wenn dadurch wie richtig beschrieben Priorisierungen etc. nicht mehr möglich sind.
Anbei, wenn auch sicher nicht auf anhieb nachvollziehbar, der aktuelle Stand des wirklichen Projekts.
Der ganze Aufbau ist für das verhältnismäßig wenige Equipment sicher etwas überdimensioniert, jedoch weiß man nie was noch kommt 
Danke Stefan, für dein Live Tutorials. Bin auch schon auf die nächste Folge gespannt, da man immer wieder neue Ideen, Möglichkeiten und Lösungen findet und diese dann kopieren kann.
Danke euch und schöne Grüße
Jonas
Hallo zusammen,
ich bin mir nicht sicher, ob ich die Einstellungen der Cuelist unter "GoNext Behavior" falsch verstanden habe, diese falsch nutze oder ob es Bug ist. Ich habe dazu auch nichts im Forum finden können. Daher kurz die geplante Verwendung anhand eines vereinfachten Beispielprojekts:
Um die Anzahl an Cues übersichtlich zu halten und trotzdem möglichst viel Flexibilität zu erhalten, möchte ich eine Haupteigenschaft pro Cuelist (im Beispielprojekt die Farbe) mit einer weiteren Eigenschaft in den jeweiligen Cues (im Beispielprojekt verschiedene Dimmer-Fanning Möglichkeiten) kombinieren. Die Cues sollen über Buttons (im Beispiel entsprechend der Cuelists je einer für blau, rot, grün) gestartet werden und über einen Schieberegler ein entsprechendes Dimmer-Fanning ausgewählt werden können (im Beispiel ensprechend der Cues 0: <> , 1: #, 2; |). Wenn ich über das Input Assignment nur einen Culist über den "Go to" Eingang mit den Regler verbinde, macht er genau was er soll, bei mehreren angeschlossenen Culists starten diese willkürlich. Ich habe gehofft, dass die Einstellung "Start Cuelist" -> false unter "GoNext Behavior" dies unterbindet, was jedoch leider nichts ändert. Habe ich diese Eigenschaft falsch verstanden bzw. umgesetzt oder handelt es sich um einen Bug.
Anbei das Testprojekt zur hoffentlich besseren Veranschaulichung.
Mit ist bewusst, dass sich dies natürlich mit mehr Aufwand und einzelne Cuelists umsetzen lässt, jedoch ist die tatsächliche Anwendung im Projekt deutlich umfangreicher als im simplen Testprojekt.
Besten Dank bereits für die Unterstützung und viele Grüße
Jonas
Hallo Stefan,
sehr gut 
Danke für die super schnelle Rückmeldung.
Viele Grüße
Jonas
Hallo zusammen,
auch ich bin vor kurzem vom DMXC2 auf die neue Version DMXC3 umgestiegen und kämpfe aktuell mit zwei Problemen, zu denen ich leider keine Lösung gefunden habe.
Danke zunächst für diese klasse Software, die nach gewisser Einarbeitung diese Vielzahl an Möglichkeiten bietet. Mein Ziel bzw. Wunsch ist es, mehrere (flexible) Gerätegruppen über separate Cuelisten für diverse Farb-, Helligkeits- und Bewegungsszenarien zu programmieren, um relativ einfach und systematisch über die Gerätegruppen sowohl auf den Aufbau und mittels vorbereitete Cuelists auf die Anforderungen an die Lichtsteuerung flexibel reagieren zu können.
Damit für jede Gerätegruppe nur eine Cuelist pro Eigenschaft (Helligkeit, Farbe, Bewegung) läuft, habe ich diese in Cuelistgruppen mit "Single list running" gepackt. Da sich die Gruppen zum Teil überschneiden (z.B. Gruppe "All" mit Untergruppen "Par", "Bar",...), möchte ich gerne mittels SignalLamp auf dem Softdesk den Status der Cuelist Group anzeigen lassen, um den Überblick über die Signalherkunft zu behalten.
Leider aktualisiert sich der Cuelist Group Node (Lampe hängt am Ausgang "Running Counts") bei mir nicht und damit zeigt mir auch die Lampe nichts an. Ist dies ein bekanntes Problem, habe das nur ich oder bin ich die Sache falsch angegangen?
Zum anderen würde ich zur schnelleren Handhabung gerne die Buttons im Softdesk zusätzlich über die Tastatur ansteuern. Dies funktioniert bei den Toggle-Button sehr gut, bei den Nontoggle-Button jedoch leider nicht. Hat dies einen Grund oder ist dies ein Bug oder nur meine Unfähigkeit?
Auf die direkte Ansteuerung der vielen (>500) Cuelists über die Tastatur zusätzlich zum Softdesk möchte ich verzichten. Die Anzahl der Buttons und Fader auf dem Softdesk habe ich versucht durch einen modularen Aufbau gering zu halten (Anwahl einer Gerätegruppe mittels Toggle Button + Nontoggle Button für Auswahl der jeweiligen Eigenschaft (Dimmer, Color) + Fader zur Parameteränderung (z.B. Fanning)). Der Screenshot vom aktuellen Projektstand verdeutlicht die Idee hoffentlich. Somit hätte ich mit der Verknüpfung zwischen Tastatur und Softdesk deutlich weniger und zudem abschaltbare Connectionsets. Hierfür möchte ich jedoch auch die entsprechenden Nontoggle Button ansteuern können.
Ich hoffe die beiden Probleme und Hintergründe sind in der Kürze verständlich geworden 
Danke bereits für die Unterstützung und die tolle Software.
Viele Grüße
Jonas
