Wie gesagt: am besten einmal einfach alles Fenster in der GUI schließen und dies als Layout abspeichern - so verfahre ich in meinen Projekten auch, die in Clubs oder auf einer Messe zum Einsatz kommen.
Posts by LightningBrothers
-
-
Der Programmer ist normalerweise immer geschlossen.
Hast du darauf geachtet, dass dies beim Laden auch wirklich der Fall ist? Denn aktuell kannst du ja immer nur das zuletzt gespeicherte Fensterlayout laden und da war der Programmer bei mir mit offen - wohlgemerkt in dem Stand der Projekte, die du seiner Zeit hochgeladen hattest.
-
Ja... das ist in der Tat meine Vermutung, dass es durch die Nutzung des Programmers für die Show auch beim Workshop-Projekt nach den zwei bis drei Tagen zu dem Absturz kommt. Deswegen auch die Frage:
Sehe ich das richtig, dass der Programmer in den Fensterlayouts durchweg geöffnet ist (selbst nur als Reiter im Hintergrund)?
Soll umgekehrt heißen: was passiert, wenn du mal wirklich alle Fenster in der GUI schließt (inklusive der Steuerungsfenster) und nur die beiden Softdesks offen sind?
Aber schlussendlich wäre mein Ansatz eben, das Projekt umzubauen, dass der Programmer gar nicht mehr genutzt wird.
-
Welche Logdatei hättest du gerne ?
Ich brauche in diesem Fall dafür keine Logs. Den ungünstigen Aufbau des Projekts habe ich da deswegen gesehen, weil ich mit dein Projekt in DMXC angesehen habe.
-
Ist das nicht gut ? Das wusste ich nicht.
Es ist insbesondere auf Grund der Gesamtkonstellation "altes Framework für die Darstellung" + "Programmerfenster offen" + "viele (schnelle) Werteänderungen" (aktuell) nicht gut. Deswegen hängt die GUI auch aktuell mal, wenn man komplexere Szenen mit vielen Werten für unterschiedliche Geräte (-gruppen) in den Programmer lädt und das Programmer-Fenster offen ist. Inwieweit sich das bessert, wenn irgendwann der Programmer technisch erneuert wurde, lässt sich auch erst dann sagen. Bis dahin ist der Weg, eine komplette Liveshow über den Programmer zu fahren, keine gute Wahl.
Der Audiosanalyser ist auf den beiden Systemen (T-W-Licht und WSL-Licht) deinstalliert.
Ich kann mir vorstellen, dass es in diesem Fall wirklich eher an dem Aufbau des Projekts liegt und weniger am Audio-Analyzer.
-
Hallo Christian!
Nutzt hier zwei Parameter-Master als Werte für die beiden Gerätefunktionen und speicherst dies in einer Cuelist. Auf den Executor-Zug legst du dann je einen der beiden Parameter-Master. Das Input Assignment brauchst somit gar nicht, um dies umzusetzen. Auch eine Anpassung am DDF #1577 ist dafür nicht erforderlich.
Stefan
-
Ein Problem gibt es aber: Die Ansteuerung der Motorfader über den DMXCMixer funktioniert nur bei einzelnen Geräten. Da ich meistens nur ganze Gerätegruppen steuere, deren Geräte dann ohnehin den gleichen Wert haben, wäre es toll, ich könnte die Fader auch auf den Wert der Gerätegruppe (bzw. falls deren Geräte unterschiedliche Werte haben meinetwegen den Mittelwert davon o.ä.) springen lassen. Gibt es dafür eine Lösung?
Vom theoretischen Ansatz her gibt es hier auch eine Lösung, aber da musst du ein bisschen in dem entsprechenden Connectionsset basteln. Du musst dir hier ein einzelnes Gerät mit dem Listen-Node aus der gewählten Gerätegruppe ausgeben lassen, mit dem du ins DMXC-Mixer-Node gehst. In diesem Fall darf dieses Gerät aber nicht für das Programmer-Node hergenommen werden. Da musst du ebenfalls die ID der gewählten Gerätegruppe ans Programmer-Node schicken und folglich eine Umschaltung zum Beispiel mit dem Eingangswähler-Node bauen. Woher die Werte für die Gerätefunktionen kommen, ist dann wiederum egal - wenn eben alle Geräte in der gewählten Gerätegruppe die gleichen Werte haben (sollen). Fannings gehen dann nicht, wie
nutzer99 bereits gesagt hat. -
Okay, mit Makros muss ich mich jetzt erstmal beschäftigen, die sind für mich noch Neuland.
Das ist gar nicht so wild wie es klingt:
- Im Project Explorer ein neues Macro anlegen und benennen.
- In den Eigenschaften ggf. auch die Fader und Buttons benennen oder auch die Anzahl von Fadern und Buttons anpassen.
- Das Macro auf einen Executor legen. Hast du mehr wie ein Fader und vier Buttons musst du dort ggf. die passenden Buttons auswählen.
- Im Input Assignment mit den gewünschten Nodes verbinden, bei dir also mit dem Speed Master, wo du den Fader zum Beispiel auf den Input "Fader Value" legst und je einen Button auf "Sync" und "Learn".
-
Ich hänge mich gerade ein bisschen an dem Programmer auf, weil es hier auf Grund des verwendeten Frameworks zum Anzeigen der Inhalte schon oft Probleme bei der Performance gab - vor allem wenn dieser geöffnet ist.
Ich habe mich nun mal weiter in deinem Projekt "T-W-Licht" orientiert. Also ich bleibe bei meiner Vermutung, dass die Instabilität in deinen beiden Projekten, aber insbesondere im Projekt "T-W-Licht" daher rührt, dass du hier mit dem Spektrum des Audio Analysers laufend Werte im Programmer aktualisierst und so eine Show aus dem Programmer fährst.
Da ich davon ausgehe, dass die Bedienweise über die beiden Softdesks bei dir etabliert ist, solltest du dir den "Unterbau" vornehmen und sämtliche Effekte vom Programmer unter Verwendung von Parameter- und Color-Mastern in Cuelists umziehen. Damit löst sich am Ende auch das Problem, dass du nicht "sauber" zwischen den verschiedenen Effekten umschalten kannst. Möglicherweise brauchst du dann auch nicht mehr zwischen "Workshop" und "Disco" trennen und hast wieder ein Projekt für alles. Wenn du hierzu noch Tipps brauchst, melde dich bitte - entweder in einem separaten Thread oder du hängst deine Fragen in bereits thematisch passenden Threads an.
Unabhängig davon würde ich mich aber noch über Antworten zu den beiden Fragen aus meinem vorangegangen Post freuen.
-
Ich denke für "In" werde ich das Interface verwenden und mir ein separates aktives für den Output zulegen.
Beim Nodle U1 bzw. Nodle R4S hättest du beides direkt in einem Interface.
-
Hallo Axel,
nachdem ich DMXControl 3.3.1 nun am vergangenen Wochenende selbst mal wieder etwas länger habe laufen lassen (bei mir waren es etwas über 50 Stunden), habe ich nun mal in deine Projekte geschaut. Dabei sind mir Dinge aufgefallen:
- Generell gefragt: hat es einen Grund, dass du viele der Geräte nicht über eine bzw. mehrere Cuelist steuerst, sondern dies direkt über den Programmer löst?
- Sehe ich das richtig, dass der Programmer in den Fensterlayouts durchweg geöffnet ist (selbst nur als Reiter im Hintergrund)?
Ich hänge mich gerade ein bisschen an dem Programmer auf, weil es hier auf Grund des verwendeten Frameworks zum Anzeigen der Inhalte schon oft Probleme bei der Performance gab - vor allem wenn dieser geöffnet ist. Wenn du dann auf Grund der von dir gewählten Programmierweise auch noch laufend Werte hineinschiebst bzw. veränderst, könnte dies ebenfalls mit eine Ursache sein. Wir sagten hier ja schon länger, dass die Aufgabe des Programmer vorrangig im Programmieren einer Show / eines Projekts liegt und weniger, mit dem Programmer auch eine Show zu fahren. Um während einer Live-Show trotzdem Werte live manipulieren zu können, wurden mit DMXControl 3.3.0 ja extra noch die Color- und Position Master ergänzt.
Dies mal meine Beobachtungen für den Moment. Ich werde nun im Anschluss das Projekt "T-W-Licht" für mich mal dahingehend ergänzen, dass ich es bei mir mit realen Geräten über den Tag mal laufen lassen kann.
Stefan
-
Ich habe mir dein Projekt auch mal angesehen und kann das Verhalten bestätigen.
Was mir hier ergänzend aufgefallen ist: sobald ich den Fader vom Speed Master entweder im entsprechenden Executor oder direkt im Master-Fenster mit der Maus kontinuierlich bewege, bleibt der Speed Master ebenfalls stehen. Erst wenn ich die Maus länger an einer Position belasse, beginnt der Speed Master nach einem kleinen Moment wieder zu laufen. Dieses Verhalten sehe ich so an sich schon als korrekt an. Denn wenn ich den BPM-Wert über den Fader ändere und der Speed Master in diesem Moment weiter Beat Signale ausgeben, würden alle Effekte und Cuelists wie wild flackern.
Aber was natürlich nicht sein darf, dass dies nicht so funktioniert, wenn man wie du den BPM-Wert für einen Speed Master in einem Executor-Track per Fader einstellt.
Damit du nun nicht komplett auf den Speed Master in der Timecode-Show verzichten musst, habe ich gerade erfolgreich folgendes getestet: Lege dir für den Speed Master zum Beispiel ein Macro an. Den Fader und die Buttons verbindest du im Input Assignment mit dem Speed Master und im Executor ersetzt du den Speed Master durch das Macro. Du musst war dann (weil es sich um ein anderen Executor-Typ handelt) die Werte in der Timecode-Show neu setzen, aber mit diesem kleinen Zwischenschritt bleibt die Nutzungslogik gleich - inklusive mit der Möglichkeit, Dinge für den Speed Master über das Macro in der Timecode-Show aufzuzeichnen.
-
Nein... dazu machen wir keine Aussagen und damit implizite Versprechen (mehr). Das ist für beide Seiten einfacher. Eine neue Version kommt, wenn sie fertig ist.
-
Aber habt Ihr vielleicht sowas wie Best Practice, wie man hier den Überblick behalten kann?
Am Ende ist es das Thema klare Benennung von allem. Bei
- Cuelists und Cuelist Groups ist es der Name der Cuelists bzw. der Cuelist Group
- Cues ist es sowohl der Name der Cue (wenn deren Inhalt nicht schon aus dem Namen der Cuelist hervorgeht) als auch die Kommentare
- Mastern ist es sowohl die Nummer (welche man auch frei vergeben kann, also auch 821 oder 53) und der Display Name
- Graphen / Connectionsets im Input Assignment ist es der Name des Graphen und dessen Zuordnung zu einer gleichermaßen sinnig benannten Bank
- Elementen im Softdesk ist es der Name des Softdesks ingesamt (wenn mehrere verwendet werden) und der Display Name des Elements
Darüber hinaus kannst du ja in vielen Zweigen im Project Explorer zusätzlich noch Ordner anlegen.
Das ordentliche Benennen von allem erfordert natürlich einiges an Disziplin. Selbst bei meinen Projekten finde ich immer wieder noch Optimierungspotential, gerade wenn ich umfangreichere Änderungen durchführe. Insgesamt versuche ich aber meine Projekte nach einem recht ähnlichen Schema aufzubauen. So kann ich auch bei großen Projekten mit einigen hundert Cuelists und Connectionsets sehr gut am Namen ausmachen, was diese beinhalten und sie durch eine für mich nachvollziehbare Ordnerstruktur im Project Explorer auch schnell finden.
Wie ich hier arbeite, kannst du in meinem Live-Tutorial "Clubshow mit DMXControl 3" auch sehen.
-
Ich bin zwar nicht
JPK Aber ja… das macht dann keinen Unterschied, ob Moving Heads oder Scanner genutzt werden. -
Hallo Uwe,
auch hier verweise ich einmal ins Wiki. Du solltest dort auch unbedingt mal die Suchfunktion nutzen, die sich hinter der Lupe versteckt...
Stefan
-
Nicht so schnell
Da bei den OpenDMX-Interfaces (um das es sich hier auch handelt) nur eine Leiterbahn zur Richtungsumschaltung zwischen FTDI und dem RS485-Treiber vorhanden sein muss, klappt das bei praktisch allen OpenDMX-Interfaces, auch wenn der Hersteller es nicht explizit dazu schreibt.Okay... ich denke mir dazu nochmal was aus.
-
Das wäre blöd. Ich hatte mich da auf die "Unterstützen Interfaces" verlassen. Irgendwoher muss die Info ja kommen.
Also nachdem ich mir das bei der Produktbeschreibung des Herstellers auch nochmal angesehen habe, sage ich nun auch, dass das genannte DMX-Interface nur DMX-Daten senden, aber keine empfangen kann. Ich habe die Tabelle daraufhin aktualisiert.
Nutze aber eigentlich DMX Control 3. Wobei es für das Thema eigentlich egal sein sollte.
Kann bitte ein Moderator/Admin den Thread nach DMX Control 3 verschieben?
Das habe ich bereits gemacht, wie du siehst.
-
Hallo!
Schaue mal in den Wiki-Artikel für das 3Dconnexion Plugin. Damit bekommst du vielleicht eine grobe Idee, wie das Auslesen von Werten für Funktionen läuft.
Stefan
-
Hello.
This behaviour is (currently) normal, that you must stop and start the again after you change the timings.
Also when you change the assignments in the device groups, modify the order in a device group or you disable and enable devices, you have to restart a cuelist.
Stefan
