Posts by LightningBrothers

Das habe ich von meiner Seite bis jetzt nicht probiert.

Ja... das ist richtig. Wer auf Art-Net angewiesen ist, sollte den RC4 lieber für den Moment erstmal meiden.

Yes... that's pretty shit indeed. But luckily, the Art-Net problem should be fixed much easier then that one with the Enttec interface because it's easier to test. For fixing the problem with the Enttec interface, we had to put one our one at first to a parcel and send them in this case to Arne, that he can take a detailed look on the issue. For fixing the Art-Net problem, it should be doable without any hardware and if not, almost everyone in our development team has at least one Art-Net node at home or could use a software node for testing. So stay tuned.

Super… vielen Dank für die Rückmeldung.

Magst du das vielleicht noch einmal grob im Ticket FS#5399 : Kernel startet nicht korrekt durch und is somit nicht für Connect freigeschaltet kommentieren, dass nach dem Löschen der Interface-Konfiguration der Kernel wieder normal startete?

Okay... dann schauen wir mal, dass es wieder läuft. Entferne hierzu mal aus dem Config-Verzeichnis des Kernels (das liegt unmittelbar neben dem Verzeichnis der UserDevices) die Datei DMXInterfaceMgmtConfig.xml, wenn der Kernel geschlossen ist. Mit entfernen meine ich an dieser Stelle zum einen das tatsächliche Löschen. Die Datei kannst du alternativ aber auch in ein anderes Verzeichnis auf deinem PC verschieben. Sie muss halt nur aus diesem Verzeichnis "verschwinden". In dieser Datei ist die Konfiguration der DMX-Interfaces hinterlegt zum Zeitpunkt, wenn du den Kernel herunterfährst. Dies bedingt aber, dass der Kernel beim Herunterfahren nicht noch irgendwie auf den letzten Metern hängen bleibt.

Wenn sich nun meine Beobachtungen bestätigen, dann sollte DMXC nach dem Entfernen der Datei aus dem Verzeichnis wieder normal starten - vorausgesetzt eben, du hast nach dem Aktivieren der Art-Net-Ausgabe nicht mehr viel mehr gemacht und konntest auf deinem Laptop vor allem den Kernel ganz normal herunterfahren.

Daher zusammenfassend meine spezifischen Fragen an dich Steff wo ich über eine gezielte Rückmeldung zu jeder einzelnen Frage dankbar wäre:

1. Bevor du meinen heutigen Beitrag zu diesem Thema gelesen hattest, lief der RC4 "trocken" auf deinem Laptop soweit? Mit "trocken" meine ich, dass du nur mal das Programm gestartet und eines deiner Projekte geöffnet hast.
2. Hattest du auf deinem Laptop unter dem RC3 die Art-Net-Ausgabe aktiv oder war sie nur einfach einrichtet und inaktiv? Ich hatte zum Beispiel auf meinem Desktop-PC die Art-Net-Ausgabe zwar vollständig konfiguriert, aber die Ausgabe war deaktiviert, weil ich von meinem Laptop zuletzt Daten an mein Art-Net-Node schicken wollte, während DMXC parallel auf meinem Desktop-PC lief.
3. Konntest du nun beim RC4 die Art-Net-Ausgabe aktivieren und dann den Kernel herunterfahren?
4. Trat in Folge dessen, nachdem der Kernel erfolgreich heruntergefahren wurde, das gleiche Problem auf wie bei deinem Licht-PC?
5. Was hat der Kernel gemacht, nachdem du ihn nach dem Entfernen der Datei DMXInterfaceMgmtConfig.xml erneut gestartet hast?
6. Was passiert, wenn du den Punkt 5 ebenfalls auf deinem Licht-PC vollziehst, wo der RC4 nun zuletzt ja nicht lief?

Mal so in die Runde gefragt: war auf allen Rechnern, wo das Problem nun auftrat, zuvor die Art-Net-Ausgabe konfiguriert und auch aktiv?

