Tatsache - mit dem alten Plugin funktioniert die Kopplung zu DMXControl2 (wieder) wie gehabt.
Ich werde die Tage das nochmal parallel mit meinen ArtNet-Nodes (in meinem Fall die Single-Nodes von Radig) testen. Wenn die auch mit dem alten AusgabePlugIn funktionieren, ist das mein Workaround.
Vielen Dank für die Unterstützung.
Gruß
Bernd
zum einen bei der Installation unter anderem direkt auswählen kannst, dass die Standard-Gerätebibliothek nicht mit installiert wird und
zum anderen deine eigenen DDFs im Installationsverzeichnis von DMXC3 nichts zu suchen haben? Für deine eigenen DDFs gibt es das Verzeichnis "UserDevices".
Gut zu wissen. Danke für die Info.
Wo genau finde ich das "UserDevices" Verzeichnis?
Was du aber machen kannst: führe den Installer für DMXControl 3.3.3 nochmal aus und wähle bei den zu installierenden DMX-Interfaces das alte Art-Net-Ausgabeplugin an. Mit diesem habe ich sowohl das zweite Programm als auch DMXC2 erreichen können.
Das werde ich mal versuchen. Das vorherige Plugin hatte einen Bug, richtig? Ich benutze seit neuesten nämlich mehrere 1-Kanal Artnet-Nodes. Alle haben ihr eigenes Artnet-Universum. Auf diese Artnet-Universen werden aber zum Teil gleiche DMX-Universen rangiert. Betrifft dieser Anwendungsfall den Bug?
Ah OK. Das ist ein guter Hinweis. Ich habe das tatsächlich bis jetzt immer über das Art-Net-Universum 0 geschickt, weil ich ab 1 meine ArtNet-DMX-Notes konfiguriert habe.
Ich habe das jetzt mal testweise auf ein anderes, freies ArtNet-Universum gelegt. Das Ergebnis ist allerdings immer noch das gleiche.
Hier die (neue) Konfiguration in DMX-Control 3.3.3
Das habe ich in DMX-Control 2.12.2 eingestellt:
Ich habe auch jeweils immer ein Universum nach oben und unten ausprobiert um Fehler durch eine mögliche unterschiedliche Zählweise auszuschließen (0,1,2,... vs. 1,2.3,...).
Aber es ist immer das gleiche Ergebnis (ich bekomme nur Fragezeichen):
Ich vermute, dass bei mir auf dem Rechner die Kommunikation in irgendeiner Weise geblockt wird. Deswegen habe ich mir auch die Portbelegung angesehen (siehe oben). Da bin ich nur nicht so fit. Da benötige ich eure Hilfe ...
LG
Bernd
Danke für die Infos.
Ich habe bereits sowohl die loopback-Adresse 127.0.0.1 als auch die IP des Rechners versucht. Hat alles nichts gebracht. Der Fehler blieb unverändert.
Speicherprobleme habe ich nach wie vor (vielleicht ist jetzt die Ursache eine andere). Ich habe z.B. mein Projekt nach Installation von 3.3.3 erst öffnen können, nachdem ich den Inhalt der Standard-LibDevices gelöscht und nur die DFFs, die ich benutze eingefügt hatte. Das mache ich schon seit der 3.3.0 so. Ansonsten wird das Laden des Projektes mit Speicherüberlauffehlern im Kernel abgebrochen. Danach kann ich einigermaßen arbeiten. Ab und zu wird beim Laden des Projektes das GUI-Fenster geschlossen. Das kann man dann aber einfach im Launcher wieder starten. In Außnahmefällen wird auch mein Projekt beim Laden zerschossen ("Beim Laden sind Fehler aufgetreten"). Danach ist es unbrauchbar. Backups sind beim mir Pflicht ;.)
Wenn es aber dann läuft, dann funktioniert alles stabil.
Hast du sonst noch eine Idee, wie ich die Artnetverbindung zum Laufen bringe?
Nachdem ich seit längerem mit Problemen durch zu viele Audiofiles in meinem Projekt und den damit verbundenen Speicherüberläufen kämpfe (DMXC 3.3.0 RC5: Ständige Abstürze der GUI - Hilfe und Unterstützung [v3] - DMXControl Projects e.V.) hatte ich im letzten Jahr einen eleganten Workaround gefunden, indem ich alle Audio-Files die nicht zwingend in einer Timecodeshow laufen müssen (z.B. weil nur statisches Bühnenbild) nach DMXControl2 auszulagern und dort per Artnet von DMXControl 3 aus zu starten (Status von Timecodeplayer und Soundfiles über Executor Child-ID - Input Assignment - DMXControl Projects e.V.). Beide Programme befinden sich auf dem gleichen Rechner. Das hat damals wunderbar funktioniert. Nachdem ich nun wieder begonnen habe die kommende Faschings-Saison vorzubereiten, bekomme ich das ein Jahr später nicht mehr hin.
Mit DMXWorkspace sehe ich die Daten auf dem entsprechenden ArtNetUniverse. DMXControl3 scheint also zu senden. Im DMX-In Fenster von DMXControl2 bekomme ich nur Fragezeichen - da kommt also nichts an.
Ich habe hier im Forum gesehen, dass da die Einschaltreihenfolge entscheidend sein soll (DMXC 2 und 3 über Artnet verbinden - Hilfe und Unterstützung [v3] - DMXControl Projects e.V.). Hier habe ich schon alle Varianten mehrmals ohne Erfolg probiert.
Ich habe gesehen, dass die Ports wie folgt belegt werden:
DMXControl 2 bindet 0.0.0.0:6454
DMXControl 3 bindet 192.168.178.47:6454 und 127.0.0.1:6454
Ich vermute mal, das hängt damit zusammen.
Kann mir jemand sagen, wie ich die Verbindung wieder hin bekomme? Hat sich da mittlerweile etwas verändert? Ich denke damals hatte ich die 3.3.1 installiert.
LG Bernd
Hallo Markus,
vielen Dank. Das mit den "Draw Bitmap" funktioniert.
Der Button leuchtet dann zwar nicht ganz so schön wie in der "Lumos"-Darstellung, bzw. die Korona erscheint nur, solange ich ihn drücke. Aber das ist für mich OK - Hauptsache die Funktion ist da: Externer Midi-Taster und interner Softdesk-Button verhalten sich jetzt exakt gleich, egal welchen von beiden ich betätige. 
Gruß
Bernd
Der bessere Ansatz wäre, wenn du für die Rückmeldung den Status der Cuelist hernimmst.
Darüber habe ich auch schon nachgedacht. Nicht-Endlos-Cuelisten würden dann korrekt angezeigt, wenn sie von selbst enden. Danke nochmal für den Hinweis.
Allerdings löst das nicht mein eigentliches Problem, dass der Softdesk-Button nicht leuchtet, wenn man über den Softdesk-Butten selbst die Cuelist startet.
Irgendeine Idee?
Hallo zusammen,
ich wollte folgendes Umsetzen:
Sowohl ein Taster eines Midi-Pults startet/stoppt eine Cuelist als auch ein (Lumos-)Button im Softdesk. Ein/Aus wird durch Leuchten der Taster/Buttons dargestellt. (2x gleiche Funktion - intern/extern)
Hierfür verodere ich die Signale beider Taster mit einem FiFo-Node. Im Anschluss Nutze ich das Signal zum Toggeln eines T-FlipFlops. Der Ausgang des Flip-Flops gebe ich wieder auf die beiden Taster (für das Leuchten) zurück.
Den Softdesk-Button habe ich so konfiguriert, dass er selbst nicht toggelt.
Im Prinzip funktioniert das auch. Ich kann von beiden Tastern aus starten und stoppen. Die Signalisierung des externen Midi-Tasters funktioniert perfekt. Der Softdesk-Button leuchtet allerdings nur, wenn ich über den externen Midi-Taster schalte. Wenn ich mit dem Softdesk-Button schalte, leuchtet dieser nur in dem Moment, wenn er gedrückt wird. Der Status wird dann nicht korrekt angezeigt.
Kann ich das irgendwie anders umsetzten, damit das funktioniert? Ich vermute, dass durch den Druck auf den Softdesk-Button meine Rückführung überschrieben wird. Kann man das irgendwie unterbinden?
Gruß
Bernd
Wie gesagt: wenn das Projekt oder die Projekte fehlerhaft wären, dann würdest du am jeweiligen Projekt einen Hinweis sehen und dieser Eintrag wäre auch gelb oder gar rot markiert.
Da du aber den letzten Stand und auch vorherige Versionen ohne Probleme laden konntest, ist die Gelbfärbung ein reiner Anzeigefehler. Die Konsistenz wird beim Laden ja geprüft.
Mich beunruhigt etwas, dass eine aus diesem Projekt exportierte Projekt-Version beim wieder Importieren das gleiche Phänomen zeigt (Projekt gelb, die nun einzelne darin enthaltene Version aber nicht). Das bedeutet doch, dass trotzdem irgendetwas mit den Projektversionen nicht stimmen kann und sich das Problem durch Speichern auch auf die nächste Version überträgt. Oder liege ich das falsch?
Du kannst ggf. das Projekt mit an das Ticket anhängen - dann kann man / ich nochmal unabhängig schauen.
Schon passiert (siehe Ticket FS#5526)
Der Absturz deines Rechners ist das eine. Das bringt DMXC wie andere Programme natürlich auch ein Stück weit aus dem Takt.
Mich „stört“ bei deinem Bild der Punkt, dass keine Version (mehr) als fehlerhaft markiert ist, dafür aber das gesamte Projekt.
Das stört mich eben auch.
Ich bin mir einfach nicht sicher, ob ich an dem Projekt weiter programmieren soll, mit der Gefahr, dass doch irgendetwas zerschossen ist oder ob ich auf ein Backup zurückspringe und mir die Arbeit der letzten 2-3 Tage noch einmal mache.
Ich kann das Phänomen einfach nicht einschätzen ...
Magst du das bitte einmal in den Bugtracker eintragen? Das sollte nämlich so nicht sein.
Das kann ich gerne machen. Ich hoffe, dass sich das mit dem Logfile nachstellen lässt.
Eine Info habe ich noch:
Nach dem Rechnerabsturz waren bei dem Projekt die Meta-Daten weg. Es zeigte sich in der Projekt-Administration als Projekt ohne Namen. Projekt-Name, Autor usw. habe ich dann händisch wieder ergänzt.
Möglicherweise hat es damit etwas zu tun?
Das ist ja das Komische an der Geschichte:
Nur das Projekt ist gelb. Die darunter gespeicherten letzten 10 Versionen aber nicht:
.
Auch, wenn ich eine Version exportiere und anschließend wieder importiere, wird das importierte Projekt gelb ...
Hallo zusammen,
nachdem mein Rechner während des Betriebs mit DMXControl 3.3.1 abgestürzt ist, wird das zugehörige, während dieser Zeit laufende Projekt in der Projektadmistration gelb angezeigt. Des weiteren hat das Icon ein Ausrufezeichen. Ich vermute eine Warnung.
Das Projekt selbst läd und läuft auch ohne Probleme, zumindest soweit ich das auf die Schnelle beurteilen kann. Die Ausgaben des Kernels beim Laden des Projektes kann ich leider nicht deuten.
Weiß jemand etwas damit anzufangen (siehe Anhang)? An was kann das liegen? Kann ich mit dem Projekt weiter arbeiten oder ist es geschickter eine alte Sicherungskopie auf den Stand des aktuellen Projektes wieder zu ertüchtigen?
Gruß
Bernd
Jetzt habe ich nun doch noch einen Workaround gefunden. Den will ich euch natürlich nicht vorenthalten.
Zugegeben, es ist eine Von-hinten-durch-die-Brust-Lösung - sehr umständlich und fehlerträchtig. Aber sie löst bei mir gerade gleich zwei Probleme:
1.) Ich kann damit Audiofiles komfortabel vom Executor aus steuern (inkl. Lautstärke) und den Status der Audiofile im Input-Assingment für mein Midipult weiter verarbeiten
2.) Ich bekomme bei vielen und langen Audiofiles im Projekt (bis jetzt) keine sporatischen Abstürze beim Programmstart von DMXControl mehr
Es funktioniert wie folgt:
Ich habe mir ein DFF "AudioDummy" (siehe Anhang) erstellt. Darin gibt es eigentlich nur einen Dimmerkanal für die Lautstärke und ein rawstep-Kanal für Play/Stop. Für jedes Audiofile füge ich je ein Gerät dieses DFFs in das Projekt ein und rangiere sie auf ein freies DMX-Universum. Dieses DMX-Universum sende ich per Artnet an ein parallel laufendes DMXControl V2. Dort spiele ich DMXgesteuert die Audiofiles ab. Damit sind die Files nicht mehr im DMXControl3-Projekt und es gibt keine Probleme beim Laden mehr.
In DMX-Control3 habe ich für jedes Audiofile eine Cuelist erstellt, die auf den Executor gelegt wird. Die erste Szene dieser Cuelist startet das zugehörige Audiofile, indem es das Dummy-Gerät des zugehörigen Audiofiles bedient. Eine zweite leere Szene wird auf die Dauer des Audiofiles gesetzt, so dass sich die Cuelist automatisch beendet, wenn das File am Ende abgespielt ist. Dadurch wird aber auch der Fortschritt im Executor angezeigt.
Ich hoffe natürlich immer noch auf die Umsetzung des Tickets, damit man die Lautstärke der Timecodeshows per Executorzug steuern kann und auf die Lösung des Problems mit dem Garbage Collector. Denn die Lösung per "leeren" Timcodeshow ist für mich immer noch die eleganteste.
MfG
Bernd
Die sauberste Methode wäre tatsächlich die aus dem Ticket.
Ok, das hatte ich befürchtet.
Ich bin ebenfalls der Meinung, dass es mit der Timecodeshow-Lösung (mit funktionierendem Fader) die eleganteste Lösung ist.
Bis dahin werde ich mit den Makros weiter arbeiten. Damit kann ich ich die Executoren so bedienen, wie ich es vor hatte. Auf die Rückmeldung des Audiofile-Status muss ich halt vorerst verzichten.
Danke für die Infos.
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.
Guter Tipp - Danke.
Hilft das schon?
Hab das mal wie folgt versucht:
Die Szenenliste läuft einmalig durch und gibt sich am Ende selbst frei. Wenn ich diese Szenenliste auf einen Executor lege und nur die "Play"-Taste und "Go"-Taste aktiviere, kann ich mit Play starten und mit Go stoppen. Durch die leere Szene läuft im Display des Executors ein Fortschrittsbalken.
Eine Pausen-Funktion habe ich allerdings nicht hin bekommen. Das ist aber für meine Zwecke nicht so schlimm.
Hier habe ich jetzt aber das gleiche Problem wie bei der Timecodeshow: Ich kann über den Fader des Executors die Lautstärke des Audiofiles nicht einstellen.
Gibt es da noch eine Möglichkeit, die ich nicht sehe?
Deswegen wurde hier bereits das Ticket FS#5410 : Timecodeplayer-Executoren-Fader als Lautstärkeregler der zugehörigen Audiospure(n) aufgemacht.
So, und jetzt rate mal, wer dieses Ticket angelegt hat ... 
Bis jetzt habe ich es vermieden Audiofiles, die ich ohne Licht laufen lasse, in "leere" Timecodeshows zu packen, nachdem ich letztes Jahr das 32-Bit Speicherproblem mit zu vielen Audiofiles hatte (siehe DMXC 3.3.0 RC5: Ständige Abstürze der GUI - Hilfe und Unterstützung [v3] - DMXControl Projects e.V.).
Aber wenn ich das damals richtig verstanden habe, wird beim Programmstart von DMXControl eh von jedem Audiofile eine FFT erzeugt und in den Speicher gepackt, unabhängig davon, ob das File in einer Timecodeshow verwendet wird oder nicht, richtig?
Allerdings ist bei einem Executor, der mit einer Timecodeshow belegt ist der Fader deaktiviert. Bei den Audiofiles ohne Licht nutze ich diesen aber als Lautstärkeregler. (Beispielsweise bei Start einer "echten" Timecodeshow -mit Licht- fade ich über eine Executorspur das vorher laufende Audiofile automatisch aus. Funktioniert echt super).
was hindert dich daran, die Audiofiles in Cuelists zu triggern oder in eigene Timecode Shows zu packen?
Was meinst du mit "Audiofiles in Cuelists triggern"? Da habe ich das Prinzip noch nicht verstanden. Evtl. wäre das eine Lösung für mich, wenn du das kurz erklärst.
Im Moment habe ich mir damit geholfen über Buttons und Fader eines Makros das Audiofile zu triggern. Über eine Ausgabe in das Makro-Bitmap bekomme ich die Information über Laufzeit und Status in den Executor. Das sieht dann wie folgt aus:
Wenn es dafür einen bessere Umsetzung gibt lasse ich mich gerne darauf ein.
Gruß
Bernd
Ah OK. Kommando zurück:
Da habe ich mich wohl selbst ausgetrickst.
Die Child-ID enthält auch die Timecodeshows. Verknüpft mit einem Timecondeshow-Objekt bekomme ich auch nun den Status meiner Timecodeshows zurückgeliefert.
Mit meinen Soundfiles bekomme ich das allerdings nicht hin.
Wie gesagt, ich steuere die Audiofiles über Makros, die ich dann auf die Executoren lege. Über das Makro-Bitmap bekomme ich (z.B. über die Hintergrundfarbe) die Information indirekt auf den Executor. Ich schaffe es allerdings nicht, die Information im Input-Assingment irgendwie wieder aus dem Executor-Objekt auszulesen.
Gibt es da eine Möglichkeit?
Gruß
Bernd
Hallo zusammen,
ich versuche gerade meine Executoren auf ein Midi-Pult zu spiegeln. Dazu nutze die dynamischen Executoren im Input-Assingment um Fader und Taster auf das Pult zu rangieren. Vom Prinzip funktioniert das auch ganz gut. Beim Wechsel der Excutoren-Seiten schaltet das Pult sauber mit um und die Motorfader stellen sich auf das, was an der neuen Seite eingestellt ist. Liegt auf dem entsprechenden Executor eine Cuelist, kann ich über den Child-ID-Knoten, verknüpft mit mit einem Cuelist-Objekt auch den Status dieser Cuelist auslesen und z.B. so lange diese läuft die Farbe eines Buttons ändern oder ihn Blinken lassen.
Soweit alles Tiptop.
Allerdings liegen auf meinen Executoren auch Makros mit denen ich Soundfiles abspiele und Timecodeshows. Hier schaffe ich es nicht den jeweiligen Status (z.B. über ein Timcodeshow-Objekt am Child-ID-Knoten) auszulesen.
Gibt es da einen Trick? Zumindest bei der Timecodeshow sollte das doch nichts anderes sein, oder?
Gruß
Bernd
Na, wenn das so ist - hier die Log-Dateien.
Das mit dem parallel installieren ist eine gute Idee
