Das Nanoleaf-Plugin ist eine wunderbare Blaupause! Eigentlich tut es im wesentlichen technisch sogar 1zu1 das, was hier angestrebt wird. Nur leider halt auf die NanoLeafs gemünzt (was vermutlich schlicht daher rührt, dass es die erste Erweiterung für ein solches Device gewesen sein dürfte),
Werde mich also dann an dem Plugin orientieren. Danke euch!
Passender könnte dieser Thread für mich gar nicht sein!
Momentan brainstorme ich darüber irgendwie meine Elgato Key Light einbinden zu können. In meinem Fall zwar ein anderes Device, aber von der Vorgehensweise dann identisch zu den Geräten von charly.h, also HTTP basiert, mit eigenem integrierten HTTP Server mit API, auf den Key Light.
Ich könnte zwar ein eigenständiges Tool dafür aufsetzen (weil ich auf MIDI Signale reagieren will), aber es wäre halt echt genial, dies in DMXControl eingebaut zu kriegen. Daher tendiere ich, wie von 
JPK angebracht, zu einer Plugin-basierten Lösung.
Alles in Richtung der Lampen ist kein Problem. Allerdings ist mir noch nicht klar, wie ich mich dann mit DMXControl kommunizieren lasse. Vermutlich mittels IA (da fehlt mir nur bisher leider noch die Tiefe). Habe aber das Gefühl, dass ggfs Events vom IA heraus noch einfach sind. Aber wie ich das dann in einer Cue(list) setzen und entsprechen verarbeiten kann.. ja, da bin ich noch planlos.
Evtl hat da jemand direkt einen Ansatz parat, wo ich mich dran hängen und weiter vertiefen kann.
charly.h Da wir beide momentan dasselbe Ziel verfolgen, biete ich mich da gerne an, bei der Umsetzung eines Plugins zu helfen oder, falls keine entsprechenden Möglichkeiten bei dir selbst gegeben sind, das zu übernehmen und zu begleiten.
Hallo miteinander,
Einen Treiber für das Interface konnte ich nicht installieren. Ich weiß nicht wie ...
Ich vermute die Frage ist weniger „wie“ sondern eher „woher“. Beim Eurolite DMX512 Pro Mk2 sind die Treiber nicht im Lieferumfang dabei uns müssen bei Steinigke herunter geladen werden. Diese sind auf der Produktseite zum MK2 unten unter Downloads -> Support bereitgestellt. In der ZIP findet sich dann der Installer. Nach der Installation wird das MK2 dann, wie von Stefan erwähnt, im Geräte-Manager unter Ports (Com & LPT), bzw. auf deutsch Anschlüsse (COM & LPT) aufgelistet. Vermutlich dann als USB Serial Port (Com 3).
Kann ich nachvollziehen. Habe jetzt aber eher vermutet, dass InputAssignment-BeatSource eher als bevorzugter Ansatz, auch in der Umsetzung dann, angesehen werden würde. Eben weil im IA alles was MIDI in Richtung DMXC angeht da schon gegeben ist.
Die MIDI-BeatSource wäre dann 1:1, richtig? Wenn ich analog dann, wie beim Speed- und Parameter-Master, weitere anlegen und so auf eine andere Messages reagieren kann, wäre damit zumindest eine gewisse Flexibilität gegeben. Natürlich nicht auf eine einzelne Cuelist gesehen. Aber Cuelist A MBS#1, Cuelist 2 MBS2 dann ... das wäre ein Träumchen!
Wenn ihr Eine MIDI-BeatSource und oder MIDI-Timecode in die Software kriegen wollt, müsst ihr mir mehr zuarbeiten damit ich als Entwickler da was machen kann.
Sehr gerne!
In meinem Fall ist es rein vom Verhalten her mit der Tastatur nachstellbar. Ist kein Midi-Device, allerdings geht es in der weiteren Verarbeitung um das Verhalten als solches. Taste drücken, Signal.
Reicht das?
Der Midi-Beat kommt momentan bei mir durch die Zuweisung zweier Pads via Midi als Button (Siehe Screenshot Regelsatz).
Bleiben wir mal bei einem Pad, z.B. der Bass Drum. Diese wird getriggert (gespielt), das Signal geht über MIDI an DMXC, der als Button gesetzte Input reagiert, geht über den Konverter an das GO der Cuelist (Screenshot Verbindungssatz IST).
Die von dir als „MIDI-BeatSource“ benannte Quelle käme dann anstelle der Cuelist, beim Verbindungssatz (Screenshot Verbindungssatz Mock). Diese Quelle wäre dann der jeweiligen gewünschten Cuelist zugewiesen und könnte so, wie im letzten Screenshot exemplarisch) alle Cues durch navigieren.
Hoffe ich habe jetzt nichts vergessen.
Hi miteinander
In diesem Sinne: Nur zu
Willkommen im Club der Spezial-Fälle-Nervensägen 
Zum einen kann man die Cuelist durch einen externen Trigger mit eigener Logik Schritt für Schritt weiterschalten. Der Aufwand dafür scheint groß, aber durch Copy&Paste der Connectionsets und per Drop&Replace (von mir gerade mal erfundenes Kunstwort) der Knoten sollte das trotzdem halbwegs schnell gehen. Mit Drop&Replace meine ich, dass man einfach Knoten austauschen kann, indem man einen anderen aus dem Baum links per Drag&Drop auf den entsprechenden Knoten zieht. So kann ich beispielsweise einfach den Input "Taste D" durch "Taste S" per Drag&Drop ersetzen. Gleiches geht natürlich auch für die MIDI-Inputs.
Danke für deine ausführliche Antwort.
Unter Berücksichtigung der aktuell technischen Möglichkeiten in DMXC, wäre der erste Punkt dann (weiterhin) der Workflow für mich. Klar, gehen tut das. Ist für mich aber dennoch weiterhin Kategorie „Geil ist anders“. Drop&Replace gefällt mir dafür sehr. Schöne Kreation!
Umgekehrt betrachtet, sehe ich das aber auch als Bestätigung an, dass ich bisher auf dem momentan wohl richtigen Weg unterwegs bin, um das gewünschte Verhalten an sich zu erreichen. Das ist auch, unabhängig oder trotz des Aufwandes, schon mal Gold wert!
Ein dedizierter MIDI-Trigger macht auch keinen Sinn, denn es wäre nur wieder eine Art manual- oder beat-Trigger (jenachdem, welchen Weg man geht), der aber sehr eingeschränkt auf den MIDI-Input und nicht allgemeingültig ist. Gibt es dann plötzlich eine neue Art Input (z.B. ein Clocksignal über Art-Net) bräuchte man schon wieder einen weiteren Trigger usw. was wirklich eine Redundanz ist und hier keinen Mehrwert liefert.
Ein dedizierter Trigger wäre in der Tat nicht notwendig. In deiner Ausführung hast Du für mich aber wunderbar genau die Stelle aufgezeigt, wo man da aufsetzen könnte: Bei der Taktquelle!
Okay, bisher ist vorgesehen bzw. technisch gegeben, dass auf Basis vom SpeedMaster oder ManualBeat (ist der Beat Generator im AudioAnalizer, richtig?) taktgesteuerte Signale zur Verfügung stehen. Soweit auch alles gut. Allerdings sind beide genannten erstmal nur eines: Eine Quelle. Eine Beat-Quelle, welche (auf irgend einer Weise gesetzt) zeitlich hintereinander folgende Beat-Signale automatisch liefert. Und besagter Automatismus ist für mich momentan hinderlich. Ich möchte nicht x Mal auf ein Pad hauen um einen Beat zu generieren, welcher dann wunderbar für sich alleine seine Arbeit verrichtet. Mal überspitzt ausgedrückt: Ich möchte ein Signal geben, mit einem Schlag auf ein Pad. Gehe dann gemütlich einen Kaffee trinken, evtl noch Einkaufen, dann noch mit Hund spazieren..... komme wieder und haue wieder aufs Pad und es geht weiter.
Der eigentliche Schönheitsfehler für mich momentan (bis jetzt ist ja alles wie beschrieben erst mal an sich „machbar“), ist, dass ich als Trigger momentan beat gewählt habe (wieso, wie im vorherigen Post beschrieben), aber dennoch über IA einfach nur über GO weiterschalte. Irgendwo läuft also (meinetwegen auch bei mir!?) was falsch.
Dem bestehenden Beat-Trigger kann die Art der Quelle egal sein. Dieser bekommt einfach nur den Impuls zum Reagieren, ob automatisiert oder EBEN dann manuell. Daher wäre es einfach super, wenn das irgendwie realisiert werden kann.
Ob das zukünftig (...) als (weitere) dedizierte Taktquelle(Art) oder wie zuvor angemerkt in Verbindung mit einem der bestehenden Mastern mal möglich sein wird, ist dann erst Mal egal und eher flexibel in der Entscheidung. Zudem auch nicht redundant und würde weiterhin einen generischen Ansatz garantieren.
Hallo miteinander,
ich möchte mich dieser Thematik anschließen, da ich mich vom Thread-Titel regelrecht angesprungen fühle, da er nicht passender sein könnte. Mein Bedürfnis beschränkt sich allerdings rein auf den Trigger selbst. Der beschriebe Workflow und das ausformulierte Ziel betreffen mich also weniger. Hoffe acdnrg du siehst es mir nach, dass ich mich rein auf einen Aspekt einklinke.
Ich würde einen MIDI-Trigger bei den Cuelists begrüßen. Momentan verfolge ich den von JPK genannten Ansatz, über das Input Assignment durch eine Cuelist durch zu navigieren (über mein E-Drum als Midi Device, mit dem simplen Verhalten: Schlag auf Trommel, Signal, GO!). Wegen dem von mir angezielten Verhalten der Cue(list), habe ich momentan als Trigger beat gewählt. Mit manual geht an sich auch. Allerdings brauche ich eher das Verhalten, dass nicht gleich beim Starten die erste Cue aktiv ist, daher beat. Und auf eine einzelne Cuelist gesehen, funktioniert das auch wunderbar.
Momentan habe ich allerdings einen enormen Aufbereitungs- und Verwaltungsaufwand in den Input-Bänken (bei der Verarbeitung der Midi-Signale), sobald mehrere Cuelists auf dasselbe Midi-Signal reagieren sollen (z.B. auf Bass Drum und/oder Snare). Zudem sei noch erwähnt, dass ich eine Cuelist nicht über das IA aktivieren will (erfolgt momentan auf anderem Wege). Mit der Anzahl der Cuelists, welche in irgend einer Form auf diese Signale reagieren sollen, steigt also auch die Anzahl der Bänke bzw Connection Sets, welche ich zusätzlich aktivieren/deaktivieren muss, damit immer nur die jeweils gewünschte Cuelist darauf reagiert.
Hier sehe ich großes Potential, wenn ich wirklich nur noch im IA ein Mal die eigentlichen Midi Inputs definieren muss und dann an der jeweiligen Stelle in der Cuelist (wo es wirklich relevant ist, an der jeweiligen Cue) zu setzen. Da die Trigger eh nur reagieren, wenn die eigentliche Cuelist aktiv ist und ich mich sonst keinen Kopf um das IA machen müsste, wäre das ein enormer Mehrwert und Hilfe.
Da folgendes vom eigentlichen Thema abschweift, mal so verarbeitet...
Alternativ kann ich mir auch die Erweiterung der Master vorstellen, mit einem Single-Mode. Momentan – sofern ich das richtig einschätze – dienen Speedmaster und auch Manual Beat immer nur dazu, um eine BPM zu kreieren. In meinem Fall bin ich aber der Beat bzw der Speedmaster. Und wenn es möglich ist, auf welchem Wege auch immer, dann meinetwegen in Verbindung mit dem beat Trigger das so zu erreichen, dass immer nur mit jedem weiteren Schlag (...) der Trigger reagiert, bin ich schon absolut happy. Wenn das schon jetzt möglich ist umso besser (mir nur leider bisher unbekannt).
Also der Weg, das Beat-Signal via MIDI von Traktor nach DMXC3 zu schieben, macht zum Beispiel Helmut . Er triggert damit die Speedmaster in DMXC3, welche dann wiederum die Cuelists mit ihren Cues triggern.
Mit einem kleinen Trick sollte es sogar seit DMXControl 3.2.2 möglich sein, den Speedmastern den exakten BPM-Wert zu übergeben. Wenn du den auf in der "Quelle" als MIDI-Wert zwischen 0 und 127 rausbekommst, kannst du diesen in DMXC3 wieder verrechnen und hast einen exakten Wert.
Gibt es dazu an anderer Stelle weitere Infos bzw. Beispiele? Sowohl die Umsetzung von Helmut als auch der beschrieben Trick klingen sehr interessant, das mal genauer sehen zu können.
Hallo miteinander,
JPK Auf den berühmten Timecode Player freue ich mich schon sehr, denn er würde von der Steuerungsmöglichkeit eben genau in die Richtung gehen, wie ich es bräuchte. Bis zum Release, behelfe ich mir dann eben anders.
Ihr seid da natürlich praxiserfahrener als ich, daher kann ich mich auch irren. Ich würde jetzt zumindest davon ausgehen, dass es besser ist, wenn vor allem eine zeitliche Steuerung des Lichts, eben vom Chef der Lichter, sprich DMXControl 3, übernommen wird, trotz der Möglichkeit zur externen Steuerung.
LightningBrothers Wir sammeln bzw. evaluieren hier immer mehr Cuelist-Typen: Show-Cuelist, Song-Cuelist, Light-Cuelist. Gefällt mir! Gibt s noch weitere?
Coole Lichtshows!
Die (eigentlichen) Presets habe ich bisher eher stiefmütterlich behandelt. Sehe da die Cuelist als quasi „besseres Preset“. Allerdings hatte ich bisher die Anwendungsfälle von Show-Cuelists bisher nicht so im Blick.
Hier kristallisiert sich für mich gerade eine kontext-abhängige Verfahrensweise heraus, wann man was besser (zusammen) einsetzt. Hier kommen wir evtl. sogar zu Best Practices!?
Show-Cuelist
Hier kann ich nachvollziehen, dass die Presets der bessere Helfer sind, um wiederkehrende Lichtstimmungen bzw Eigenschaften in eine Cue zu setzen. Aber selbst ohne Presets, wenn man Cue für Cue komplett manuell setzt.
Solange beim Event ein fester Ablauf gegeben ist, fährt man hier recht gut. Also wunderbar für Theater und auch Bandauftritte mit fester Setlist.
By the way: Was ist hier eine übliche Anzahl an Presets, welche man da hat? 100? 1000? Schon bei 50 alleine, sehe ich die Liste der Presets dann aber auch ganz schön aufblähen und in der aktuellen Präsentation und Handhabung als recht unhandlich, dann jedes Mal da auf die Suche zu gehen.
Song-Cuelist
Eine Song-Cuelist sehe ich zum einen als Bruchteil (Repräsentation) einer Show. Zum anderen vor allem eben auf den jeweiligen Song gesehen. Hier könnte ich auch die Presets zur Hand nehmen, um die Lichtstimmungen etc zu setzen. Oder eben Light-Cuelists hier aus ansteuern. Und vor allem könnte ich die eigentliche Song-Cuelist in einer Show-Cuelist aufrufen...
Und auch wenn ich, wie im vorherigen Post, die Special-Cue in der Handhabung (bei mehreren zu startenden Cuelists) momentan als umständlich erachte, würde ich diesen Ansatz dennoch bevorzugen.
Unabhängig davon wie eine Song-Cuelist nun zusammen gebaut wurde, sehe ich hier eben den Vorteil darin, diese On Demand aufrufen und ausführen lassen zu können, wenn der Ablauf (der Show) nicht fest ist. Das wäre z.B. bei mir der Fall. Ich habe keine feste Setlist, welche ich immer erneut so durchspiele.
Light-Cueslist
Mmmh, die dürften offensichtlich sein, oder?
========
Ich stehe noch am Anfang, mir alles aufzubereiten. Ich habe mit Stand heute 300 Songs, welche ich mit der Zeit (also irgendwann mal...) mit jeweils einer eigenen Ablauf an (passenden) Lichtstimmungen versehen möchte. Und selbst wenn ich einfach nur mal drei drei Songs exemplarisch nehme, habe ich im Best Case voll individuelle (sich nicht wiederholende) Lichtstimmungen. Wie bei vielen anderen Dingen im Leben aber auch, gehe ich davon aus, dass sich bestimmte Lichtstimmungen, Effekte etc einfach für bestimmte Stellen in einem Song bewährt haben. Hier mangelt es mir natürlich an der Praxiserfahrung. Aber die unterschiedlichen Eigenschaften in Kombination, führen denke ich schon zu genügend Abwechslung. Also ob ich bei Song A Moving Heads habe die Blau leuchten oder bei Song B Moving Heads sich identisch bewegen, aber eben Grün leuchten. Und so weiter. Einen Song kann man dann ja noch untergliedern, in Intro, Strophe, Refrain, Bridge usw.
Zum Anfang hin dürfte es also eher grob und sich sehr wiederholend zeigen. Oder mit anderen Worten: Eintönig und einfallslos. Aber mit der Zeit wird es immer granularer, individueller etc. Und beim Ansatz einer Wiederverwendung sehe ich da den Vorteil nicht nur bei der initialen Zuweisung. Dann kommen erst Bearbeiten oder gar ersetzen ins Spiel. Wenn ich eine bestimmte Cuelist z.B. in zehn Songs (an irgend einer Stelle innerhalb des Liedes) gesetzt habe und diese Cuelist in irgend einer Form bearbeite, dann zeigt sich diese Änderung direkt bei allen Songstellen, wo diese Cuelist zum Einsatz kommt. Ist wie bei Smart-Objects in Photoshop oder gar in der Softwareentwicklung, wo ich eine zentrale Implementierung einer Funktion habe. Wenn ich eine Änderung an 100 weiteren Codestellen noch nachziehen muss, mache ich was falsch. Redundanz ist je nach Menge per se nicht schlecht. Aber die Regel ist eher: große Menge! Besonders nach einer gewissen zeit.
Außerdem, wenn ich einen Preset bearbeite, dann ist der Preset selbst bearbeitet. Die Änderungen wirken sich aber nicht direkt auf die Geräte aus, oder?
Hallo miteinander,
Hallo,
folgendes ist erst einmal unabhängig von den Antworten, die dir Stefan und Patrick gegeben haben: Bitte beachte, dass dein Plugin nur noch für die 3.2.X Versionsreihe nötig ist, denn wir bauen gerade die komplette Kommunikation auf gRPC um (bzw. haben das intern schon getan und arbeiten da gerade an den Fixes). Das wird dann mit DMXControl 3.3 ausliefert. Ergo sollten solche Dinge dann zukünftig darüber laufen. Wenn du es unbedingt brauchst, kannst du dir dann deine eigene GUI bauen und dir die einzelnen Teilbereiche, die du haben möchtest holen. Die entsprechende Protobuf Spezifikation soll dann auch veröffentlicht werden, sobald diese mal soweit fixiert ist. Dies vielleicht als Warnung, dass du nicht zu viel Zeit rein steckst, viele Aktionen über deinen Seitenkanal zu triggern
Viele Grüße
JP
Die große Frage ist: Wann kommt 3.3? 😁 Geht mir jetzt nicht um eine Aussage dahingehend (und sorry, sollte das an anderer Stelle kommuniziert sein). Worauf ich hinaus will: Wenn das erst Ende des Jahres ist, dann ist noch genügend und Zeit bis dahin für einen Einsatz 😀
Das ganze am Ende auf gRPC umzubauen ist zudem unkritisch. Zumal könnte ich dann beim Client sogar einen Technologiewechsel machen. Und mal allgemein gesprochen: Es macht mir einfach Spaß!
Die Veröffentlichung der Spezifikation ist sehr gut! Es war schon ein kleiner Akt für mich, in den aktuellen Ressourcen mal richtig durchzusteigen. Umso schöner, wenn dann ne Referenz veröffentlicht wird. 
Guten Abend!
Was meinst du mit generischen Wiederverwendung? Ich hatte dein Plugin im Endeffekt so verstanden, dass dieses den Anwendungsfall "ich habe einen Pool von Cuelists und möchte aus diesem Pool die Cuelist in verschiedenen, fest vorgegeben Reihenfolgen zu unterschiedliche Songs mit nur einem Klick wieder aufrufen und anhand eines Timecodes akkurat abspielen" abbildet. Oder habe ich da noch etwas überlesen? Denn die Antwort von Patrick wäre nämlich auch meine erste gewesen.
Viele Grüße, Stefan.
Mittlerweile hat es bei mir Klick gemacht. Wieso auch immer, war ich bei der Vorstellung, dass die Special-Cue immer „nur“ am Ende einer Cuelist sitzt und dann die nächste Cuelist aufruft. Dass ich aber eine Cuelist auch mit Special-Cues vollklatschen kann, welche alle immer eine andere aufrufen, dafür hat es jetzt einen Moment gebraucht.
Also technisch geht der Vorschlag von patme und dir dann schon in die Richtung. Ich habe „Licht-Cuelists“ (welche bei den Geräten das Licht definieren). Dann lege ich für einen Song eine „Song-Cuelist“ an und befülle diese entsprechend mit Special-Cues, welche jeweils die „Licht Cuelists“ abarbeitet. Eine Wiederverwendung von Cuelists ist damit gegeben. Cool!
Aber...unabhängig vom Trigger (um innerhalb dieser „Song-Cuelist“ zu navigieren) ist es in der Anwendung dieses Ansatzes momentan doch recht mühselig. Dabei ist es noch recht einfach, wenn eine Licht-Cuelist (welche via Special Cue aufgerufen wird) das Licht für alle Geräte definiert. Wenn ich allerdings ordentlich getrennte Gerätegruppen habe und zudem auch noch unterschiedliche Cuelist Groups (Licht, Dimmer, Effekte etc), dann muss ich jeweils für die Anzahl X an aufzurufenden Cuelists entsprechend so viele Cues setzen. Klar, alle auf Auslöser Follow, Auslösewert 0(ms) und dann laufen die, bis zum nächsten Trigger, welcher dann die nächsten so gruppenweise laden soll. Empfinde ich zum jetzigen Zeitpunkt aber doch recht als umständlich.
Und dann komme ich erst zum eigentlichen Trigger. Timecode innerhalb von DMXControl 3.2 geht nur in Verbindung mit einem dort hinterlegten und geladenen Audio-File. Mittels Beat...könnte man auch via IA auf irgend einem Wege produzieren. Klingt in meiner Vorstellung gerade aber auch nach Gefrickel. Schaue ich mir aber noch mal an.
Hallo Patrick,
die Special-Cue ist mir auch schon unter die Augen gekommen. Allerdings, wenn ich das richtig deute, ist diese dann fix auf eine bestimmte ClueList gesetzt. Also Ja, damit kann man technisch gesehen eine CueList-List aufbereiten. Allerdings sehe ich da gerade keine Möglichkeit zur generischen Wiederverwendung von ClueLists. Aber wie immer: Nur weil ich etwas nicht sehe, heißt das nicht, dass nicht dennoch etwas da ist
Ansonsten: tolle Idee!
Danke dir!
Hallo miteinander,
ich möchte gerne mit euch mein sich in der Entwicklung befindende Kernel-Plugin für DMXControl 3 teilen:
MyKLC - My Kernel Lightning Control
Was macht es?
Über eine UDP Socket gestützte Verbindung ,durch Hinzunahme der jeweils verfügbaren Message Actions, kann eine entsprechende Funktionen im Kernel aufgerufen und verarbeitet werden. Je nach Aktion erfolgt zudem eine Antwort zurück an den Client.
Das Plugin arbeitet mit vorhandenen Projekten, welche zuvor entsprechend aufbereitet wurden.
Disclaimer
Zum einen aus Gründen der Transparenz, aber natürlich auch zur Möglichkeit Input seitens der eigentlichen UrheberInnen der genutzten Programm-Ressourcen zu erhalten (natürlich gerne auch andere Plugin-EntwicklerInnen), ist der Code auf GitHub einsehbar.
Das Repository: https://github.com/Wampe/MyKlc
Noch ein paar Entwicklung- und Projektspezifische Anmerkungen:
Wieso überhaupt das Plugin?
Nachdem ich mich in DMXControl eingearbeitet und auch andere verfügbare Plugins evaluiert habe, kam ich zu der Erkenntnis, dass ich meinen angedachten Workflow mit den eigentlichen Bordmitteln (sowie verfügbaren Plugins) zum jetzigen Zeitpunkt nicht umgesetzt bekomme. Das ist absolut wertfrei gemeint. Nur weil ich bestimmte Funktionen einer Software nicht nutze(n kann), ist diese deshalb nicht schlecht. Zudem kann sich dies in Zukunft ändern, mit neuen Versionen (mit neuen Features, Anpassungen etc).
Bei mir ist es jedenfalls so, dass zum jetzigen Zeitpunkt Executer, Softdesk als auch Input Assignment (welche alle für sich gesehen wunderbare, starke Features sind) mir nicht dienlich sind, meinen angedachten Workflow optimal umzusetzen. Was mir zudem momentan in DMXControl 3 fehlt, ist quasi eine CueList-List bzw. CueList-Playlist-Funktion, in der ich CueLists (ggfs. auch mehrfach) hinein legen und dann nach bestimmten Kriterien ablaufen lassen kann. Aber das ist alles nicht wild, denn das wird in einem entsprechenden eigenen Client-Tool von mir berücksichtigt (und wieso dadurch auch eben dieses Plugin geboren wurde).
Vom Gerätemanagement bis hin zum Aufbau der gewünschten Lichtszenen, in Verbindung mit den grandiosen Gruppenfunktionen, wird mir DMXControl 3 (vor allem der Kernel) daher wunderbar behilflich und dienlich sein.
Welcher Workflow eigentlich überhaupt?
In meinen Livestreams, in denen ich Schlagzeug spiele, kann – nein möchte – ich nicht proaktiv auf das Licht eingehen. In Relation zum jeweiligen Musikstück, soll eine von mir vordefinierte Reihenfolge an CueLists (auf Timecode Basis und an das Plugin gesendete Trigger) abgespielt werden. Welche CueList zu welcher Zeit dann aufgerufen und gestartet wird, erfolgt auf Basis einer Playlist im Client. Das jeweilige Musikstück ergibt sich zudem auf Basis eines Song Requests, welcher von einen Dienst im Internet aus geladen wird. Daher verfolge ich das Ziel, Musik (die notwendigen Audiodateien also) sowie die dazu gehörende Licht-Playlist, mit einem Mausklick zu laden und abzuspielen.
Evtl. wird durch diese Ausführung auch etwas klarer, wieso ich angefangen habe das Plugin zu entwickeln. Sollte sich im weiteren Verlauf ergeben: „Jung, das geht wunderbar so und so...“ kann ich auch wunderbar damit leben, wenn das Repository dann nur noch ein Dasein als aktuelles Beispielprojekt hat, für die Entwicklung eines Kernel Plugins.
Hi miteinander,
ich fühle mich wieder erschlagen. Aber dieses Mal im positiven Sinne. Diese große Resonanz, von eurer Seite, freut mich sehr.
Würden wir zusammen in einem Raum sitzen, im Rahmen eines Workshops, hätten wir mit allen Wortmeldungen eine wunderbare Ausgangslage, mit vielen wichtigen Aspekten, Informationen und Erkenntnissen, um daran weiter zu feilen.
Ich erkenne, dass ihr euch einigem sogar bestens bewusst seid und vor allem, dass ihr empfänglich seid. Wenn aber, wie von JPK angeführt, auf eine Anfrage nur noch Wüstenhexen durchs Bild rollen, dann sind euch natürlich auch schlicht erst Mal die Hände gebunden, im Rahmen eurer Möglichkeiten.
Allerdings scheint es für mich auch so als wären gerade die mächtigen Funktionen und auch die Flexibilität, welche definitiv eine Stärke sind (für sich gesehen), momentan die größte Schwäche sogar (bezogen auf die Aussage von nutzer99 „Den Start für einen Anfänger runterzubrechen ist für uns schwierig, ...“). Aber auch hier sehe ich schon Ansätze und Potential, wo bzw wie man das ändern könnte.
Ich lasse gerne noch hier zu, aber auch generell, weiteren Input folgen. Weiß aber noch nicht wann ich dazu kommen werde. Heute soll weiteres Licht geliefert werden. Muss DMXControl anwerfen und befüllen
Hallo Dennis
erst mal Herzlich Willkommen hier im Forum
Vielen Dank!
Spaß und Freude, sowohl in der Software als auch im Forum, wird sich garantiert finden.
Hallo und herzlich willkommen im Forum
Auch an dich vielen Dank und...
Uns würde interessieren, was für dich dazu führt, dass deiner Meinung nach DMXControl 3 vor allem für Power User ist. Was muss sich ändern, dass dieser Eindruck nicht gleich am Anfang aufkommt.
...das mache ich sehr gerne. Allerdings in Form des nun folgenden Videos. Warum, erläutere ich auch am Anfang.
https://www.youtube.com/watch?v=13gyqbb72Mg
Grüße
Wampe
Hallo miteinander,
um mich als Neuling im Forum auch noch kurz vorzustellen, ich bin mit dem Namen Dennis beschenkt, Frontend-Entwickler bei Tag, Musiker bei Nacht und mit Stand heute, der Kategorie (Medium-)Anfänger zugehörig. Sowohl was Lichttechnik in der Praxis, DMX und eben DMXControl angeht.
Nutzerprofil: Alleinunterhalter (am Schlagzeug) und von meinem beabsichtigten Workflow (wohl) Nische und definitiv nicht (eigentliche) Kernzielgruppe von DMXControl.
TL;DR
Mein Fazit zu DMXControl: 510 von 512 DMX Kanälen.
Nach meiner Einarbeitung in DMX und dem Herantasten an anderen (denke mal wohl allen hier bekannten alternativen) Tools, wandte ich mich dann nach erfolglosen Versuchen DMXControl zu. Wie bei den vorherigen Kandidaten auch: Erst mal nur installieren, starten und... im Fall von DMXC erschlagen werden. Unabhängig von der Kenntnistiefe der Fachlichkeit eines Benutzers: Einsteiger-freundlich, bei einer Software, sieht anders aus! Aber diese Überfülle signalisierte dennoch eines: Profianwendung.
Faktoren wie der Verein, die Community, die DDF Lib und vor allem für mich vor allem Ausschlag gebende Punkt, die Langlebigkeit und Aktualität der Software, ließen mich dann schon mal durch sämtliche Seiten im Wiki und hier im Forum klicken. Umso erfreuter war ich dann auch, als ich auf die jüngsten Videos stieß (sowohl der konkrete Einstieg in Form der Tutorials Blöcke 1 bis 3, sowie das „Let´s build a project“), da ich eher der Audio-Visuelle Lerntyp bin. Und diese sind für mich einfach wunderbar. Die drei Tutorial-Blöcke quasi als Theorie, das „Let´s build...“ mit praktischer Darstellung, als super Ergänzung bzw. Vervollständigung. Nachdem ich heute den dritten Block vom Let´s Build noch gesehen habe, fühlt (...) es sich so an, als würde ich nun 90% der Funktionen, Ressourcen sowie der Workflows in DMXControl kennen, verstehen und jetzt in der Lage sein, diese auch selbst praktisch anzuwenden und so zu vertiefen. 90% ist evtl. hoch gegriffen. Allerdings ist das sehr motivierend für mich und vor allem eines: Wichtig für die Erkenntnis, bis zu welchem Grad DMXControl für mich greifen kann, einen Mehrwert bietet und was ich noch selbst Erarbeiten muss, um meinen geplanten Workflow zu erreichen. Und zu meiner weiteren Freude: Das tut und wird es.
Fachlich und Funktional ist DMXControl gut gelungen. Aber neben einem Entwickler-Team, welches diese gute Arbeit leistet, zeichnet sich das Projekt hier auch in seiner Kommunikation und Betreuung durch weitere Akteure aus. Ich bin noch nicht lange genug hier, um einzuschätzen, wer der Forenmitglieder alles vom Team bzw vom Verein ist oder zu den alten Foren-Hasen aus der Community gehört. Aber hier findet man Gehör und Hilfe.
Auch wenn ich DMXC weiterhin mit dem Fokus auf Power User sehe, fühle ich mich gerade durch die genannten Videos bestens an die Hand genommen und geholfen, um auch als Einsteiger in DMXControl Fuß fassen und austoben zu können.
Ich bin zufrieden!
Beste Grüße
Wampe
