MyKlc - My Kernel Lightning Control

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:

• Der initiale Codestand kann gebaut werden.
• Die bisher zur Verfügung stehenden Aktionen sind auch funktional.
• Die Anzahl der Aktionen ist zu Anfang natürlich noch sehr dürftig. Hier kommt es aber auch darauf an welche Funktionen (je nach Client) überhaupt zur Verfügung stehen könnten/sollten.
  Momentan entwickle ich primär für meinen geplanten Workflow. Vorschläge zur Erweiterung sind aber definitiv willkommen.
• Versionierung und Release erfolgen momentan noch manuell. Sollte bei Zeiten schauen, dass ich einen automatisierten CI/CD Prozess aufgesetzt bekomme.

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.

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

Quote from patme

Ansonsten: tolle Idee!

Danke dir!

Hallo miteinander,

Quote from JPK

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.

Quote from LightningBrothers

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 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?