Mir hatte nämlich die Aussage nämlich keine Ruhe gelassen, dass das Problem auf einem eigentlich betroffenen Rechner nicht mehr auftritt, sobald man sich mit einem anderen Windows-Nutzer angemeldet hat und wo dann DMXC 3.3.0 auch noch nicht ausgeführt wurde. Und nach ein bisschen Probieren und verbunden durch die Meldung im Thread DMXC 3.3.0 RC4: Art-Net seems to stuck konnte ich das hier beschriebene Verhalten auf meinem PC nun gezielt reproduzieren.

But I also can confirm the behaviour you recognise first, that Art-Net will not work. Every time I try to add a Art-Net interface, the Kernel shows the same message and the stage view does not response anymore in that way, that for example the changes color on a device group will not be shown at the devices itself. It does not happen by using a USB interface like a Nodle R4S.

Edit: I have created a ticket in our bugtracker FS#5400 : Aktivieren der Art-Net-Ausgabe für zu Deadlock

This point is related to the following Ticket FS#5399 : Kernel startet nicht korrekt durch und is somit nicht für Connect freigeschaltet. That could also be the reason, why you can't activate your Art-Net.

Dann schließe ich daraus, dass du das dein Benutzerverzeichnis (Arbeitsverzeichnis) nicht explizit zwischen DMXControl 3.2.3 und DMXControl 3.3.0 mit Hilfe einer Umgebungsvariable getrennt hast und damit alle Konfigurationsdaten für beide Versionen gemeinsam im Standard-Verzeichnis unter C:\Users\{BENUTZERNAME}\AppData\Roaming\DMXControl Projects e.V\DMXControl\ liegen?

Da bin ich bei Steff . Das darf nicht des Rätsels Lösung sein, dass DMXC 3.3.0 im RC4 nun unter einem eigenen Windows-Benutzer gestartet werden muss.

Aber trotzdem würde mich interessieren, ob auf dem Rechner, auf dem DMXC 3.3.0 nun über diesem Wege läuft, ggf. auch DMXC 3.2.3 mit installiert ist und unter dem „alten“ Windows-Benutzer ausgeführt wurde? Wenn ja, gehe ich mal davon aus, dass unter dem neuen bzw. anderen DMXC 3.2.3 noch nie lief?

Da müssen wir definitiv tiefer graben, weil es wie ihr ja selbst nachvollziehen könnt, irgendwie im Zusammenhang mit der Hardware steht. Aber welche Gemeinsamkeiten die Systeme haben, auf denen es läuft und die, auf denen es nicht läuft, müssen noch gefunden werden. Das ist leider einer von den Fehlern, die sich (möglicherweise) schwerer finden lassen.

Was ggf. gut wäre, wenn ihr von allen Systemen einmal ein Logfile vom Kernel mit a den jeweiligen Beitrag hängt, wo ihr die technischen Daten genannt habt - egal ob es auf diesem System funktioniert oder nicht.

Steff Wenn du dir die Verknüpfung erstellst, wie von mir auf Basis der Infos von Patrick beschrieben, was passiert dann auf deinem Licht-PC?

Wie Qasi sagt: legt euch einmal eine eigene direkte Verknüpfung zum Kernel an, die dann wie folgt aussieht:

"C:\Program Files (x86)\DMXControl Projects\DMXControl 3.3.0\Kernel\Lumos.exe" --correlation=skip (In diesem Fall ist DMXControl 3.3 im Verzeichnis C:\Program Files (x86)\DMXControl Projects\DMXControl 3.3.0\ installiert.)

Damit sollte die Gobo-Korrelation ausgelassen werden und der Kernel wäre nach dem Hochfahren direkt bereit zum Verbinden. Wenn das klappt, ändert ihr die Verknüpfung ab und nutzt die beiden anderen Start-Parameter. Bedeutet in allen Fällen, dass ihr den Kernel über diese neue, eigene Verknüpfung startet und nur für den Umbra und die GUI den Launcher nutzt.

Hallo!

