MIDI-Controller im Eigenbau – Ein Baubericht

  • Vor Kurzem habe ich ein größeres Projekt fertiggestellt, dass ich euch hier gerne vorstellen möchte.



    Als Info vorab: Viele relevante Informationen, die für die Kommunikation mit dem Kemper nötig sind, habe ich durch Beiträge in diesem Forum und durch die umfangreiche Kemper MIDI-Dokumentation erhalten. Auf technische Funktionsweisen gehe ich nicht tiefer ein, da ich mich in der Beschreibung auf die generelle Entwicklung beschränken will. Zudem ist der Prototyp in erster Linie auf meine persönlichen Anforderungen und Präferenzen zugeschnitten.


    20180826-IMG_9365.jpg

    Warum überhaupt?

    Was wäre, wenn ein MIDI-Controller für den KPA mit nur einem Kabel, Anschlüsse für mehrere Expression-Pedale und vielen Tastern, günstig in der Anschaffung wäre? Ich hätte mich wahrscheinlich nie mit der Programmierung von Mikrocontroller, Aufbau von MIDI-Nachrichten und PCB-Design beschäftigt.


    Auf der Suche nach einer für mich passenden Lösung, den KPA live und im Proberaum zu steuern, bin ich an technische Grenzen gestoßen. Einerseits wollte ich einen möglichst einfachen und robusten Controller mit möglichst vielen Tastern, um eindeutige Belegung zu ermöglichen und nicht zwischen den Songs (oder sogar mittendrin) diese ändern zu müssen, zum anderen wollte ich einen einfachen und schnellen Aufbau ermöglichen. Meiner Erfahrung nach musste ich feststellen, dass Steckdosen, vor allem am vorderen Bühnenrand, meist Mangelware sind. Daher hatte eine Phantomspeisung ebenfalls eine hohe Priorität.


    Zunächst habe ich ein Diezel Columbus benutzt. Dieses Board wird praktischerweise mit nur einem 3pol. XLR-Kabel angeschlossen. Um dieses dann mit dem KPA zu verbinden, habe ich eine Konverterbox von prostage benutzt, die MIDI out und Strom an das Columbus weitergibt. Doch 10 Presets, die mir durch das Columbus per direkten Zugriff zur Verfügung standen waren mir zu wenig. Also habe ich mir die weiteren Produkte von prostage genauer angesehn, aber mit dem Wechsel zu einem proprietären Protokoll, das die neuen Boards verwenden, war für mich nichts Interessantes dabei und wirklich günstig sind diese auch nicht.


    Also dann selber bauen. Viele Taster, Strom über Phantomspeisung, vielleicht ein bis zwei Anschlüsse für Expression-Pedale und nur ein Kabel... wird ja nicht so schwierig sein.

    Wie baut man sich sowas selbst?

    Im Rahmen meines Studiums habe ich mit dem Bau dieses Prototyps begonnen. Zuvor hatte ich kleine Sachen mal gelötet, die beschränkten sich aber mehr auf: Hier mal eine wacklige Klinkenbuchse an der Gitarre oder ein Stecker an ein Kabel dran. Einen Mikrocontroller (MCU) wie einen Arduino hatte ich vor dem Projekt nie in der Hand, geschweige denn programmiert.

    Unabhängig von der Auswahl der MCU war bereits zu Beginn klar, dass die zur Verfügung stehenden digitalen Eingänge nicht für alle Taster (und was sonst da noch kommen mag) reichen würden. Lösung: Shiftregister.

    Um den Zustand der Taster des Prototypes mit Leds anzuzeigen, sind wieder sehr viele Pins erforderlich. Durch den Einsatz von Led-Driver war dieses Hindernis schnell beseitigt.

    Als Nächstes stand MIDI in und MIDI out auf der Agenda. Nachdem ich verstanden hatte wie ein Optokoppler funktioniert und warum dieser überhaupt benötigt wird, habe ich eine “MIDI-zu-XLR” Box mit Spannungsversorgung gebaut. Aufseiten der Programmierung ist dies durch Libraries eine Sache von ein paar Zeile Code, um beispielsweise ein Presetwechsel am KPA auszulösen.




    20151113-IMG_9791.jpg


    Um ein Gefühl für die Dimensionen des späteren Boards zu bekommen und als Basis für die weitere Entwicklung, baute ich einen zweckmäßigen Holzprotypen. Mit diesem konnte ich schnell erkennen, welche Displaygröße benötigt wird, um alle Informationen lesebar darzustellen.

    Leider musste ich feststellen, dass hier die Auswahl nicht so groß ist. Ein Display, das nur über ein parallel-Interface verfügt, konnte direkt ausgeschlossen werden, da dieses viel zu viel Pins an der MCU belegen würde. Ein zeichenbasiertes Display ist bei diesem Einsatz äußerst beschränkt in der Möglichkeit Informationen darzustellen und die meisten 128x64px grafischen LCDs sind eben nur mit parallelem Interface zu haben. Wenn man keine Zeit investieren will, um nicht auch noch einen Display-Controller in Gänze zu verstehen, beschränkt sich die Auswahl der Displays auf die für die bereits eine Arduino kompatible Library existiert. Schließlich wurde ich bei buydisplay.com fündig. Für das auf dem RA8875 Controller basierende 4,3” TFT-LCD Display mit SPI-Interface wurde von sumotoy eine passende Library geschrieben.


    20151219-IMG_9995.jpg20151208-IMG_9887.jpg


    Spätestens nach der Umstellung auf RGB-Leds, die zur Statusanzeige der Taster dienen, war die Platine und die Verbindungen zwischen den Komponenten nicht mehr so leicht zu überblicken. Da aus Sicht der Hardware alles funktionierte (zumindest zum damaligen Kenntnisstand) habe ich mit dem ziemlich einfach zu handhabenden Tool fritzing eine Platine erstellt und produzieren lassen. Nur um kurze Zeit später festzustellen, dass die verwendete MCU einfach nicht den Speicheranforderungen genügt. Kurzum habe ich einen Adapter gebaut, um den jetzt verwendeten Teensy 3.2 auf dieser ersten Version der PCB verwenden zu können. Diese MCU hat gegenüber des Arduino Nanos nicht nur deutlich mehr Speicher (Flash: 32kB < 256kB & RAM: 2kB < 64kB) sondern auch eine deutlich höhere Taktrate (16MHz<96MHz).


    20161030-IMG_1827.jpg


    Mit dem Wechsel auf eine PCB nahm das Projekt konkreter Gestalt an und ich ließ mir für ein Metallgehäuse eine Wanne falzen. Um Geld zu sparen, habe ich die weitere Bearbeitung per Hand erledigt, dabei musste ich feststellen wie widerstandsfähig 2mm Stahl ist.


    20151223-IMG_0033.jpg


    Da ich auf dem Display des Controllers vom KPA kommende Informationen (wie z.B. den Tuner) darstellen wollte, wurde auch die Programmierung immer aufwändiger. Daher wechselte ich von der eher rudimentären Arduino “IDE” zu Visual Studio in Kombination mit vMicro, um komfortabler den stetig wachsenden Code zu handhaben. Zeitgleich wurde klar, dass die bereits produzierte PCB Mängel im Design aufwies (bspw. keine Decoupling-Capacitors). So entwarf ich mit Hilfe von KiCad eine als Shield ausgelegte PCB, die direkt hinter das Display “Huckepack” platziert werden konnte. So konnte ich die Länge des SPI-Busses zwischen MCU und Display auf ein Minimum reduzieren und zudem entfiel ein weiteres Kabel. Durch den festgelegten Formfaktor und meinem Entschluss Vias sowie Drahtbrücken zu vermeiden, war ich gezwungen größtenteils SMT Komponenten zu verwenden. Da KiCad eine recht umfangreiche Software zum Erstellen von PCB’s ist, brauchte ich eine Zeit mich in diese einzuarbeiten. Doch dieser Wechsel war absolut zwingend, da das bisher verwendete Programm fritzing mit dem Platinenlayout absolut an die Leistungsgrenzen war und die Möglichkeiten beispielsweise Leiterbahnen in KiCad zu (re-)organisieren deutlich einfacher ist. Anschließend habe ich das Design bei der sehr zu empfehlenden Firma Aisler produzieren lassen. Super Qualität, direkter Kontakt und schnelle Produktionszeiten #notsponsored ;).

    20181130-181001_poc_board_front_anginv_raytracing.jpg20181130-181001_poc_board_back_ang_raytracing.jpg

    20180825-IMG_9355.jpg


    Um die jetzt bidirektionale MIDI-Verbindung zu überwachen, verwendete ich meine externe Soundkarte und die Software MIDI-OX. Dadurch ist es möglich zu überwachen was der Prototyp in Richtung KPA sendet und was der KPA darauf zurückgibt. Leider musste ich feststellen, dass das Regeln der Kommunikation nicht ganz so einfach ist. Auch eingehende Nachrichten können mal fehlerhafte Bits enthalten, die zu schwerwiegenden Fehler in Programmablauf führen können. Daher müssen die eingehenden Nachrichten auf Plausibilität geprüft werden und falls nötig auch verworfen und neu angefordert werden.


    Nachdem alle Basisfunktionen implementiert waren, kümmerte ich mich verstärkt um die Entwicklung einer Bedienoberfläche. Um ein geradliniges Bedienkonzept weiterhin einzuhalten, entschied ich mich auf der Rückseite des Controllers einen Encoder mit integriertem Taster (“Endlospoti”/Drehknopf) zu montieren. Durch Halten dieses gelangt man ins Menü und durch das Drehen navigiert man sich hindurch. Im Menü selbst können z. B. Tastenbelegungen geändert werden und beim Verlassen des Menüs werden die gemachten Änderungen permanent auf einem EEPROM gespeichert. Dadurch, dass sich die Expression-Pedale, falls welche angeschlossen sind, ständig neu kalibrieren werden, sind hierzu keine Einstellungen weiter nötig.


    20180822-IMG_9348.jpg



    Abschließend kann mal wohl sagen, dass dieser DIY MIDI-Controller doch sehr viel teurer geworden ist und deutlich länger in Entwicklung war als anfangs gedacht. Aber wie andere sich selbst eine Gitarre bauen oder so manch einer ein erhebendes Gefühl verspürt nach dem Aufbau seines ersten IKEA Regals, so hab ich am Ende etwas, was wie ein Maßanzug sitzt.


    Ich freu mich über Kommentare oder Anregungen :)

  • Wow, excellent job !

    Deinem Abschlußkommentar stimme ich voll und ganz zu. Ich hab selber schon einen Tweed Twin und einen Deluxe Reverb Klone gebaut und mußte abschließend feststellen das man einfach Lehrgeld bezahlt. Von der Zeit ganz abgesehen sind - wie bei jedem Projekt - die letzten 5% die, welche viel Zeit und/oder Geld kosten. Ich hab die Dinger dann getuned mit Speakern und Übertragern und dann hat das Ergebnis gepasst und meine Erwartungen getroffen.

    Jetzt bin ich beim KPA gelandet als Universallösung für all meine Saiteninstrumente. Ich glaube nicht das die Equipmentreise schon am Ende ist, aber die "KPA Etappe" dauert bis jetzt jedenfalls sehr lange und ich habe kein Verlangen nach Alternativen. Mit dem KPA Fusschalter bin ich wegen des Tasterabstands nicht ganz zufrieden. Die Features passen für meine Ansprüche außer der Loopersamplezeit locker. Das hast du bei deiner DIY Remote deutlich besser gelöst! Respekt!

  • Hallo mreit,


    erstmal großes Lob. Da ich selber etwas ähnliches vor habe, hätte ich ein paar Fragen. Wo hast du die Infos über die Kommunikation her? Vor allem die Daten für den Tuner würden mich interessieren. Über CC31 ein und ausschalten geht, aber ich bekomme keine Daten zurück vom Kemper.

  • Tolle Arbeit! Ich hatte mich auch schon mal damit beschäftigt aber dann aus Zeitmangel und Kenntnisstand aufgegeben.
    Interessant wäre dann wirklich einmal: Bauzeit, Kosten und ein Vergleich zur Kemper Remote.

    Und ganz toll wäre natürlich Material zum Nachbau: Bauteilliste, Programmcode und Schaltplan.
    Aber das ist natürlich viel Zeitaufwand wenn es das noch nicht gibt.

    Nochmal: Tolles Projekt!