Ich wollte nun die vorhandenen Halos verwenden, und nicht neue LEDs kaufen
Wenn du jetzt halt eh etwas kaufen musst, kannst du dir halt dabei auch gleich etwas mehr Flexibilität erkaufen 
Ich kann meinen Vorrednern nur zu 100% zustimmen.
Viele Grüße
JP
Hallo,
folgendes geht:
Auch folgendes geht:
Aber du kannst da keinen ParameterMaster in einen anderen Master rein packen. Das ist nicht vorgesehen und kann DMXControl 3 nicht. Wenn man genau ist, sollte eigentlich auch die zweite Option nicht funktionieren, denn hierbei handelt es sich um eine Zeitdauer und da ist eigentlich der SpeedMaster dafür vorgesehen. Aber das ist glaube ich aus Convenience drin.
Viele Grüße
JP
Guten Morgen,
ich müsste mir das nochmal im Detail anschauen, warum das jetzt bei dir nicht tut (geht gerade am Handy schlecht). Aber du kannst das anders viel besser lösen, denn das "Stop All" stoppt halt wirklich alles. Und das will man häufig nicht. Stattdessen will man eher, dass ein Teil der Cuelists stoppt, ein anderer Teil weiterläuft. Daher haben wir in DMXC Szenenlistengruppen / Cuelist Groups. Diese Gruppen kannst du auch so einstellen, dass nur eine Szenenliste glwichzeitig aktiv sein darf. Aktivierst du eine andere aus der Liste, wird automatisch die aktuell laufende Szenenliste beendet. Dafür musst du nur im Projekt Explorer eine neue Szenenlistengruppe anlegen und alle entsprechenden Szenenlisten da reinpacken. Um jetzt hier alle zu stoppen, kannst du entweder auch hiermit im Input Assignment sagen, dass alle aus der Gruppe gestoppt werden sollen. Oder du fügst einfach eine weitere, leere Szenenliste in die Gruppe ein und startest diese (so mache ich das immer, weil so der Aufbau überall gleich ist).
Viele Grüße
JP
hab ich den Kommentar im bugtracker so richtig verstanden, daß nun die presets automatisch new preset cuelist xy 01... benannt werden?
Ja, das hast du so richtig verstanden. Das Schema ist minimal anders, aber ja, so ist es.
Hilft vermutlich nur bedingt, und nur Leuten, die mehrere cuelists am Start haben.
Nö, warum? Es sagt dir ganz klar, dass das Preset in einer gewissen Cuelist enthalten ist. Dann kann man in dieser Cuelist im Namen der Cue schauen, wo das Preset genau hinterlegt ist.
Gibt es keine Möglichkeit, beim erstellen dem preset sofort händisch einen aussagekräftigen Namen zu geben?
Ohne einen gewissen Umbau nein und glaub mir, da haben wir uns schon Gedanken gemacht. Vorerst wird das so bleiben. Wir haben zwar eine Idee für einen zukünftigen Release. Aber wie gesagt, dafür sind gewisse Umbauten nötig und die werden wir jetzt nicht mehr machen.
Als Ergänzung noch, wenn du das nun umbauen musst: Wie du nun gesehen hast, baut DMXControl 3 sehr stark auf Geräte Gruppen auf. Ergo: Wenn du jetzt eh das umbauen musst, lohnt es sich vielleicht, noch mehr Gruppen anzulegen und zwar in den Pattern, wie du sie brauchst. Das geht ganz einfach, indem du in der Stage View die entsprechenden Geräte auswählst, dann einen Rechtsklick auf eines der ausgewählten Geräte machst und dann auf "Erstelle Gruppe aus Auswahl" (oder so ähnlich) klickst. Dann wird automatisch mit der Auswahlreihenfolge eine Gruppe erstellt und auch in deine aktuelle Stage View eingefügt. Denn niemand verbietet dir, ein Gerät in mehrere Gruppen zu packen. Tatsächlich nutze ich das bei mir auch sehr intensiv, also immer wenn ich eine spezielle Kombination brauche, erstelle ich eine Gruppe. Da muss man dann zwar etwas mehr darauf achten, die Übersicht zu halten. Dafür ist man super flexibel und kann die Gruppen nachher immernoch anpassen.
Viele Grüße
JP
Hallo,
ich hätte Lust, mich in meiner (zugegebenermaßen begrenzten) Freizeit mal an der Entwicklung einer kleinen App zur Fernsteuerung von DMXC3 zu versuchen. Ich habe gesehen dass es vor Jahren mal Ansätze zu einer Android-App gab, die aber nicht mehr weiter gepflegt wurde (letzter commit vor 9 Jahren). Außerdem würde ich gerne ein Cross-Plattform Framework wie z.B. Flutter benutzen in der Hoffnung dass das ganze dann sowohl unter Android, iOS als auch Web nutzbar ist. Wenn ich die aktuelle Architektur von DMXC richtig verstanden habe gibt es einen gRPC-Server („Umbra“), über den GUI und Backend kommunizieren. Ich habe auch gesehen, dass die gRPC Schnittstelle öffentlich verfügbar ist. Meine Idee war, die App über diese Schnittstelle mit DMXC sprechen zu lassen. Gibt es dazu weitere Dokumentation oder Beispiele, wie diese zu verwenden ist? Mich würde im ersten Schritt z.B. das Thema Softdesks interessieren - wenn es gelingt für Softdesks ein App-basiertes Frontend zu entwickeln wäre ja schonmal einiges möglich. Natürlich in der Annahme dass Softdesks kein reines GUI-Feature sind, so gut kenne ich mich mit DMXC dann doch noch nicht aus.
Hierzu mal als kleine Info, es gibt (oder gab zumindest letztes Jahr) Entwicklungen bezüglich einer App aus der Community. Da könntest du mal schauen / nachfragen, wie der Stand ist (war auf unserem Discord-Server).
Zu den Softdesks: Die sind aktuell leider tatsächlich ein reines GUI Feature. Das wird sich irgendwann noch ändern und wir planen da auch, die Management-Teile in den Kernel umzuziehen. Aber Stand jetzt sind diese rein in der GUI vorhanden.
Und noch eine Frage am Rande: Was ist eigentlich der Grund dafür, dass DMXC selbst nicht open source ist? Gewinn wird mit einer Freeware ja ohnehin nicht gemacht, warum also Entwicklung „hinter geschlossenen Türen“? Gerade mit Blick auf Community-Interesse wie meines würde Zugang zum Quellcode die Entwicklung ja sicher beschleunigen (für mich wäre es z.B. interessant zu sehen wie die gRPC Schnittstellen in DMXC verwendet werden).
Wir hatten uns bisher dafür entschieden, den Sourcecode nicht öffentlich zu halten, um so die Möglichkeit von Sonderversionen zu eliminieren. So gibt es eine offizielle Version, welche von uns stammt und nicht verschiedene weitere Versionen mit reingebauten Features, die ein User gerade spontan braucht. Das sorgt nur für Verwirrung zumal ein Großteil unserer Community auch eher nicht-Programmierer sind. Aber wenn jemand wirklich ein Feature einbauen will, geht das ganz gut über ein Plugin, weil man damit auch recht viel erreichen kann in DMXControl 3. Dafür gibt es auch entsprechende Beispiele auf unserem GitHub Account. Außerdem haben wir die Erfahrung gemacht (und man sieht das auch an vielen mittelgroßen Git-Projekten), dass zwar viele den Code dann nutzen wollen, aber wirklich mitgearbeitet wird nicht und so besteht auch eigentlich kein Unterschied bei den wirklichen Maintainer zwischen unserer Herangehensweise und von Open Source.
Das heißt aber nicht, dass wir nicht offen für Mitarbeit sind. Wir unterstützen gerne dabei, Entwicklungen für DMXControl 3 zu machen. Sei es mit Code-Beispielen oder Antworten auf Fragen zu der Funktionsweise. Und wer für DMXControl 3 entwickeln möchte, kann auch über den Beitritt zum Verein und entsprechender Mitarbeit Zugriff auf den Code erhalten.
Und zum Schluss: Von Zeit zu Zeit stellen wir unsere Entscheidung auch auf den Prüfstand und entscheiden dann jeweils auf Basis der aktuellen Gegebenheiten, ob wir weiterhin bei Closed Source bleiben oder doch in Richtung Open Source gehen.
Viele Grüße
JP
Ahhh, das wird mit "ValueChanged to Bool" gemacht
ja, habe ich jetzt hier gemacht, weil ich auf Änderungen reagieren wollte. Aber das Input Assignment hat ja so viele Möglichkeiten und das ist halt eine, um das zu berechnen
Wenn ich das Colorwheel korrekt konfiguriert habe, wird das dann im StageView auch animiert oder kann ich das nur Live überprüfen?
Das geht leider nur live. Dazu muss man sagen, dass die Stage View zwar einen guten Anhaltspunkt liefert, was gerade ausgegeben wird. Aber es werden nicht alle Gerätefunktion zu 100% visualisiert. Deshalb sagen wir auch nicht, dass die Stage View ein Visualizer wäre, denn es fehlen eben ein paar Gerätefunktionen (z.B. werden auch Prismen nicht dargestellt).
Hallo,
deine beiden Ansätze waren von der Denkweise her tatsächlich gar nicht so verkehrt Die Frage wäre eher, was du genau erreichen möchtest. Willst du die maximale Helligkeit dieser Gerätegruppe einstellen, dann ist der Gruppenmaster tatsächlich genau richtig. Dieser setzt sozusagen das Limit für die Ausgabe und alle Werte, die auf dieser Gruppe ausgegeben werden, werden dann entsprechend skaliert. Aber da du ja meintest, du bist bereits über den Gruppenmaster gegangen und das hat nicht das erwartete Ergebnis geliefert. Daher gehe ich mal davon aus, dass du damit wirklich den Dimmer steuern möchtest. Dann ist der Weg über die Master auch nicht falsch, aber du brauchst einen anderen: Beim Dimmer den ParameterMaster (bzw. den PositionMaster bei Positionen und den FarbMaster bei Farben). Diese kannst du dann in der Dimmereigenschaft des Geräts oder der Gruppe definieren (bzw. die anderen Mastertypen in den anderen Geräteproperties):
Das musst du aktuell tatsächlich genau so händisch eintippen. Wenn du mehr Master haben möchtest (also z.B. einen zweiten ParameterMaster für andere Geräte oder einen anderen Zweck), kannst du das übrigens entweder damit lösen, dass du im Projekt Explorer einen neuen Master anlegst oder indem du ihn einfach benutzt (also z.B. {ParameterMaster 2} eingibst) und dieser wird dann automatisch angelegt. Nun ist das so im Programmer, aber noch nicht fest gespeichert. Das speicherst du nun einfach in eine Cue in einer Cuelist. Wenn du diese Cuelist dann startest kannst du die Helligkeit mit dem ParameterMaster steuern bzw. wenn du den Slider über das Input Assignment mit dem Master verknüpfst auch damit.
Ich habe das mal in deinem Projekt umgesetzt, damit du mal siehst, wie das aufgebaut werden kann. Dabei habe ich auch noch eine Funktion eingebaut, dass diese Dimmer Cuelist immer gestartet wird, wenn du den Dimmerregler auf dem Softdesk veränderst. Außerdem war ich mal so frei, die Verknüpfung der Blackout-Cuelist im Input Assignment zu korrigieren und für diese Cuelist die Ausblendzeit in ihren Optionen auf die gleiche Dauer zu stellen wie die Fadezeit der Cue. So blenden nun die Scheinwerfer in 500ms in black über und wenn du den blackout ausschaltest, dann wieder in 500ms zurück auf die angegebene Helligkeit. Außerdem habe ich für deine Farb-Cuelists noch eine Cuelist Gruppe angelegt. Dort habe ich alle Farb-Cuelists hineingepackt und in den Gruppen-Optionen das Startverhalten auf "Nur eine Cuelist aktiv" gestellt. Das sorgt dafür, dass immer nur eine der Farb-Cuelists aktiv sein kann. Wenn du also eine startest, dann werden die anderen Farb-Cuelists automatisch gestoppt. Das spiegelt das Verhalten von Szenenlistengruppen wieder, die man in DMXControl 2 mit den Klammern im Namen angegeben hat.
Ich hoffe, das wird soweit klar. Falls nicht, einfach weiter fragen
Viele Grüße
JP
Für die Beispiele der Procedures gibt es eine eigene Seite: Procedures (DDF-Syntax examples) DMXC3
Ok, aber dann sollte diese Seite vielleicht auf der anderen Seite auch nochmal prominent verknüpft sein. Ich hatte das nämlich nicht gesehen und das ist eben auch anders wie bei allen anderen Seiten zu den Kanalfunktionen, bei denen das ja eingebettet ist. Da ich hier von einem einheitlichen Aufbau ausgegangen bin, habe ich dann nicht weiter danach gesucht.
Hallo,
Erst einmal finde ich es gut, dass du dir das erstellen eines DDFs aneignest Zu deinen Fragen:
Bezüglich dem range in der random Definition müsste ich mal in den Code schauen, was DMXControl 3 da erlaubt. Aber vermutlich ist das tatsächlich noch nicht so drin. Ich prüfe das mal und sag nochmal bescheid. Wenn das nicht erlaubt ist, könnten wir hier ein Ticket bei uns im Bugtracker anlegen, um das noch einzubauen, denn das ist schon eine sinnvolle Erweiterung.
Zu den System-Channels: Kanal 9 kannst du mit der Farbtemperatur-Definition definieren: https://wiki-de.dmxcontrol-projects.org/index.php?titl…#Farbtemperatur Dabei ist für dich die zweite Tabellenzeile interessant.
Die Kanäle 10 und 11 würde ich mit Raw-Kanälen https://wiki-de.dmxcontrol-projects.org/index.php?titl…reie_Funktionen in der jeweiligen Ausprägung (hier Rawranges) umsetzen. Damit hat man dann selbst definierte Funktionen gut abgedeckt.
Kanal 12 hängt so ein bisschen davon ab, ob diese Einstellung vom Gerät gesetzt wird, wenn man z.B. auf die Logarithmic Dimmer Curve geht, kurz wartet, dann den Kanal wieder auf null setzt und das Gerät trotzdem weiterhin die logarithmische Dimmerkurve verwendet oder nicht. Wenn das der Fall ist, dann schau in den nächsten Abschnitt, was ich zu Kanal 13 schreibe, denn das ist dann genau so umzusetzen. Wenn das Gerät die Dimmerkurve nur so lange ausführt, wie der Kanal 12 auch in diesem Bereich ist, dann würde ich das über eine rawstep Definition umsetzen.
Bezüglich der Gerätefunktionen (Kanal 13) geht das mittels Procedures. Die entsprechenden Funktionen, die DMXControl 3 hier unterstützt sind unter https://wiki-de.dmxcontrol-projects.org/index.php?titl…F-Syntax)_DMXC3 aufgelistet. Weil auf der Seite der Procedures keine Beispiele aufgelistet sind, habe ich hier mal eines herausgesucht. Du siehst sowohl ein Beispiel für eine vorgegebene Procedure als auch für eine selbst definierte mit eigenem Namen:
<procedures>
<reset>
<set dmxchannel="18" value="255"/>
<hold value="6000"/>
<restore dmxchannel="18"/>
</reset>
<procedure name="Pan Tilt Fast (Default)">
<set dmxchannel="17" value="13"/>
<hold value="5000"/>
<restore dmxchannel="17"/>
</procedure>
</procedures>Du kannst dabei (falls nötig) auch mehrere Kanäle innerhalb einer Procedure gleichzeitig setzen. Aber das sollte bei dir ja in dem Fall nicht nötig sein. Wenn du die Procedures angelegt hast, dann tauchen die in DMXControl 3 in der Stage View im Kontextmenü des Scheinwerfers auf (also einen Rechtsklick darauf machen).
Ich hoffe, das hat jetzt soweit geholfen. Wenn du weitere Fragen hast oder noch fragen offen geblieben sind, dann gerne melden
Viele Grüße
JP
Edit: Ok, während ich getippt habe, war dann 
LightningBrothersschneller
Um das mit dem Fehler im DDF noch etwas genauer auszuführen: Alle Versionen vor DMXControl 3.3.0 haben hier nicht ausreichend darauf geprüft, ob das DDF uneindeutig ist. Denn die Angabe im DDF mit range und minval gleichzeitig ist tatsächlich zweideutig und DMXControl 3 musste raten, was jetzt verwendet werden soll. Hier hatten wir schon in der 3.2.x eine Warnung eingebaut, dass solche DDFs in einer zukünftigen Version nicht mehr akzeptiert werden. Diese Warnung haben wir dann mit der 3.3.0 einfach in die Tat umgesetzt 
Deshalb ist das jetzt eben so und alte Projekte, in denen noch solche DDFs drin sind laden nicht mehr. Aber das ist ja üblicherweise einigermaßen einfach behebbar.
Viele Grüße
JP
Denn mit DMXC 3.3.0 wurden im MIDI-Bereich einige Dinge korrigiert, dass dies gerade in Kombination mit dem Backtrack besser und stabiler läuft.
Ich würde das noch drastischer formulieren: Mit allen Versionen vor 3.3.0 gab es im Midi Teil so gravierende Probleme, dass diese zu einem Absturz der Software führen können, die ein Neustart erfordeen, um Midi wiedee sauber nutzen zu können.
Ah ok, das ist auf jeden Fall schon einmal ein guter Hinweis. Vielleicht komme ich heute noch dazu, mir das anzuschauen, sonst in den nächsten Tagen.
Viele Grüße
JP
Öhm, kannst du mal bitte dein Projekt anhängen, damit wir das testen können? Denn eigentlich sollte das eigentlich nicht tun 
Viele Grüße
JP
Later cues in a cuelist depend on earlier cues. So lets make an example: If the first cue sets the dimmer to 100% and the second cue sets the color to orange, then 100% and orange is output if you run the second cue because the values of the first cue also count. This is the reason why the playstate of the cue changes if you activate it (because all later cues depend on it).
JP
Zur nicht vorhandenen galvanischen Trennung: Dies kann zu Störungen der Signalübertragung führen.
Da dies kein aktives Interface ist muss der PC das DMX Signal erzeugen. Da durch wird der PC "unnötig" belastet und es könnte Performance Probleme geben.
Nur um das noch etwas genauer auseinander zu sortieren: Ein aktives / passives Interface und die Galvanische Trennung haben nichts direkt miteinander zu tun und eine Galvanische Trennung hat auch nichts direkt mit der Verhinderung von Störungen zu tun. Um das nochmal einzuordnen: Die Aussage bezüglich aktiven / nicht aktiven Interfaces von Steff ist so voll korrekt, also ein PC wird tatsächlich stärker bei passiven Interfaces belastet. Eine Galvanische Trennung sorgt aber anders als es hier beschrieben ist für einen Schutz der Komponenten. Hiermit werden verschiedene Ein-/Ausgänge und Teile der Platine bis zu einer gewissen Durchschlagspannung (üblicherweise 1000V) von einander getrennt. Die beiden Features sind aber unterschiedliche Dinge. Man kann also auch ein aktives Interface ohne Galvanische Trennung oder ein passives Interface mit Galvanischer Trennung haben.
Als Beispiel zur Galvanischen Trennung: Ein DMX-Gerät könnte z.B. einen technischen Defekt haben und 230V auf die DMX-Leitung legen (hatten wir hier im Forum schon so Fälle). Dann verbruzelt im Zweifelsfall der DMX-Teil des Interfaces. Aber der PC-Teil und damit auch der PC sind durch eine Galvanische Trennung geschützt und gehen eben nicht kaputt (was bei fehlender Galvanischer Trennung wiederum recht wahrscheinlich ist).
Viele Grüße
JP
Hallo,
die Bestellung an unseren Zulieferer ist raus, aber wir haben leider noch kein genaues Datum, wann wir den aktuellen Batch bekommen. Aber sobald dieser da ist, kann man sich z.B. über unseren Shop informieren lassen.
Viele Grüße
JP
Hi and welcome in our forum
So when I stop and start again, the changed fade time is applied only then, is this normal?
Yes, this is totally normal and the way DMXControl 3 works. Fade / delay times are only updated after restarting the cuelist and e.g. fannings on device groups are recalculated for group size changes only after reapplying the fanning (or rerun the cuelist in which the fanning is stored). Otherwise, those checks would have major performance impacts and thus are not done.
JP
Und honsichtlich der Master gibt es aktuell nichts. Dafür gibt es schon ein Ticket, aber das ist eben noch nicht umgesetzt.
Viele Grüße
JP
