Adapter für MIDI-Controller als Macro-Board

    Hallo zusammen,

    ich nutze seit ein paar Jahren einen APC Mini Mk II, den ich per MIDI zur Steuerung von DMXControl 3 einsetze.
    Schon länger suche ich nach einer sinnvollen Lösung, um auf dem Controller mehrere Seiten/Pages anzulegen und dadurch mehr Aktionen auf die Buttons legen zu können.

    Für meinen letzten größeren Einsatz habe ich mir dazu ein Programm geschrieben, das zwischen DMXControl und dem APC sitzt und die Verwaltung der verschiedenen Pages übernimmt. Da dieses Programm jedoch auf beiden Seiten ausschließlich über MIDI kommuniziert hat, war die Umsetzung durch die Limitierungen von MIDI ziemlich eingeschränkt.

    Vor kurzem bin ich in DMXControl über die Macro-Board-Funktion gestolpert. Diese entspricht im Prinzip genau dem, was ich mit meinem MIDI-Controller erreichen möchte. Auch Paging scheint über unterschiedliche Profile möglich zu sein.
    Soweit ich weiß, gibt es dafür aber bislang keine direkte MIDI-Anbindung?

    Nun habe ich in einem anderen Beitrag gelesen, dass die Definitionen des Netzwerkprotokolls von DMXControl 3.3 öffentlich zugänglich sind. Beim Durchstöbern ist mir aufgefallen, dass dort auch Macro-Boards berücksichtigt werden.

    Daher meine Idee:
    Wäre es grundsätzlich möglich, einen eigenen „Client“ zu schreiben, der auf die Macro-Boards zugreift und die Daten zu MIDI übersetzt?
    Also so, dass das Feedback des Macro-Boards an den Controller weitergegeben wird – und umgekehrt die Knopfdrücke vom MIDI-Controller an DMXControl gelangen?

    Falls das über das Netzwerkprotokoll machbar wäre, würde ich das gerne in nächster Zeit ausprobieren.

    Viele Grüße
    Fabian

    Quote from SvenFinn

    Daher meine Idee:
    Wäre es grundsätzlich möglich, einen eigenen „Client“ zu schreiben, der auf die Macro-Boards zugreift und die Daten zu MIDI übersetzt?
    Also so, dass das Feedback des Macro-Boards an den Controller weitergegeben wird – und umgekehrt die Knopfdrücke vom MIDI-Controller an DMXControl gelangen?

    Falls das über das Netzwerkprotokoll machbar wäre, würde ich das gerne in nächster Zeit ausprobieren.

    Kurz gesagt: Ja, das geht. Du kannst eine eigene Applikation schreiben, die sich im DMXControl 3 in das Netzwerk anmeldet und dann auf die MacroBoard-Elemente subscribed. Letztendlich macht da die GUI nichts anderes.

    im Falle eines Falles klebt Gaffa einfach alles, denn Gaffa ist dein Freund und Helfer :thumbup:

    Was du aber auch schon mit Board-Mitteln in DMXC3 machen kannst: du legst dir im Input Assignment mehrere Bänke an, die du dann für die Funktionen der jeweiligen zusätzlichen Seite ein- bzw. ausschaltest. Auch die Bänke lassen sich im Input Assignment triggern. So brauchst du deinen MIDI-Controller auch nur einmal anlernen, weil die Umschaltung der Seiten wie gesagt softwareseitig erfolgt.

    Ah weil ich es oben in meinem Post vergessen habe: Das Netzwerkinterface von DMXControl 3 findest du hier: https://github.com/DMXControl/DMXControl3-Network-Interface Wenn du diesen Weg gehen möchtest, schau dir mal den Discovery- und ConnectionClient unter source an. Damit solltest du dich verbinden können.

    im Falle eines Falles klebt Gaffa einfach alles, denn Gaffa ist dein Freund und Helfer :thumbup:

    Servus zusammen,

    der Tipp mit dem Netzwerkprotokoll war wirklich hilfreich – vielen Dank dafür! :)

    Ich bin inzwischen soweit, dass ich mich erfolgreich mit Umbra und dem Kernel verbinden kann.
    Dabei stellt sich mir jedoch die Frage, wie genau die UserContexts funktionieren. Nach meinem bisherigen Verständnis besitzt jeder Benutzer einen eigenen Context. Wenn ich also – wie das GUI – mit dem Benutzer DMXCDefault arbeite, sollte ich doch eigentlich auf dieselben Daten zugreifen können, oder?

    Unter dieser Annahme habe ich angefangen, mit dem MacroBoard-Teil von DMXControl zu arbeiten.
    Dabei bin ich auf das Feature MacroBoardProxy gestoßen. Verstehe ich es richtig, dass man damit softwareseitig eigene MacroBoards registrieren kann?

    Ich habe das testweise ausprobiert, konnte jedoch im GUI nicht auf die MacroBoards zugreifen, die mein Client erstellt hat.
    Habt ihr vielleicht ein paar Hinweise oder Tipps, woran das liegen könnte bzw. wie man das korrekt umsetzen muss?

    Vielen Dank im Voraus!
    Fabian

    P.S.: Wer sich den (noch etwas chaotischen) Code ansehen möchte, findet ihn hier: https://github.com/SvenFinn/umbra-client

    Hallo,

    Quote from SvenFinn

    Wenn ich also – wie das GUI – mit dem Benutzer DMXCDefault arbeite, sollte ich doch eigentlich auf dieselben Daten zugreifen können, oder?

    Also erst einmal zum UserContext selbst: Ja, wenn du mit dem selben UserContext wie eine GUI arbeitest, dann kannst du auf die entsprechenden Daten aus diesem UserContext zugreifen. Das sind u.a. die ausgewählte Geräte und Gerätegruppen, die entsprechenden Executoren, der ausgewählte Timecode und zukünftig noch ein paar mehr Funktionen. Aktuell arbeiten alle GUIs tatsächlich mit dem DMXCDefault UserContext, weil das der aktuell automatisch generierte Default-User ist. Allerdings wird sich das mittelfristig ändern. Dann ist geplant, dass es wirkliche User inkl. Userverwaltung gibt, die man anlagen kann und die dann gewisse Rechte haben. Dann wirst du auch bei dir eine Userauswahl einbauen müssen. Das aber wie gesagt mittel- bis langfristig. Aktuell kannst du mit dem DMXCDefault UserContext arbeiten.

    Quote from SvenFinn

    Dabei bin ich auf das Feature MacroBoardProxy gestoßen. Verstehe ich es richtig, dass man damit softwareseitig eigene MacroBoards registrieren kann?

    Ja, du kannst damit eigene MacroBoards registrieren. Der Punkt hier aber ist: Das "Proxy" im Namen sagt es schon. Hier geht es um MacroBoards, die an einer der GUIs (oder eben an deiner Applikation) angeschlossen sind. Dementsprechend werden dann alle Befehle für ein MacroBoard auch an die jeweilige GUI (und nur dort hin) geschickt. Die GUI ist dann praktisch der Proxy für die Daten des MacroBoards, denn die Verwaltung und Steuerung geschieht ja im Kernel. Daher kannst du deine MacroBoards auch nicht direkt in den GUI-Einstellungen der DMXControl 3 GUI sehen. Aber du solltest ein von dir registriertes MacroBoard im Input Assignment finden können. Dort sollte es wie mein StreamDeck in den entsprechenden Ordnern links auftauchen. Außerdem solltest du ein solches MacroBoard in den Einstellungen des MacroBoard Wrapper Nodes finden können.

    Damit kannst du dann auch die Verknüpfung zwischen dem jeweiligen MacroBoard und MacroBoard Profil machen. Hilft das schon?

    Viele Grüße
    JP

    im Falle eines Falles klebt Gaffa einfach alles, denn Gaffa ist dein Freund und Helfer :thumbup:

    Edited 2 times, last by JPK (October 25, 2025 at 10:30 PM).

    Wenn man die viele "Schalt-Zauberei" lieber extern erledigen möchte (also bevor sie DMXC erreicht), ist "Bome Midi Translator" sehr zu empfehlen. Ich nutze Bome, um mit bis zu ca. 10 Midi-Controllern wahlweise DMXC zu steuern oder VoiceMeter oder Reaper oder OBS oder oder oder. Der dafür erforderlichen Berechnungen werden alle in Bome geschrieben - es ist super komplex aber auch unendlich kraftvoll, wenn es um die Manupulationen / Veränderung von Midi-Nachrichten geht.

    Als Beispiel:

    U.a. nutze ich zwei Akai APC40MKii - einer ist Nummer 1, einer ist Nummer 2.

    Ich kann aber dem Einser per Knopfdruck sagen, dass er nun der Zweier ist - also ein funktionaler Zwilling zu seinem Bruder.

    Zusätzlich haben bei bis zu acht Bedienungslayer - vier davon habe ich für DMXC reserviert, die anderen für die Steuerung der anderen Programme.

    Alles hängt von der Umrechnung der Noten und Kanäle ab.

    Hallo JPK,

    vielen Dank für deine Erklärung.
    Ich habe die MacroBoardProxies nochmal ausprobiert und festgestellt, das dass DMXControl 3.3.1 - GUI solche Änderungen nicht sofort mit zu kriegen scheint. Ich musste das GUI jedes mal neu starten, damit der MacroBoardProxy im Input Assignment als Macro Board aufgetaucht ist. Ähnlich ging es mir auch bei den Attachables, die auch erst nach längerer Zeit oder nach einem Neustart im Effects and Filters Menü aufgetaucht sind.

    Ich habe mich jetzt dazu entschieden, erstmal eine Library für DMXControl zu schreiben, die sich um das Verbindungszeugs, etc. kümmert. Dazu hab ich jetzt angefangen, für die einzelnen Clients Wrapper zu schreiben, damit die leichter zu bedienen sind. Die grpc-library für TypeScript ist nämlich ziemlich umständlich. Ich habe mich jetzt erstmal mit den CueLists beschäftigt und hätte dazu ein paar Fragen:

    Die Anfrage "CueListClient.insertSpecialCue" braucht ein Feld "specialEnum", das laut Protobuf-Definition aus einem Enum gecastet wird. Dieser Enum ist im Interface aber nicht beschrieben. Hast du mir vielleicht die Defintion von dem Enum, damit ich auch die Methode passend implementieren kann?

    Ebenfalls wollte ich Fragen, was die "getPropertyValues" Funktion im CueListClient genau macht? Bei meinen bisherigen Tests hat diese immer nur einen leeren Array geliefert.

    Zu guter letzt habe ich mich an der "getCuelistProgress" versucht, die meldete aber nur "No cuelist is currently running", obwohl ich teilweise mehrere CueLists laufen hatte. Mach ich da was falsch?

    Ich würde diesen Thread erstmal weiter verwenden, um meine Fragen anzubringen :)

    Vielen Dank schonmal für die Hilfe :)
    Fabian