Ich habe jetzt erstmal wieder die 3.3.0 installiert. Habe in zwei Wochen eine Veranstaltung, die ich vorbereiten muss. Mit der 3.3.0 funktionierte es wieder auf anhieb. Ich hab nichts weiter verändert.
Ich würde in 2 Wochen, wenn die Veranstaltung durch ist, nochmal einen Versuch starten, dann schicke ich euch die Logs ...
Die Einschaltreihenfolge habe ich mal auf vermutlich alle Möglichkeiten variiert. Das hat keinen Unterschied gemacht.
Ich habe in den erweiterten Firewall-Einstellungen die "eingehenden Regeln" für DMX-Control gelöscht. Danach habe ich die 3 Meldungen beim Start von DMX-Control bekommen, wie du das beschrieben hast. Ich habe alle Haken gesetzt und alles zugelassen.Ich hoffe, das war das was du gemeint hast?
Hat leider auch nix gebracht.
Vom Netz trennen und separat starten bringt leider auch nichts:
05:55:51 WARN GrpcManager - Network not available. Only listening Broadcast
05:55:51 INFO KernelRunManager - Startup finished, ready!
DMXControl 3.3: 05:55:58 INFO Umbra_gService - Unable to connect to Umbra DefaultUnknownServerName @ 127.0.0.1
05:55:58 WARN Umbra_gService - Unable to contact any of the Umbra DefaultUnknownServerName IPs: [127.0.0.1]
05:55:58 INFO Umbra_gService - Same IP Addresses detected [127.0.0.1], prefering Localhost to connect first
05:55:58 INFO GrpcManager - Connecting to Umbra Server on Host 127.0.0.1:17475
05:56:00 WARN Umbra_gService - Unable to contact any of the Umbra DefaultUnknownServerName IPs: [127.0.0.1]
Mir ist aufgefallen, dass wenn ich im Kernel manuell verbinden will, ich eine Fehlermeldung bekomme. Vielleicht könnt ihr ja etwas damit anfangen:
Connecting to 127.0.0.1
DMXControl 3.3: 05:59:40 INFO GrpcManager - Connecting to Umbra Server on Host 127.0.0.1:17475
05:59:41 ERROR GrpcManager - 1 Attempt, Unable to login to Umbra Server: Status(StatusCode="Unavailable", Detail="Error connecting to subchannel.", DebugException="System.Net.Sockets.SocketException: Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigerte."). Retry in 2 Seconds
05:59:43 ERROR GrpcManager - 2 Attempt, Unable to login to Umbra Server: Status(StatusCode="Unavailable", Detail="Error connecting to subchannel.", DebugException="System.Net.Sockets.SocketException: Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigerte."). Retry in 2 Seconds
- Mein Betriebssystem ist Windows 11 Home, Version 23H2
- Wenn ich auf "Auto-Position" Drücke ändert sich nichts. Der Netzwerkexplorer bleibt leer.
- Bis jetzt habe ich das Programm immer über den großen "DMXControl 3.3.1" Button gestartet
- DMXC 3.3.1 habe ich über ein Update installiert (quasi über 3.3.0 drüber installiert)
Ah OK. Dann ist die GUI auch nicht mit dem Umbra verbunden. Der Netzwerk-Explorer ist bei mir leer.
Im Umbra sind nur folgenden Einträge:
05:07:37 INFO DMXControl 3 Umbra - Using Log4Net Config File: C:\Program Files (x86)\DMXControl3\Umbra\Config\log4net_conf.xml
05:07:37 INFO DMXControl 3 Umbra - Logs will be written to: C:\Users\Bernd\AppData\Roaming\DMXControl Projects e.V\DMXControl\Umbra\Log
05:07:37 INFO UmbraRunManager - Umbra V3.3.1.1136 starting! (x64)
05:07:37 INFO UmbraRunManager - Umbra Build Time: 10.08.2025 20:18:35 UTC
05:07:37 INFO UmbraRunManager - Umbra Running in 64bit Mode
05:07:38 INFO UmbraSettingsManager - Settings loaded
05:07:39 INFO UmbraRunManager - Collected 35 Services!
05:07:39 INFO UmbraRunManager - Umbra ready to accept connections
Umbra 3.3: 05:07:40 INFO UmbraNetManager - Following IPs found: [192.168.178.47]. Sending Multicasts.
Neu gestartet habe ich mittlerweile schon mehrmals. Ich habe die 3.3.1 auch schon ein zweites mal installiert.
connect 127.0.0.1 bringt nichts:
Connecting to 127.0.0.1
DMXControl 3.3: 19:29:11 INFO GrpcManager - Connecting to Umbra Server on Host 192.168.178.47:17475
19:29:12 INFO Umbra_gService - Unable to connect to Umbra DefaultUnknownServerName @ 127.0.0.1
19:29:13 WARN Umbra_gService - Unable to contact any of the Umbra DefaultUnknownServerName IPs: [192.168.178.47, 127.0.0.1]
Wie stelle ich fest, dass die GUI mit dem Umbra verbunden ist?
Laut Launcher sind alle drei Komponenten aktiv. Ich habe jetzt mal Kernel und Umbra eingeblendet. Laut Kernel kann dieser sich nicht mit dem Umbra verbinden:
18:47:04 INFO Umbra_gService - Same IP Addresses detected [192.168.178.47, 127.0.0.1], prefering Localhost to connect first
18:47:04 INFO GrpcManager - Connecting to Umbra Server on Host 192.168.178.47:17475
18:47:06 INFO Umbra_gService - Unable to connect to Umbra DefaultUnknownServerName @ 127.0.0.1
18:47:06 WARN Umbra_gService - Unable to contact any of the Umbra DefaultUnknownServerName IPs: [192.168.178.47, 127.0.0.1]
Alle drei Komponenten laufen auf dem gleichem Rechner. Mit der 3.3.0 hat das auch alles in dieser Konfiguration funktioniert. Ein manuelles Verbinden, wie es im Troubleshooting vorgeschlagen wird bringt auch nichts.
Hallo zusammen,
nachdem ich die 3.3.1 installiert habe öffnet sich beim Start nicht mehr das Projektadministrationsfester. Ich kann es auch nicht manuel aus der Gui heraus öffnen. Dort sind unter "Datei" alle Menüpunkte ausgegraut.
Daher schaffe ich es im Moment nicht eines meiner Projekte zu laden oder ein neues zu erstellen.
Funktioniert das jetzt anders oder mache ich etwas falsch?
Gruß
Bernd
Hallo,
als kleinen Tipp, wie man die Starter-Cuelists noch einfacher gestalten kann bzw. so in der Form nicht braucht: Wenn ihr die Cuelists, die vom Timecode-Player getriggert werden aber dann unabhängig laufen sollen, auf einen Executor legt, könnt ihr diese Cuelists im Timecode-Player auch mit dem Executor-Tracks triggern. Die großen Vorteile an dieser Variante sind, dass man a) keine weiteren Cuelists braucht und b) das Triggern dieser Cuelists einfach aufzeichnen kann. Man kann also den roten Record-Button drücken und dann einfach die "Go" bzw. "Stop"-Button des entsprechenden Executors drücken. Das geht insgesamt deutlich schneller als das über Starter-Cuelists zu bauen. Außerdem kann man so z.B. auch gewisse Cuelists, die in einem Abschnitt immer wieder getriggerrt werden müssen entsprechend schnell an die entsprechenden Stellen setzen. Dabei kann man das zuerst grob händisch machen und danach noch zurechtrücken.
Und das widerspricht auch so ein bisschen der Aussage von Bernd, dass das im Timecode Player nicht direkt vorgesehen ist. Wir haben das nur aufgeteilt. Alle Cuelists, deren Cues exakt auf gewisse Punkte getriggert werden müssen, werden direkt im Timecode Player hinterlegt. So sieht man alle Cues und ihre exakten Positionen zur Musik. Alle Cuelists, die zwar exakt durch den Timecode-Player getriggert werden sollen, dann aber unabhängig laufen, werden eben über die Executortracks hinterlegt. Hier könnten wir dann nämlich eh keine Cues im Timecode Player sauber darstellen. Deshalb sind bei diesen Cuelists dann weiterhin alle Trigger erlaubt. Bei den exakten Cuelists haben wir eben die Trigger soweit eingeschränkt, um die Logik dahinter einfach zu halten.
Viele Grüße
JP
Das ist natürlich auch eine Möglichkeit 
Je nachdem um wie viele Szenenlistesten es sich handelt, können da schon einige Executoren und damit auch Executorenspuren in der Timecodeshow zusammen kommen. Dafür sind (wie du schon erwähnt hast) die Szenenlisten schön aufgeräumt, weil man die Start- und Stop-Cues nicht braucht.
Es führen halt viele Wege nach Rom.
Ich werde das mal bei Gelegenheit auch bei meinem Projekt ausprobieren. Vielleicht passt das ja sogar besser.
Jetzt muss ich nur noch rausfinden wie man mit einer Cue eine andere starte 😀
Das geht ganz einfach:
Du erstellt eine neue Cuelist und klickst bei "Szene hinzufügen" auf den kleinen Pfleil nach unten (für das Untermenü). Dort wählst du "Spezial" und dann "Szenenliste" aus. Danach öffnet sich ein Fenster in dem du eine deiner Cuelists auswählen kannst und einstellen kannst ob du diese Starten, Stoppen oder Freigeben willst. Danach noch den Trigger für die neue Startszene auf Timecode stellen und schon kannst du diese Cuelist in der Timecodeshow verwenden.
Diesen "Trick" verwende ich für alle Szenenlisten, die mehr als eine Szene beinhalten. Für Szenenlisten die nur eine einzelne Szene beinhalten (z.B. Farbe, Gobo, feste MH-Position, ...) stelle ich den Trigger Timecode ein und konfiguriere in den Cuelisteinstellungen "ersten Szenenauslöser ignorieren". Dann kann ich diese Szenenlisten direkt in der Timecodeshow verwenden. Ich kann sie aber dann auch manuell starten. Ich habe nämlich zusätzlich zu den Timecodeshows in meinen Projekt auch Softdesks mit Cuelistmonitoren (wie in dem Clubshowvideo) um für einen Livebetrieb auch manuell zu arbeiten.
Die Cuelists, die nur andere Cuelists für die Timeocodeshow starten oder stoppen, habe ich nicht in meine Cuelistgroups eingefügt. Dann tauchen sie auch in meinen Cuelistmonitoren nicht auf. So kann ich mit meinen Szenenlisten gleichzeitig beide Welten (Timcodeshow und Livebetrieb mit Cuelistmonitoren) bedienen.
Um entsprechend flexibel zu sein und einige Sachen mehrfach zu verwenden, baue ich mir meine Cue-Lists auch so wie im "Clubshow-Tutorial" beschrieben auf.
Der Übersicht halber lege ich mir (im Prinzip analog zu den Cue-List-Groups) in der Timecodeshow mehrere Cue-List-Spuren an (Dimmer, Bewegung, Gobo usw.). Muss im Prinzip nicht sein, aber durch die Clubshow-Cue-List-Strucktur passiert in der Timecodeshow an bestimmten Zeitpunkten sehr viel gleichzeitig und da hilft mir etwas Ordnung in mehreren Spuren schon sehr.
Cue-Lists mit Beat-Trigger oder Random-Trigger starte ich in der Timecode-Show über separate Start-/Stop-Cues, die diese Cuelists außerhalb der Timecodeshow steuern. Über diesen Umweg kann man sie aus der Timecodeshow heraus starten ohne, dass man den Timecode-Trigger benötigt. An dieser Stelle muss ich der ursprünglichen Idee, dass in der Timecodeshow alles zeitgesteuert läuft und daher nur der Timecodetrigger Sinn macht etwas widersprechen. Ich finde es in einer Timecodeshow auch nice, wenn ich über den Randomtrigger zufällige Flash-Effekte (z.B. Funkeln, Blitzlichgewitter) starten kann. Oder ein Lauflicht, dass ich die ganze Zeit beatgesteuert immer weiter laufen lassen will, ist einfach so schneller umgesetzt als wenn ich das Lauflicht über längere Zeit im Timecode einzeln programmiere.
Legt man dann noch den Beatmaster auf einen Executor, kann man über eine Executorspur und der REC-Funktion sogar den Beat sauber vorgeben - funktioniert Einwandfrei.
Nachdem nun alle vier Aufführungen geschafft sind, denke ich, dass ich euch noch ein Feedback schuldig bin:
Das Aufsplitten auf zwei Teilprojekte hat in meinem Fall leider nicht ausgereicht. Noch weiter aufsplitten konnte/wollte ich nicht mehr. Ich hätte ja jedes weitere Teilprojekt noch einmal genau durchtesten müssen, um sicherzugehen, dass ich nicht Zuviel heraus gelöscht habe. Dafür war schlichtweg keine Zeit mehr.
Ich hatte es hier aber ja schonmal erwähnt, dass ich nach Abschluss des Programmierens Fenster wie Timecodeplayer oder Stageview nicht mehr verwendet habe und beim ausschließlichen Arbeiten mit Executoren und Softdesk beim Fahren der Show sich DMX-Control relativ stabil verhalten hat.
Das Problem hat sich dann nur noch dadurch geäußert, dass nach einiger Zeit eine Cuelist-Group nach der anderen zwei Cuelists gleichzeitig abgespielt hat, obwohl ich das in den Eigenschaften nicht erlaubt hatte.
Das hat sich aber nur so ausgewirkt, dass z.B. nach einer Timecodeshow mal eine MH-Gruppe an geblieben ist oder mal eine Bewegung weiter gelaufen ist. Über meine Cuelist-Monitore konnte ich das sehr schnell händisch abschalten. Das war dann weiter kein Problem. Ab und zu haben sich dadurch sogar ganz nette Bühnenbilder während der Moderation ergeben =)
Ich will damit nur sagen, dass in meinem Fall DMX-Control nicht komplett abgestürzt ist und mir im Fehlerfall eher "signalisiert" hat, dass es Zeit wird neu zu starten. In Kombination mit meinem Backup-Rechner, auf den ich dann wechseln konnte, war das alles händelbar.
Da ich jetzt einfach mal davon ausgehe, dass die 64Bit-Version noch etwas auf sich warten lässt (ihr könnt ja auch nicht hexen), denke ich für das nächste Mal über einen Workaround nach:
Ich habe dabei an eine Artnet-fähige Mediaplayer-Software gedacht, in die ich alle Audiofiles auslagere, die nicht in einer Timecodeshow verwendet werden. Dadurch könnte ich mein Projekt deutlich verschlanken und hätte dennoch den Komfort die Files aus DMXControl heraus zu steuern.
Im Prinzip könnte man sogar ein parallel laufendes DMX-Control V2 als Artnet-MP3-Player missbrauchen. Da werde ich bei Gelegenheit mal etwas experimentieren. Sobald ich einen praktikablen Workaround gefunden habe, würde ich das hier noch ergänzen.
Ich starte jetzt allerdings erstmal meine Vorbereitungen in die kommende Bierzeltsaison, wo ich mit meinem Musikverein unterwegs bin. Sprich Livemusik, keine Audiofiles und ein Setup in der Größenordnung 150 DMX-Kanäle. Das sollte etwas entspannter laufen 
Bleibt mir nur mich hier noch einmal zu bedanken für euere Unterstützung, schnelle Rückmeldung und dass ihr euch die Arbeit gemacht habt, mein Projekt nach Fehler zu durchforsten. Wenn wir auch das Problem kurzfristig nicht vollständig beseitigen konnten, war es für mich äußerst hilfreich überhaupt zu wissen, was passiert und woher die Phänomene kommen. Vielen lieben Dank nochmal dafür.
Ich hoffe auch, dass es hier nicht falsch rüber gekommen ist, nachdem wir sehr viel über Probleme diskutiert haben:
Im allgemeinen finde ich DMX-Control 3.3 als äußerst gelungen. Ich nutze DXM-Control mittlerweile seit über 20 Jahren und es ist für meine Zwecke nach wie vor die beste Wahl und ich bin bei neuen Versionen immer wieder überrascht, Features zu entdecken von denen ich vorher noch gar nicht wüsste, dass ich sie dringend brauche 
Großes Lob und bitte macht weiter so.
Ich hab dein Project mal in der Entwicklungsumgebung geladen,Dffs
Da sind fehler in ein paar DDFs, die es mir nicht erlauben das project zu öffnen
Ich bin mal auf Fehlersuche gegangen und hab etwas gefunden. Mit den DFFs hier im Anhang bringt bei mir der Kernel beim Start des Projektes keine Fehlermeldung mehr.
Zu den DDFs, in der Fehlermeldung in dem Bild steht genau an welcher stelle der fehler ist und was nicht richtig ist.
Zu den Timecode Shows.
Dann Bearbeite die Shows nicht Quer durchs beet, oder alle hinter einander, dann musst du kurz Speichern, die GUI schließen und dann die GUI neu Starten.
Wir können da nichts dran ändern bis wir auf x64 sind.
Genau so habe ich es dann auch gemacht. Wollte damit nur sagen, dass ich das Phänomen beobachten konnte.
Moin, also, das mit den FFT-Analysen der Audiofiles wird mit dem x64 umbau warscheinlich kein problem mehr sein.
Das eigentliche Problem ist aber weniger die Analyse, als das UI-Framework WPF.
Dieses ist nicht in der Lage Bilder/Zexturen die einmal geladen wurden zu entladen.
Heist das der Speicherverbrauch steigt mit jeder weiteren Audiofile das in einer TimecodeShow angezeigt wurde(also ab dem moment wo es sichtbar im Fenster war)
Das wird aber auch mit x64 weit weit nach hinten verschoben
Das deckt sich mit meiner Beobachtung. Oft konnte ich eine TimecodeShow laden und bearbeiten. Wollte ich dann mit der nächsten weiter machen hat sich das Programm gerne beim Laden aufgehangen.
Umgekehrt: Wenn ich jetzt für die Veranstaltung die Timecodeshows nur noch über die Executoren starte, also das Timecodeshow-Fenster in meiner Fensteranordnung gar nicht mehr lade, läuft das ganze (relativ) stabil.
Das meinte ich auch oben damit, dass das Programmieren gar keinen Spaß macht aber das Fahren der Show einigermaßen funktioniert.
Ich hab dein Project mal in der Entwicklungsumgebung geladen,
Da sind fehler in ein paar DDFs, die es mir nicht erlauben das project zu öffnen
Da sind mir auch schon entsprechende Fehlermeldungen im Kernel-Fenster beim Laden des Projektes aufgefallen. Ich konnte aber nicht herausfinden um welche DFFs es sich handelt. Laut deinem Fenster handelt es sich um das DFF "Triumph" und "TAS ProSpot".
Ich schaue mir die DFFs mal an.
Das stimmt schon. So ein bisschen missbrauche ich da DMX-Control auch etwas
Aber das finde ich gerade seit Jahren das Schöne daran, dass ich alles aus einer Hand habe und vor allem dass die Audio-Files auf den Punkt sofort ohne Zeitverzug starten. Weiterhin macht es den Austausch zwischen Main- und Backup- und Programmier-Rechner einfacher, wenn man immer nur ein Projekt synchron halten muss.
Daher war ich ja bei der V_3.3 so extrem begeistert, als ich von den Executoren-Spuren beim Timecode-Player gehört habe. Damit ist es mir möglich z.B. beim Start einer Timecode-Show ein zeitlich vorher laufendes Audiofile automatisch auszufaden zu lassen und zu beenden.
Das ist für mich eine rießen Erleichterung, wenn ich solche Sachen automatisieren kann. Dann kann man sich in dem Moment um andere Sachen (Mikrophonie, Video …) kümmern und muss sich nicht auch noch darauf konzentrieren.
Um den Vorteil aber zu nutzen zu können, müsse diese (z.B. Einzugs-/Introlieder) eben mit ins Projekt. Dann bleibt nicht mehr all zu viel übrig, was man weg lassen könnte.
In diesem speziellen Fall kann ich eh nicht mehr viel machen. Übermorgen ist Generalprobe - Samstag die erste Aufführung. Da ist nicht mehr viel Zeit noch etwas anzupassen bzw. das Risiko zu groß, dass sich Fehler einschleichen.
Daher werde ich (wie von 
JPK vorgeschlagen) das Projekt jetzt einfach mal in 2 Teilprojekte teilen (z.B. vor und nach der Pause) und die entsprechenden Timecodeshows und zugehörige Audiofiles entfernen. So müssten sich in den Teilprojekten die Files in etwa halbieren.
Für die Zukunft muss ich mal schauen, wie ich neue Projekte hinsichtlich Audio-Files gestallte. Ich hatte einfach im Vorfeld nicht erwartet, das 90MByte mp3s ein Problem darstellen könnten.
Übrigens habe ich in den letzten Jahren mit der V_2.12 einige Musical-Nummern gefahren. Dabei habe ich mit mehreren (nacheinander getriggerten) Audioplayer-Tracks Timecode-Shows in der Größenordnung von über einer Stunde gefahren. So etwas werde ich mit diesem Hintergrund vermutlich mit der V_3.3 vergessen können, oder?
Kurze Frage noch: Kann es sein, dass von jedem File beim Laden des Projektes eine FFT und Waveform erstellt wird, auch wenn das File gar nicht in einer Timcodeshow eingebunden ist?
Ich habe mittlerweile im Installationsordner /Kerne/LibDevices alle DLLs und in den Unterordnern die zugehörigen Bilder entfernt, die ich für das Projekt nicht benötige. Ich habe den Eindruck, dass es nun auf allen 3 Rechnern stabiler läuft - aber es gibt immer noch Abstürze. Insbesondere, wenn ich eine Timecode-Show in das Timecode-Editor-Fenster lade oder im Input-Assingment arbeite.
Die gute Nachricht: Während der Proben, bei denen ich nur mit Executoren und Softdesks zum Fahren der Show arbeite ist es bis jetzt stabil gelaufen.
Den aktuellen Stand des Projektes habe ich in meine Dropbox geladen. Unter folgenden Link solltet ihr es downloaden können
Achso. Ich hatte das so verstanden, dass nur die Geräte (incl. Bilder) verwendet werden, die ich in meinem Projekt eingefügt habe und der Rest nur Bibliothek ist.
Aber danke für den Hinweis, das kann ich mal ausprobieren ...
Das ist natürlich etwas, was man 6 Tage vor der ersten Aufführung nicht hören möchte 
Aber gut. Da muss ich jetzt das Beste draus machen. Ich werde mal versuche, wie du schon vorgeschlagen hast, das Projekt in mehrere aufzuteilen.
Es ist ohnehin so aufgebaut, dass jedem Programmpunkt einer Executor-Seite entspricht. Die zugehörigen Timecode-Shows und Audiofiles kann ich dann aus dem jeweiligen Projektteil entfernen.
Die Geräte und alle Szenenlisten muss ich dann natürlich in allen Teilen komplett lassen, weil die Timecodeshows und die Executoren auf diesen Pool zugreifen. Ich hoffe, das ist kein Problem (ca. 350 Szenenlisten).
Aber ich werde es herausfinden und berichten.
Gruß
Bernd
