Systemintegration mal anders: Der Klang des RD-1000 als Embedded Appliance
Wie wird aus einer Software-Emulation ein eigenständiges Instrument, das man einfach einschaltet und spielt? Dieser Frage gehe ich in meinem ersten Ausflug in die Linux-Audioprogrammierung nach.
KI unterstützt mich dabei als Werkzeug beim Erkunden und Ordnen der technischen Fragen.
Der Klang des RD-1000
Das Roland RD-1000 ist der klangliche Bezugspunkt für dieses Projekt: ein Stagepiano mit für seine Zeit ungewöhnlicher digitaler Klangerzeugung. Mit 43 Kilogramm ohne Stativ und Gebrauchtpreisen, die ich dafür nicht ausgeben würde, ist das Original für mich keine praktische Option.
Vor vielen Jahren habe ich mir deshalb ein MKS-20 zugelegt: die 19-Zoll- Rackversion mit derselben Klangerzeugung. Mit rund sieben Kilogramm ist sie deutlich leichter. Heute steht es auf dem Dachboden und zeigt sein Alter. Nach fast vierzig Jahren bräuchte es eine umfassende Wartung. Alte Elektronik ist nicht nur ein nostalgisches Thema: Bauteile altern, und nicht alles lässt sich auf Dauer sinnvoll reparieren.
Die Sample-Emulationen, die ich bisher kannte, kamen für mein Ohr nicht nah genug an den Klang des RD-1000 heran.
Rolands Structured/Adaptive Synthesis, kurz S/A-Synthese, beschreibt einen Ton nicht als eine einzige lange Aufnahme. Stattdessen setzt die Klangerzeugung kurze Wellenformen für den Anschlag und periodisch wiederholte Wellenformen für das Ausklingen zusammen. Der Klang soll auf das Spiel reagieren, statt nur eine starre Aufnahme wiederzugeben. Anders als beim Physical Modeling werden dafür keine physikalischen Saiten berechnet, sondern vorbereitete digitale Klangbausteine kombiniert.
Tonhöhe und Anschlagstärke beeinflussen, welche dieser Anteile hörbar werden und wie ihre Hüllkurven - also Ein- und Ausblenden - verlaufen. Ein stärkerer Anschlag macht den Ton daher nicht nur lauter, sondern verändert auch Attack und Obertonspektrum. Daraus entsteht die ausgeprägte Dynamik des RD-1000.
Ein kurzer Blick zurück
Roland stellte das RD-1000 und das MKS-20 1986 gleichzeitig vor. Das Stagepiano und die 19-Zoll-Rackversion teilen sich die S/A-Klangerzeugung; das MKS-20 war damit eine praktische Alternative für Studios und Keyboard-Setups, in denen bereits eine passende Tastatur vorhanden war. Zeitgenössische Tests beschrieben die beiden Geräte als eigenständigen Ansatz zwischen den damals verbreiteten Digitalpianos und Samplern.
Das MKS-20 war in unzähligen Keyboard-Racks zu sehen und zu hören. Auch Elton John setzte RD-1000 und MKS-20 in den späten 1980er Jahren ein. Teils standen die Geräte als eigenständiges Piano im Vordergrund, teils als durchsetzungsfähige Schicht im Mix mit anderen Piano- und Keyboardklängen. Das erklärt vielleicht, warum der Sound für viele nach Achtzigern klingt, ohne auf einen einzelnen Hit reduzierbar zu sein.
RdPiano als Ausgangspunkt
Als ich auf Giulio Zausas RdPiano-Projekt stieß, war ich sofort begeistert: endlich keine weitere Sample-Library mehr. Statt aufgezeichnete Klavierklänge nachzuspielen, bildet RdPiano die digitale Klangerzeugung der historischen Instrumente in Software nach.
Im RD-1000 sitzt diese Klangerzeugung auf der CPU-B-Platine. Ihr zentraler Baustein ist ein Hitachi HD63701Y0, ein 8-Bit-Mikrocontroller aus der Motorola-6800-Familie. Er führt die Firmware aus dem Programm-ROM aus und greift auf RAM, Parameter-ROM und drei kundenspezifische Fujitsu-Gate-Arrays zu. Über Speicheradressen steuert die Firmware diese Soundchips; sie erzeugen den digitalen Klang aus den Klangdaten und den Steuerdaten des Instruments.
RdPiano emuliert diesen Aufbau: die HD63701Y0-CPU mit ihrem erweiterten 6800-Befehlssatz, die Speicherbereiche und die Soundchips. Giulio Zausa leitete die Logik der nicht dokumentierten Gate-Arrays aus Siliziumaufnahmen ab und überführte sie in Verilog-Modelle. Verilog ist eine Hardwarebeschreibungssprache für logische Bausteine und ihre Verbindungen.
Zausa hat RdPiano als Open Source veröffentlicht, unter anderem als VST-Plugin und in Varianten mit SDL. Mich interessierte deshalb weniger die fertige Plugin-Variante als eine Systemintegrationsfrage: Wie weit lässt sich der Aufbau reduzieren? Was braucht es wirklich, damit die Emulation im Userspace knapp oberhalb des Linux-Kernels direkt an ALSA hängt und als eigenständiges Instrument läuft: MIDI rein, Audio raus, einschalten und spielen?
Ein erster Host ohne grafische Oberfläche
Aus dieser eingangs formulierten Frage ist ein noch unveröffentlichter Proof of Concept entstanden. Mein ALSA-Host nimmt MIDI direkt über den ALSA-Sequencer entgegen und gibt das Audio direkt über ALSA PCM aus. Ein Plugin-Host, JUCE, SDL und eine grafische Oberfläche sind dafür nicht nötig. Der Host verbindet die beiden Standard-Schnittstellen: eingehendes MIDI und ausgehendes PCM-Audio.
ALSA steht für Advanced Linux Sound Architecture. Im Linux-Kernel stellt es Treiber und ein einheitliches Modell für Soundkarten, USB-Audiointerfaces und MIDI-Geräte bereit. Darüber liegt eine Userspace-Bibliothek, über die Programme auf diese Funktionen zugreifen.
Für Audio liefert ALSA mit PCM einen kontinuierlichen Strom von Sample-Puffern an ein Ausgabegerät. Der ALSA-Sequencer verteilt MIDI-Ereignisse wie Note On, Note Off oder Program Change zwischen Geräten und Programmen. Mein ALSA-Host nutzt beide Schnittstellen direkt: Er empfängt MIDI vom Keyboard und schreibt die berechneten Audiodaten an das Interface.
Der Experimentieraufbau funktioniert bereits an meinem Laptop: Mein Yamaha CK88 liefert MIDI über seinen USB-MIDI-Ausgang, ein Steinberg-USB-Audiointerface übernimmt die Ausgabe. Es ist noch ein Versuchsaufbau. Aber wenn ich am CK88 eine Taste anschlage und ohne DAW der vertraute Klang aus den Lautsprechern kommt, fühlt es sich schon erstaunlich nah an einem Instrument an.
Im Kern bleibt die Aufteilung überschaubar:
- Die Emulation erzeugt den Klang der historischen Instrumente.
- Eine Engine verwaltet ROMs, Sounds, Effekte und die gewählte Performance.
- Der schlanke Host verbindet MIDI und Audio mit ALSA.
Doppelte Polyphonie als praktische Lösung
Ein originales RD-1000 hat 16 Stimmen. Das genügt für vieles, kann bei gehaltenen Akkorden und Sustain aber knapp werden. Genau an dieser Grenze entstand beim Testen ein Problem, das zunächst ganz anders aussah.
Bei den ersten Tests gab es gelegentliche Aussetzer, selbst mit einer nahezu Echtzeit-Priorität für den Prozess. Das wirkte zunächst wie ein Latenz- oder Scheduling-Problem. Bei genauerem Hinsehen lag die Ursache jedoch bei der Polyphonie: Wenn mehr Noten angefordert werden als Stimmen verfügbar sind, muss das Instrument entscheiden, welche laufende Stimme beendet wird. Diesen Vorgang nennt man Voice Stealing.
Die zweite MCU-Bank war dafür die praktische Lösung. Mit 32 Stimmen kommt die Emulation im Test deutlich seltener in diese Situation. Die Aussetzer verschwanden, und dichteres Spiel mit Sustain wird angenehmer.
Technisch startet die Engine dafür zwei unabhängige Instanzen der 16-Stimmen-Emulation und verteilt neue Noten auf die weniger ausgelastete Bank. Das ist keine hardwaregetreue Erweiterung. Der Klangpfad jeder einzelnen Bank bleibt jedoch unverändert, während die verfügbare Polyphonie steigt.
Damit der Aufbau wie ein Instrument wirkt
Auch Performances gehören für mich dazu. Ein Programmwechsel am Keyboard soll einen vorbereiteten Klang auswählen, statt dass ich am Rechner Einstellungen zusammensuchen muss. Eine TOML-Datei trennt deshalb musikalische Einstellungen von den Eigenschaften des Aufbaus: Sound, Stimmung und Effekte gehören zur Performance; Audio-Gerät, Puffergröße und MIDI-Kanal bleiben global. Sie prüft Namen, Werte und Zuordnungen vor dem Start. Das ist keine spektakuläre Funktion, aber genau solche Kleinigkeiten lassen einen Aufbau später eher wie ein Instrument wirken.
Vom Laptop zum Instrument
Der Laptop ist ein guter Anfang, aber nicht das Ziel. Für meine Smart-Home- Zentrale baue ich bereits Buildroot-Systeme für einen Raspberry Pi. Deshalb möchte ich als Nächstes herausfinden, ob ein Raspberry Pi 4 für diese Emulation genug Leistung und eine brauchbare Audiolatenz bietet.
Der geplante Aufbau wäre bewusst schlicht: Das Yamaha CK88 liefert MIDI per USB an den Raspberry Pi. Dort laufen Buildroot, der ALSA-Host und die Emulation. Das Steinberg-USB-Audiointerface übernimmt anschließend die Verbindung zu Kopfhörern oder Lautsprechern. Noch ist das ein Zielbild, nicht das Ergebnis eines abgeschlossenen Leistungstests.
Falls das funktioniert, wäre der nächste Gedanke sehr reizvoll: ein maßgeschneidertes Instrument, etwa ein MIDI-Keyboard mit eingebautem Raspberry Pi, das beim Einschalten direkt als vollständige RD-1000- oder MKS-20-Emulation bereitsteht. Nicht als Ersatz für ein historisches Original, sondern um seinen Klang im Alltag robuster und einfacher zugänglich zu halten.
Bis dahin bleiben wichtige Fragen offen: Reichen die Reserven unter Buildroot? Bleiben MIDI und Audio unter Last zuverlässig? Wie fühlt sich die Latenz beim tatsächlichen Spielen an? Der jetzige Aufbau beantwortet das noch nicht.
Er zeigt aber, dass der Gedanke nicht nur auf Papier funktioniert. Für den Moment ist das genug: ein funktionierender Aufbau, ein klarerer technischer Weg und ein guter Grund, in der Werkstatt weiterzumachen.