Halt Bitte die DDFs so nicht hochladen. Hintergrund ist: DMXControl 3 verwaltet hier nicht den Dimmer, sondern die angehängten Scheinwerfer. Also anstatt dass du deine Dimmer-DDFs einfügst, ist es besser, du nimmst hierfür für jeden an den Dimmer angeschlossenen Scheinwerfer einen Generic Dimmer. Diese DDFs sind schon in DMXControl 3 enthalten (und solche 4-Kanal-Dimmer bewusst nicht ) und du kannst dann auch alle angeschlossenen Geräte einzeln steuern (du siehst jeden Scheinwerfer in der Stage View als ein eigenes Element). Bei deiner Variante würden alle Scheinwerfer in einem DDF zusammengefasst werden, wobei du die dann nicht sauber einzeln steuern kannst. Das wäre dann nämlich ein sog. Multi-Beam-Gerät, was DMXControl 3 noch nicht richtig unterstützt. Stattdessen fügst du alle 4 Generic Dimmer ein und lässt automatisch eine Gerätegruppe erstellen. Dann kannst du sowohl die einzelnen Lampen ansteuern, wenn du eine oder mehrere der Scheinwerfer in der Stage View auswählst. Oder du kannst alle gemeinsam über die Gerätegruppe ansteuern. Außerdem kannst du natürlich in beiden Fällen Effekte auf die Dimmer-Eigenschaft legen.
Ich hoffe, das war jetzt soweit verständlich. Falls nicht, dann einfach melden
Viele Grüße
JP
P.S.: Wenn ich das richtig im Kopf habe, geht das Hochladen mit einem Forenaccount in der DDFLibrary erst, wenn der Account verifiziert ist (2 von einem Vereinsmitglied als valide bestätigte Posts).
Das das DMXC3-GUI allerdings nie mehr als ungefähr 1GB RAM verwendet, deutet für mich auf eine Beschränkung in der verwendbaren RAM-Menge hin.
Gibt es eine (einfache) Möglichkeit, diese Beschränkung (falls sie existiert ) soweit zu erhöhen, dass ich auch große TimeCode-Shows öffnen kann?
Genau das ist leider das Problem. Zwischen 1 und 2GB RAM ist leider aktuell die Schallmauer, bis zu der die GUI funktioniert. Das liegt daran, dass DMXControl 3 in weiten Teilen (ausgenommen vom Umbra) eine 32bit-Anwendung ist und einfach nicht mehr Speicher adressieren kann. Das geht rein technisch nicht. Mit 64bit-Anwendungen ist das anders. Solche können deutlich mehr Speicher adressieren, weit über die heute üblichen 32 oder 64GB Arbeitsspeicher. Jetzt fragst du dich sicher, warum DMXControl 3 keine 64bit-Anwendung ist. Wir würden DMXControl 3 sehr gerne auf eine 64bit-Anwendung umstellen, aber leider geht das aktuell nicht. Beim Kernel liegt das an den ganzen DMX-Plugins, die dort laufen. Würden wir den Kernel einfach auf 64bit umstellen, würden alle DMX-Plugins nicht mehr tun, die wir wegen den Abhängigkeiten zu den Programmbibliotheken der Hersteller nur als 32bit compilieren können (und das sind aktuell etwa 95%). Hier müssen wir erst noch einen Zwischenlayer einziehen, der die Adaption von 32bit auf 64bit macht. Das ist geplant, aber noch nicht umgesetzt. In der GUI hindert uns XNA an einer Umstellung auf 64bit. Dies ist eine von Microsoft entwickelte, schon länger eingestellte GameEngine (so etwas ähnliches wie Unity oder Unreal Engine, die man von einigen Spielen her kennt), welche die StageView, das Input Assignment, den Network Monitor und den Programmer treibt. Wir hatten XNA damals verwendet, weil nur das die nötige Performance hatte, diese Fenster sauber anzuzeigen. Alles andere war so laggy oder buggy, dass man diese Fenster nicht benutzen hätte können. Leider wird XNA wie gesagt nicht mehr weiterentwickelt und unterstützt auch kein 64bit. Wir sind dabei, die genannten Fenster in den nächsten Versionen von DMXControl 3 Schritt für Schritt auszutauschen und dabei auf ein anderes Framework zu wechseln (WPF) was schnell ist und 64bit unterstützt (treibt u.a. schon die Executoren, die Project Administration und den Timecode Player). Der Austausch der XNA-Fenster ist bei uns auch recht weit oben auf der Prio-Liste. Allerdings sind diese Fenster auch wahre Klopper was den Umfang angeht und das wird nicht ganz so einfach.
Die kurze Antwort auf deine Frage lautet also: Ja, es gibt eine Möglichkeit, aber diese ist leider weder einfach noch schnell realisierbar und es ist auch leider keine, die du als User hast
Mit dem DDF Creator für die Version 2 war das alles irgendwie einfacher umzusetzen...
Definitiv. Das ist uns auch bewusst. Wir haben nur leider immernoch niemanden gefunden, der sich um den DDFCreator 3 kümmert (sprich in mit moderner GUI neu schreibt) . Alle aktiven Entwickler (inkl. mir selbst) sind halt schon mit DMXControl 3 und dem drum herum voll ausgelastet und können das leider nicht auch noch stemmen. Zumal das Schreiben an DMXControl unser Hobby ist und durchaus auch mal liegen bleibt, wenn gerade andere Dinge wichtiger sind Sollte sich aber jemand finden, der den DDFCreator neu schreibt, dann wäre das super und auch wir würden uns sehr darüber freuen (Interessenten können sich gerne bei uns melden )
Qasi ich hatte da heute schon angefangen, entsprechende Converter Nodes aufzusetzen. Allerdings ist das bei den Convertern gerade noch ein kleines Durcheinander, weil manche Funktionen (z.B. für die Farbe) doppelt existieren. Daher hab ich meine Arbeiten dazu wieder auf Eis gelegt und wir sollten erst kurz reden, welche Converter benötigt werden und welche nicht.
wir befinden uns hier gerade in einem Zwischenzustand. Der Launcher hat schon einige der Startvorgänge übernommen und wird zukünftig noch mehr übernehmen. Er kennt aber Projekte noch nicht (das sieht man an dem ausgegrauten rechten Teil des Launchers). Dieses Feature wird erst in einer der folgenden DMXControl Versionen (evtl. 3.3.1) kommen. Dazu passend fehlt auch noch eine Einstellungsmöglichkeit, was beim Start von DMXControl 3 passiert. Hier ist ebenfalls für eine der nachfolgenden Versionen geplant, dass du einstellen kannst, wie DMXControl 3 genau startet (ohne Projekt, Projekt Administration offen (aktueller Zustand), ein spezifisches Projekt).
Seit dem Einzug der Project Administration musst du also für deinen speziellen Fall alle drei Programme (GUI, Kernel und Umbra) z.B. per Skript starten und dem Kernel dabei die ProjectID übergeben. Es ist also wichtig, nicht den Pfad zur Datei zu übergeben, sondern die ID des Projekts. Diese findest du im ProjectStore von DMXControl 3 (in AppData) im Dateinamen (sollte offensichtlich sein ). Allerdings hier als Hinweis: Das ist kein Feature, was offiziell so unterstützt wird. In einer der nächsten Versionen wird es dann wie gesagt eine passende Einstellung dafür geben. Ab dann wird die hier beschriebene Funktion wieder deaktiviert / nur noch für Entwickler nutzbar sein! Das also hier als Warnung.
Perfekt Genau, entweder so oder du kannst auch im Baum den StageView Bereich aufklappen, damit du die entsprechende StageView siehst. Dann gehst du oben in die Geräte-Kategorie, damit du alle Geräte auf der rechten Seite siehst. Dann kannst du dort alle gewünschten Geräte per Mehrfachselektion auswählen und nach links auf den Baumeintrag für die entsprechende StageView ziehen. Wichtig dabei nur: Ist ein Gerät in der Selektion schon in der StageView vorhanden, wird ein Drag&Drop nicht zugelassen.
Deine Idee von einem Drag&Drop aus dem Projekt Explorer auf die StageView an sich ist eigentlich gut. Aber leider haben wir bisher wenig bis keine Fenster-übergreifenden Drag&Drop-Möglichkeiten. Das wird auch noch etwas brauchen, bis das geht, denn wir sind gerade dabei, alle Fenster nach und nach neu zu machen und dabei auf ein einheitliches Fenster-Framework umzustellen. So haben wir gerade eine Mischung aus mehreren Frameworks und ein Framework-übergreifendes Drag&Drop ist nur mit sehr großem Aufwand möglich, weshalb wir das bisher weggelassen haben.
du musst zuerst einmal das Plugin nun 2 Mal hinzufügen. Nun wird nur noch ein Universum pro Plugin ausgegeben, es können aber beliebig viele Art-Net-Plugins eingefügt werden. Dann müsstest du beim einen eben 2-0-0 eingeben können und beim anderen 2-0-1 für Net, Subnet und Universe. Liefert dein Art-Net-Node kein ArtPoll Reply oder sind in deinem Netzwerk keine Broadcasts erlaubt, kannst du auch noch unten die IP-Adresse deines Nodes eintragen. Dann wird dahin das Art-Net-Signal auch noch geschickt.
da bist du tatsächlich an eine Grenze der 3.2.3 gestoßen. Hier gibt es keine wirklich gute Möglichkeit für ein Farblauflicht (auch weiß ist hier als Farbe zu rechnen) über eine beliebig einszellbare Grundfarbe hinweg laufen zu können. Das liegt daran, dass das Lauflicht zwar im eingeschalteten Zustand Weiß ausgibt, aber auch einen Wert für den "aus"-Zustand ausgibt (das kann entweder eine Farbe sein oder Schwarz). Du kannst also nicht unabhäbgig die Basisfarbe einstellen. Einzige Variante, wie du in der 3.2.3 das umsetzen kannst ist, ein Lauflicht "händisch" zu erstellen sprich jeden einzelnen Schritt in eine Cue speicherst, dabei aber immer nur die "an" Werte speicherst und dann das Tracking in der Cuelist ausschaltest (schaue dazu mal die Infos im Lebenszyklus-Video von den Cues auf unserem Youtube-Kanal). Indem du nur die Werte für den eingeschalteten Zustand speicherst, können für "aus" beliebige andere Szenenlisten die Werte ansteuern. Durch das deaktivierte Tracking steht jede Szene in der Szenenliste für sich. Alle anderen Szenen werden dann deaktiviert (anders als normal, wo jede Szene der Reihe nach aktiviert wird und aktiv bleibt, bis die Szenenliste neu startet oder beendet wird).
Einfacher geht das erst mit DMXControl 3.3.0, denn dort kannst du als Basisfarbe einen ColorMaster definieren. Dessen Farbe kannst du dann live einstellen während das Lauflicht läuft. Ich hoffe, das war jetzt soweit verständlich Falls nicht, einfach noch einmal fragen.
Um nicht lange um den heißen Brei herumzureden: Es gibt keine neuere Version Wir haben leider immernoch niemanden gefunden, der sich um den DDFCreator 3 kümmern möchte und ihn neu aufsetzen möchte. Wir haben nämlich leider schlicht keine Kapazitäten dafür, weil alle bereits in Projekte eingespannt sind. Deshalb liegt der DDFCreator auch so lange brach und wird nicht aktualisiert. Du müsstest also das DDF händisch zusammen bauen. Das ist aber auch möglich. Dazu gibt es eine recht große Sektion mit Erklärungen in unserem Wiki: https://wiki-de.dmxcontrol-pro…sicht_Hauptprogramm_DMXC3
Nicht ganz. Es gibt folgende Szenenhirarchie in DMXControl 3: Ein oder mehrere Szenen können Teil einer Szenenliste sein, wobei immer nur eine Szene innerhalb einer Szenenliste die aktuell ausgeführte sein kann. Alle Szenen, die davor liegen, werden auch aktiviert (außer man ändert eine gewisse Einstellung). Sprich starte ich also Szene 6, so werden Szene 1 bis 5 auch aktiv und bringen die in ihnen gespeicherten Werte in die Ausgabe mit ein. Es kann aber natürlich sein, dass z.B. Szene 3 Farbwerte für Grp 1 ausgibt und Szene 5 für die selbe Gruppe. Dann überschreibt die Szene 5 in der Ausgabe die Werte der Szene 3. Szenen 3 ist dann zwar noch aktiv, gibt aber nichts mehr aus. Sind in Szene 3 Werte für Grp 1 und 2 gespeichert und in Szene 5 nur Werte für Grp 1, dann erhält man im Output eine Mischung von Szene 3 und Szene 5.
Pro Szenenliste kann also nur eine Szene die aktuell ausgeführte sein, aber in DMXControl 3 können beliebig viele Szenenlisten parallel aktiv sein. Du kannst dir also deine Lichtstimmung tatsächlich zusammenbauen, aber mit unterschiedlichen Szenenlisten. Zusätzlich können mehrere Szenenlisten noch in einer Szenenlistengruppe sein. Diese kann das Start- und Stop-Verhalten der enthaltenen Szenenlisten beeinflussen. Man kann also damit bestimmen, ob beispielsweise nur immer eine Szenenliste in dieser Gruppe laufen darf oder wenn man eine Szenenliste aus der Gruppe startet, werden alle anderen auch gestartet.
Mit diesem Vorwissen könnte ein Aufbau bei euch eher wie ein Live-Setup aufgebaut sein, welches in etwa dem Konzept aus unseren Clubshow-Videos entspricht:
Content embedded from external sources will not be displayed without your consent.
Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.
Für jede benötigte Geräteeigenschaft (Dimmer+Shutter, Farbe, Position,...) gibt es pro Gerätegrupe die du steuern möchtest eine Szenenlistengruppe. Diese sind so eingestellt, dass sie nur eine Szenenliste gleichzeitig ausführen lassen. Darin enthalten sind mehrere Szenenlisten, die mit jeweils einer Szene nur genau diese eine Geräteeigenschaft für diese eine Gerätegruppe ansteuern. Dann baust du dir noch ein Softdesk auf (eine virtuelle Pultoberfläche) oder ein anderes Eingabegerät und verbindest die Buttons dort mit dem Starten der Szenenlisten. Dann hast du die volle Flexibilität und kannst dir einfach eine Lichtstimmung zusammenstellen. Aber, und das ist jetzt der Punkt, der leider in DMXControl 3 etwas Fleißarbeit ist: Das Erstellen der Szenenlisten und des Softdesks und auch das Verdrahten musst du leider händisch machen, weil wir noch nicht dazu gekommen sind, eine entsprechende Automatik einzubauen. Das wird also etwas Zeit in Anspruch nehmen, das so aufzubauen.
Da ich weiß, dass das ein recht hohes Ziel ist, macht es vielleicht für den Anfang erst einmal Sinn, dass du dich überhaupt mit DMXControl 3 vertraut machst und einmal die Bedienweisen und Philosophien dahinter verstehen lernst. Wenn dir das zusagt, kannst du solch größere Dinge wie solch ein Livesetup angehen. Ein guter Einstieg wäre vielleicht, wenn du DMXControl 3 einfach mal herunterlädst (ist ja komplett kostenlos nutzbar) und dir in unserem Youtube-Kanal (https://www.youtube.com/@DMXControl) die Tutorial-Videos anschaust bzw. unser Handbuch im Wiki anschaust https://wiki-de.dmxcontrol-pro…sicht_Hauptprogramm_DMXC3 Wenn dir das alles zusagt, kann es dann an das Livesetup gehen.
Für die Ballett-Veranstaltung kannst du das dann entweder auch nutzen oder wie ich das eben mit meinen Theaterveranstaltungen mache nur einen festen Ablauf in einer einzelnen Szenenliste. So habe ich zwar vor der Aufführung die Programmierarbeit. Die eigentliche Aufführung ist dann aber "nur noch" ein Durchklicken der Szenenliste
ja, das ist möglich. Die Frage ist eher wie flexibel muss es sein Also sind die jeweiligen Vereinsfarben so lange im voraus bekannt, dass man diese vorab einfach abspeichern kann? Wenn ja, dann kannst du diese direkt in einer Szenenliste speichern, die Szenenliste starten und schon hast du die entsprechende Farbkombination. Das starten der Szenenlisten kann man dann über das Input Assignment (bzw. in der deutschen Oberfläche die Ekngangszuweisung) so verknüpft werden, dass die Szenenliste gestartet wird. Wenn du einen festen Programmablauf hast, könntest du sogar nur eine einzige Szenenliste verwenden und darin in mehreren Szenen den gesamten Ablauf speichern (so mache ich das bei meinen Theaterveranstaltungen).
Dazu ein ausführliches Wiki , gute Videotutorials und ein super Forum mit Antworten ohne die negativen Bemerkungen, die man aus anderen Foren leid ist.
Danke, das freut uns natürlich, dass DMXC3 gefällt
Der Vollständigkeit halber aber die Info, dass das so eigentlich nicht gedacht war, aber halt aktuell die einzige Möglichkeit ist. Hier soll es in Zukunft (nach 3.3.0) eine bessere Lösung geben.
Wie aber Steff schon gesagt hat, kannst du die entsprechenden Kanäle mit Hilfs-Geräten überlagern. Mit denen kannst du dann die Einzelpixel-Ansteuerung realisieren (mache ich bei meinen LED Bars auch so). Dazu einfach passend zu den einzelnen Pixeln noch passende Generic Geräte zusätzlich (überlagerz) einfügen.
Öhm das ist ein interessanter Fehler. Der ist mir bisher so nicht untergekommen. Aber auch spannend, dass jemand die Executoren in der 3.2.3 nutzt. Da sind die doch sehr eingeschränkt, was ihre Funktionalität angeht. Deshalb haben wir für DMXControl 3.3.0 die Executoren komplett überarbeitet (sprich neu gemacht).
Hintergrund ist, dass wir im Hintergrund an der MIDI-Implementierung ein paar grundlegende Probleme beseitigt haben, was das Verhalten in der Summe verbessert - aber immer noch nicht perfekt macht.
An der Stelle wurde nichts geändert und deshalb ist das Ticket auch nicht geschlossen worden Es wurde an anderen Stellen Verbesserungen gemacht.
das ist tatsächlich ein anderes Problem, was ich immernoch nicht komplett gelöst bekommen habe. Windows 11 ist da etwas störrischer und man muss etwas andere Wege gehen als bisher Es funktioniert prinzipiell (wie an dem erneuten versuch des Versteckens zu sehen ist), aber offenbar rennt der Launcher in dem Fall abundzu mal in einen Timeout und dann hört er auf zu versuchen, das Fenster zu verstecken. Ich kann mal schauen, ob das Erhöhen des Timeouts eine Abhilfe schafft.
Inwieweit Multibeam-Geräte seit DMXC3.3 unterstützt werden und ob sich entsprechend da was bauen lässt weiß ich leider nicht, aber ich bin mir sicher da kann uns jemand was dazu sagen
Multibeam war in der 3.3.0 kein Thema. Das ist leider ein größeres Projekt und erfordert eine grundlegendere Überarbeitung. Daher können wir das nicht auch noch in die 3.3.0 packen
This site uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.More DetailsClose