DMXControl 3 denkt grundsätzlich in Funktionen und den dazugehörigen Werten wie "Helligkeit auf 45%", "Farbe bitte in ein orange" oder "Wähle das 3. Gobo des 2. Goborads". Auf Basis dieser "Angaben" werden auf die Daten in den Szenen gespeichert. DMX-Werte kommen hier gar nicht vor. Die Umrechnung von diesen Funktionswerten in DMX-Werte erfolgt bei DMXControl 3 erst kurz bevor die Daten die DMX-Interfaces übergeben werden.

Dem entsprechend ist dein Vorhaben so nicht möglich, einfach DMX-Werte einzulesen. Du kannst zwar dein Pult als Fader-Einheit zum Steuern von DMXControl 3 nehmen, aber in DMXControl 3 läuft alles wieder auf die eingangs getätigten Aussagen zusammen.

Am Ende sollte es daher tatsächlich einfacher sein, eine Auswahl von Szenen manuell zu übernehmen und andere Effekte, die du aktuell in deinem Pult hinterlegt hast, mit den neuen und deutlich umfangreicheren Möglichkeiten in DMXControl 3 neu zu bauen. Kurz gesprochen passe deine Arbeitsweise lieber an DMXControl 3 an (und profitiere davon) als DMXControl 3 an deine aktuelle Arbeitsweise.

Dies mal so als kurzen Abriss für den Moment. Bei weiteren Fragen melde dich gerne.

Stefan

Kannst du mal die technischen Details aller Rechner benennen, also CPU, Grafikkarte sowie Betriebssystem und dabei sagen, welcher davon ohne Probleme funktioniert?

Okay… ich mir die Logs nun mal angesehen. Offenbar verrennt sich der Kernel bei dir (auch) in der Aktualisierung der Daten für Gobokorrellation und hat infolgedessen keine Lust sich zu verbinden. Wie sich das umgehen lässt, kann ich gerade nicht sagen.

Hallo…

diese Meldung habe ich auch. Das ist weniger der Grund, da es sich hier um zusätzliche Daten für verschiedene Plugins handelt, die mehrfach geladen wurden.

Da ich gerade nicht in die Logs schauen kann: wird der Kernel denn im Network Explorer anzeigt? Wenn ja, kannst du ihn dort analog zum Input Assignment mit dem Umbra verbinden? Hat sich dabei ggf. sogar die Network-ID des Kernels geändert?

Stefan

Ja… danke für die Rückmeldung. In der Tat müssen deine selbst erstellen DDFs in dem UserDevice-Verzeichnis des entsprechenden Accounts liegen, unter dem du DMXC ausführst - zumindest wenn du das Gerät erstmalig deinem Projekt hinzufügen möchtest. Sobald es einmal im Projekt liegt, brauchst du dir da aber keine Gedanken mehr drum machen.

Deine eigenen DDFs werden wie die mitgelieferten DDFs entsprechend Hersteller, Gerätebezeichnung und ggf. DMX-Modus einsortieren auf Basis der Angaben, die du im Abschnitt informations hinterlegst. Der Dateiname ist da erstmal zweitrangig.

Damit du es über die DDFLib abrufen kannst, musst du es entsprechend auf der Website hochladen. Aber der Schritt erfolgt immer erst, wenn du selbst das DDF erfolgreich getestet hast.

Bezüglich der Verzeichnisse, schaue am besten auch nochmal in die Doku bei uns im Wiki. Da haben wir das Ganze entsprechend aufgedröselt.

Wenn ich von dem beigefügten Projekt ausgehe, dann zerschießt du dir dein Projekt nicht grundsätzlich, wenn du innerhalb des DDFs verschiedene Korrekturen vornimmst. Es ist eher davon abhängig, was du machst.

Wenn du den Dateinamen änderst, ist es auf dem ersten Blick etwas anderes - aber auch das lässt sich mit entsprechender Erfahrung und Kenntnis des Projekts grundsätzlich erstmal händeln.