Der Vollständigkeit halber (falls hier nochmal jemand drüber stolpert und nach dem aktuellen Stand sucht):
Ticket zum Bug: FS#4890 : Probleme bei öffnen von Projekt mit berechneter Phase
Ticket zu DEVICEANGLE: FS#4891 : Einführung von Kostante DEVICEANGLE und Rechnen im Device Control
Hi,
danke für die Antwort. Klar, kein Problem: ich schau dass ich morgen mal ein Beispielprojekt gebastelt bekomme und leg dann die beiden Tickets im Bugtracker an 
Viele Grüße
devit
Hallo zusammen,
ich habe aktuell folgendes Problem: ich möchte auf eine Gerätegruppe einen Sinus (Dimmer) legen und den gleichmäßig auf alle Geräte verteilen. Bei einer Phase 0 < 360 machen logischerweise der erste und der letzte Strahler das Gleiche, das sieht aber doof aus. Ich kann natürlich ausrechnen welche Phase ich da eintragen muss: 360 / AnzahlAnGeräten * (AnzahlAnGeräten - 1). Um nicht jedes Mal die Programmierung anpassen zu müssen wenn sich die Anzahl an Geräten ändert würde ich diese Berechnung gerne in der Szene mit abspeichern. Da habe ich mir ein etwas "abenteuerliches" Konstrukt überlegt: Ich habe einen ParameterMaster genommen und diesen auf 1 gesetzt. Danach habe ich folgendes als Phase eingetragen: {ParameterMaster 1:*360/COUNT*(COUNT-1)} Das funktioniert auch wie erwartet.
Wenn ich das Projekt nun aber schließe & neu öffne kommt die Fehlermeldung dass die Phase ungültig wäre. Scheint so als ob DMXC mit meinem Konstrukt beim Speichern oder Aufrufen schwer tut.
Gibt es vielleicht eine elegantere Lösung (als mein Bastelkonstrukt) für mein Problem?
Viele Grüße
devit
Vor einer ähnlichen Überlegung stand ich auch mal (ist aber damals dann auch bei einer theoretischen Überlegung geblieben - kann also nicht aus der Praxis sagen ob das alles so einwandfrei funktioniert wie ich das jetzt formuliere):
Ich hatte damals überlegt Software wie z.B. Jinx zu nutzen die die WS2812b ansteuert. In Jinx wollte ich dann vers. Szenen hinterlegen (analog zu den Macros, die du vom Pixel Mapping auf Moving Lights genannt hast) und diese Szenen via ArtNet o.ä. triggern. Bei Jinx hat sich das damals "Remote Control" genannt und hatte 8 Kanäle mit denen man dann die vers. Szenen auswählen / starten / ... konnte.
Würde bei deinem Setup heißen: du bräuchtest im Pult nur 8 Kanäle nutzen, triggerst damit deinen Szenen in Jinx und Jinx steuert dann erst die LEDs an.
Zur Ansteuerung der LEDs würden sich 2 Möglichkeiten anbieten: a) falls du schon einen Controller für die WS2812b hast, dann kannst du via ArtNet / sACN / ... aus Jinx direkt die LEDs ansteuern oder b) du nutzt (zumindest in der Testphase) dein vorhandenes RPi als "ArtNet -> WS2812b Node".
Um das evtl. nochmal klarer zu formulieren: aus dem Pult / der Software via 8 Kanäle Jinx steuern -> Jinx löst entsprechende Szenen aus und gibt die Daten via ArtNet (evtl. in ein separates Netzwerk) aus -> Daten werden via Controller oder RPi empfangen und an die LEDs ausgegeben.
Evtl. eignet sich auch eine andere Software besser als Jinx, aber das waren eben damals meine Überlegungen - hoffe das hilft der weiter oder zumindest einen weiteren Denkanstoß. Falls es nicht ganz verständlich formuliert ist, einfach nochmal nachfragen
Grüße
devit
Ahh verstehe - hatte das immer so gelesen, dass ich das Interface auswähle. Danke für die Erklärung!
EDIT:
Bei mir waren aber beiden netzwerkkarten am gleichen Switch. Wenn ich mich richtig erinnere hat Maikel2 gemeint, dass die eine Netzwerkkarte per Kabel direkt an das Nodle geht. In so einem Fall kann es durchaus ein Problem sein, weil der PC evtl. die Daten über die falsche Netzwerkkarte raus sendet, und dann landen diese im Nirvana. Bei 2 NW Karten im gleichen Netz ist das Routing auch so, dass es egal ist über welche Karte es raus geht.
Nur zum Verständis: es gibt doch die Einstellung um festzulegen über welches Interface die Daten raus sollen. Wenn hier die richtige ausgewählt ist, sollten die Daten doch auch über dieses Interface raus gehen?
Somit sehe ich alle benötigten Funktionen erfüllt oder habe ich etwas übersehen?
Ich glaube du hast mich falsch verstanden: mir ist bewusst dass ich den Highlight-Modus z.B. über den Auswahl-Rahmen oder durch Verwendung der Strg-Taste auch auf mehrere Scheinwerfer anwenden kann und dass diese, wenn ich wieder wegklicke, auch wieder ausgehen. Das funktioniert bei mir am PC auch alles so wie gedacht.
Mein Problem war hier, wenn ich die Funktion auf dem Tablet (also mit Touch) nutzen will. Da ist es eher unbequem ein Rechteck zu ziehen und auch die Strg-Taste ist da nicht verfügbar. Durch Vorschlag von 
nutzer99 habe ich es jetzt aber folgendermaßen hinbekommen: ich lese aus welcher Scheinwerfer aktuell selektiert ist (den kann ich ja auch via Touch einfach anklicken) und habe dann zwei Buttons "an" und "aus" die dann diesen Strahler entsprechen ein-/ausschalten. Alternativ geht das auch mit einem Fader. So kann ich z.B. Scheinwerfer #1 anklicken und ihn einschalten. Wenn ich jetzt Scheinwerfer #2 hinzuschalten will, klicke ich einfach diesen an und drücke den Button "an". Wenn nun Scheinwerfer #1 wieder aus sein soll, klicke diesen wieder an und klicke auf "aus".
Ich hoffe das war soweit verständlich geschrieben 
2. Beispiel: du baust dir eine Selektion mit verschiedensten Buttons und einem Fader. Sobald du einen Button drückst wird im Hintergrund das Gerät selektiert und du kannst mit dem Fader die Helligkeit des selektierten Gerätes oder der selektierten Gruppe einstellen.
Viielen Dank für die Antwort. Ich wollte vermeiden mir Buttons für Strahler anlegen zu müssen o.ä., da ich die Funktionalität eigentlich primär beim Einleuchten verwende und mit der Aufwand dafür etwas hoch erschien pro Strahler Buttons anzulegen die nur ein paar Mal genutzt werden. Aber dein Verweis mit dem selektierten Gerät hat mich auf den richtigen Weg gebracht: ich frage einfach ab welches Gerät aktuell in der Stage View selektiert ist und setze dann mit einem Fader den Wert für das entsprechende Gerät. 
Und nach einigem Basteln hab ichs jetzt auch hinbekommen zwei Buttons mit "an" und "aus" anzulegen, über die ich direkt den selektierten Strahler direk (de-)aktiveren kann.
Bzgl. OSC-Plugin: danke für den Hinweis, das hatte ich mir bisher noch nicht genauer angeschaut, wäre aber wohl ein Versuch wert!
Danke!
Hallo zusammen,
ich habe folgendes "Problem" und wollte fragen wie ihr das bisher gelöst habt bzw. ob es da ein "richtiges" Vorgehen gibt:
Meine Shows im Theater u.ä. steuer ich im Regelfall über einen PC mit einem oder mehreren Monitoren. Jetzt gibt es aber z.B. beim Aufbau und dem Ausrichten der Scheinwerfer häufiger den Fall, dass ich nicht jedes Mal zurück zum PC rennen will wenn ich einen Strahler an oder aus machen will. Deshalb richte ich mir ein WLAN ein und greife darüber mit dem Tablet auf die Anzeige des PCs zu. Das klappt soweit sehr zuverlässig und wenn ich Softdesks nutze, kann ich die so skalieren, dass sie auf dem Tablet bequem nutzbar sind.
Vorallem beim Einrichten der Scheinwerfer bin ich aber oft in der Stage View unterwegs und habe da bisher keinen vernünftigen Weg gefunden Scheinwerfer ein und auszuschalten: Wenn ich "Highlight" aktiviere kann ich zwar immer einen Strahler antippen, den ich gerade haben will, aber das stößt an seine Grenzen wenn ich mehrere Strahler auswählen will. Andererseits kann ich per Doppelklick einen Strahler aktivieren, bekomme ihn dann aber mit keiner Geste wieder aus.
Wovon ich so ein bisschen träume ist z.B. ein "Einleucht-Modus" den man aktivieren kann. Wenn man dann in der Stage View einen Strahler anklickt geht dieser entsprechend an und wenn man ihn wieder anklickt geht er wieder aus. Damit könnte man sich immer die Strahler zusammenklicken die man aktuell braucht und kann sie auch einfach wieder ausschalten.
Oder gibt es da ein anderes Vorgehen, dass ich bisher übersehen habe?
Liebe Grüße
devit
Die Software würde einen kleinen FIFO von 20 ms Länge mit den DMX Ausgabewerten aufbauen. Ganz am Anfang vom FIFO werden die Werte für das Art-Net Interface abgegriffen und sofort herausgeschickt. Am Ende vom FIFO werden die Werte für das USB Interface abgegriffen (also 20 ms verzögert) und dann an das Interface abgeschickt. Letztendlich hast du dann auf allen Interfaces 20 ms Latenz und die Ausgabe der DMX-Werte auf allen deinen Geräten ist wieder synchron - denn hierauf kommt es an, das nicht die Geräte am USB Interface früher reagieren, als die Geräte am Art-Net Interface.
Ahh, ich verstehe. Das langsamste Interface würde dann die Verzögerung des gesamten Systems vorgeben, womit alles dann wieder synchron wäre - wenn auch verzögert. Danke für die Erklärung!
Entschuldige, da hast du natürlich recht - das Problem hat nichts mit der Datenrate zu tun - mein Fehler.
Bzgl. Latenz: aber auch eine konstante Latenz ist ja ein Problem weil ich die nicht immer kompensieren kann. Klar, wenn ich z.B. vorprogrammierte Abläufe (Cuelists die in Dauerschleife laufen und immer mit einem festen Interval weiterschalten) habe, dann kann ich da einen Offset von X ms draufrechnen um die Werte früher via ArtNet rauszuschicken. Aber bei manuell getriggerten Events geht das ja nichtmehr: wenn ich "jetzt" die Cuelist "alles weiß" starte, weiß DMXC das ja nicht im Vorfeld und dementsprechend wären doch diese Änderungen wieder verzögert?
Bzgl. UDP: ja, das ist natürlich eine Eigenheit bzw. die Eigenschaft von UDP selbst. Bei der Verwendung von Ethernet besteht halt der Vorteil, dass es kaum zu Paketverlusten kommt und damit UDP Pakete zuverlässig genug ankommen. Das ist, wie du schon sagst, bei WLAN nichtmehr gegeben. Prinzipiell wäre es zwar denkbar via TCP die Daten zu versenden, da dürfte aber der Overhead von TCP den Vorteil der Zuverlässigkeit wieder zunichte machen. Und wir wären wieder bei Punkt-zu-Punkt-Verbindungen wohingegen UDP uns die Möglichkeit von Broadcast oder Multicast gibt.
Also zu deinem konkret verlinkten WLAN-Interface kann ich leider nichts sagen. Aber ich habe vor ca. 2 Jahren bei einer Faschingsveranstaltung ein vergleichbares Produkt verwendet um ca. 10 LED Pars zu steuern (also keine Bewegungen o.ä.) weil baulich bedingt keine DMX-Leitung von meinem ArtNet-Interface zu den Strahlern gelegt werden konnte. Ich hab dabei die Erfahrung gemacht: wenn es nicht anders geht und schnell gehen muss kann man mal auf WLAN setzen, aber ich würde es nicht als Dauerlösung empfehlen. Wenn ich z.B. Effekte hatte bei denen die Strahler nur kurz aufblitzen sollten, blitzten die per WLAN angebundenen häufig mit Verzögerung und teilweise sogar gar nicht. Da ist natürlich immer die Frage inwieweit das Publikum das mitbekommt (vor allem bei der Faschingsveranstaltung hat das sicherlich keinen gestört), aber zumindest mir ist es aufgefallen
Das Problem bei WLAN ist einerseits die Latenz und andererseits die begrenzte Datenrate. Vorallem bei häufigen und / oder schnellen Werteänderungen kommt WLAN da an seine Grenzen (wie wohl die meisten Funklösungen).
Einen AP explizit für ArtNet zu verwenden kann dir evtl. ein bisschen helfen, aber ich würde mir da keinen allzugroßen Vorteil erhoffen.
Bei der Nutzung von MHs kannst dann in ähnliche Probleme geraten wie bei meinen Blitzeffekten: die Bewegungen benötigen hohe Senderaten der DMX-Werte um flüssig auszusehen.
Ein ganz anderer Faktor wäre noch die Störanfälligkeit: Funklösungen im 2,4 GHz Bereich (wie eben WLAN) können gerne von anderen WLANs, Handys, mobilen Hotspots, manchen Funkmikros, ... gestört werden. Da ist es einfach peinlich wenn das ganze Licht ins Stocken gerät weil jemand eine Datei runterlädt oder die Funkmikros den Großteil vom 2,4 GHz Bereich beanspruchen.
Du ersparst dir sicher einiges an Kopfzerbrechen, Fehlersuchen, Ausfällen, ... wenn du auf eine kabelgebundene Lösung setzt. Ich selbst nutze WLAN bzw. allgemein Funklösungen inzwischen nurnoch ein für z.B. bequemeren Fernzugriff oder beim Einrichten auf der Leiter - aber immer mit einem kabelgebundenen System im Hintergrund.
Ist jetzt ein bisschen längerer Text geworden, aber hilft dir hoffentlich etwas weiter.
Grüße
devit
Evtl. auch mal die Antivirensoftware temporär deaktivieren, die blockieren auch manchmal unbekannte Verbindungen.
Grüße
devit
Wenn ich mich richtig erinnere sollte das eigentlich im Skript schon passieren, aber versuche mal folgendes:
sudo chmod +x ./rpi-beamertool
sudo ./rpi-beamertoolGrüße
devit
Hallo Wulf,
manche Antivirenprogramme blockieren auch den Schreibzugriff - um u.a. die Verschlüsselung durch Ransomware zu verhindern. Evtl. musst du da DMXControl auf die entsprechende Whitelist setzen.
Grüße
devit
Ah perfekt, das macht es in der Szenenliste natürlich übersichtlicher 
Oh, das ist ja clever! Den Doppelklick kannte ich bereits, aber dass sich das nicht nur auf den Mausklick beschränkt war mir neu
Dann viiielen Dank auf jeden Fall an alle hier! Hat mir wirklich sehr weiter geholfen und ich habe mal wieder einiges gelernt was die Software noch alles kann
LightningBrothers ich hab jetzt nochmal das Projekt von damals aufgemacht und mir ein paar Gedanken gemacht: stimmt, eigentlich hätte ich es über mehrere Cuelists in ner Cuelist Group lösen können.
Eine Frage hätte ich aber dabei noch: wie wäre das korrekte Vorgehen um die Cuelist Group mal mit Fadeout und mal "hart" zu beenden? Zwei Cuelists erstellen: eine die via Fade alle Werte auf 0 zieht und dann von selbst terminiert. Und eine zweite, die direkt (ohne Fade) wieder terminiert? Oder gibt es da ein besseres / anderes Verfahren?
Ansonsten ist der einzige Weg, der irgendwann mal umgesetzt werden würde ein entsprechender "TimingMaster"
Stimmt, prinzipiell wäre natürlich die Verwendung eines solchen TimerMasters (sobald er dann verfügbar ist) möglich. Aber so wie ich das Konzept der Master immer verstanden hatte ist das eigentlich ein Mittel um Live Werte anpassen zu können und sind nicht unbedingt für die statische Speicherung von Werten gedacht - richtig?
Aber kommt das wirklich soooo häufig bei dir vor
Das ist natürlich eine gerechtfertigte Frage, die ich mit einem klaren „Jain“ beantworten muss
Unser Theaterstück letztes Jahr war insofern besonders, als dass es in einem Wohnhaus mit mehreren Stockwerken gespielt hat. Zur Unterscheidung dieser Stockwerte hat jedes eine Farbe bekommen in der dann die Wände entsprechend angeleuchtet wurden. Da im Stück relativ häufig zwischen den Stockwerken gewechselt wurde, gab es natürlich oft Szenen wie „jetzt brauche ich eine rote Wohnung“ und „jetzt brauche ich eine grüne Wochnung“ usw. sodass sich da viele Einstellungen (auch in Sachen Timing) wiederholt haben.
Werde ich das mal wieder brauchen können? Keine Ahnung - wer weiß was in Zukunft für Inszenierungen kommen Es wäre rückblickend einfach ein Feature gewesen, dass mir einiges an Arbeit gespart hätte (wir hatten am Ende irgendwas um die 400 Lichtszenen, wobei das natürlich nicht alles auf solche Stockwerkswechsel zurückzuführen ist).
Ich muss aber auch direkt eingestehen, dass die Verwendung von rekursiven Presets (auch wenn das Timing dann pro Cue im Timing Editor geändert werden muss) auch schon einige Zeit gespart hätte - ich bin einfach nicht auf die Idee gekommen, dass Presets auch rekursiv funktionieren könnten 
Bezogen auf dein Beispiel bietet die Cuelist ja mit ihren Triggern sowie Fade und Delay-Zeiten das Ganze sogar in nur zwei "Zeilen" umzusetzen
Ja genau, das war im Prinzip auch die Vorgehensweise die ich gewählt hatte. Da es bei uns aber immer ein paar mehr Presets pro Lichtbild gab, waren das halt häufig nicht nur 2 Zeilen (wie im Beispiel) sondern schnell mal 4-6 pro Lichtwechsel. Das kommt einem dann aber irgendwann zu den Ohren wieder raus, wenn man das dann ein paar Mal braucht 
du kannst natürlich auch hergehen und du lagerst die Szenenfolgen, welche mehrfach in der gleichen Konstellation aufgerufen werden, in eine eigene Cuelist aus.
Stimmt, hatte ich zwischendurch auch überlegt. Es gab jedoch auch Fälle wo es nicht nur „Wohnung an“ und „Wohnung aus“ gab, sondern wo dann aus „Wohnung an“ in irgendeine komplett andere Szene umgeblendet wurde - das war mir mit “externen“ Cuelists dann doch etwas heikel, dass da alle Überblendungen immer richtig sind.
Vlt. um alles nochmal etwas zusammen zu fassen:
Wie oft das oben genannte Szenario wirklich in der Praxis auftritt kann ich schlecht beurteilen - bei mir gab es jetzt eben in dieser einen Produktion den Fall. Gleichzeitig stelle ich aber auch fest, dass durch die Verwendung von rekursiven Presets und dem Anwenden des Timing Editors in der entsprechenden Cue auch schon Zeit hätte gespart werden können und man hätte dann „nur noch“ die Timings in den einzelnen Cues bei Bedarf anpassen müssen.
Timings gehören nicht in presets
Der Vorteil von dem Ansatz ist, dass ich das gleiche Preset mit unterschiedlichen Fade / Delay Werten verwenden kann.
ja genau, das kann ich auch komplett nachvollziehen: Presets sollen statische Werte global speichern und Timings sind dann lokal Aufgabe der einzelnen Szenen. Mein Problem liegt darin, dass ich die Möglichkeit suche dieses Timing aus der Szene auszugliedern und irgendwie anders zu speichern.
So wie ich das jetzt lese scheint es aktuell schonmal keinen Ansatz in der Richtung zu geben. Ich denke daher wäre evtl eher erstmal die generelle Diskussion: wäre das ein sinnvoles Feature / Ergänzung? Oder kommen so Anwendungsfälle, wie bei mir, zu selten vor?
Der nächste Schritt wäre dann wohl im Zweifel zu klären wie das umsetzbar wäre. Da sowohl Presets als auch Cues ja eigentlich schon klar definierte Aufgaben haben, bräuchte man evtl. ein weiteres Konstrukt um diese Timings zu speichern?
Während ich das so schreibe kommt mir noch ne Idee: oder wäre hier die Integration kleiner „Skriptnodes“ denkbar? Also quasi Codeblöcke, die man wie Presets in eine Cue einbauen kann. In dem Codeblock könnte dann sowas stehen wie:
loadPreset(„LEDs rot“, 0 s)
delay(200 ms)
loadPreset(„LEDs an“, 2 s)Mir ist klar, dass ich jetzt hier einfach so ein „implementieren wir doch nebenbei noch ne Skriptsprache“ vorschlagen kann und das dann erstmal in jede Menge Arbeit ausarten würde. Bin selbst in der Informatik und weiß dass sich so Dinge immer erstmal ganz toll anhören - bis man sie dann implementieren muss.
Daher: seht das einfach als Vorschlag / Idee an - vlt gibts aber auch gar keinen großen Bedarf an meinem Szenario oder ich habe bisher eine komplett offensichtliche Möglichkeit übersehen...