FM-Synthese (3) – … back to the drawing board

Der finale Schritt zu dritten Evolutionsstufe des FM-Projektes war getan – und meine Computer komplett überfordert. Die gefundenen Lösungen haben universellen Charakter, sollen aber speziell am kommenden FM-C erläutert werden. Eine kleine PreView inclusive.

Um was wird es gehen?

Mit etwas Übung sind tolle Ideen in Reaktor recht schnell umgesetzt. Dabei verliert man schnell aus den Augen, welche Rechenleistung man am Ende abruft – bis der Computer protestiert. Dann heißt es: entweder die Ansprüche herunterschrauben, oder Lösungen finden, um das gewünschte trotzdem zum Laufen zu bekommen.

In diesem Tutorial möchte ich euch drei wichtige Tipps an die Hand geben, den Leistungshunger eurer Reaktor-Konstrukte (zum teil erheblich) reduzieren können. Bei der Gelegenheit bekommt ihr schon mal einen Einblick in die kommende und finale Version der FM-Tutorials.

Zuvor…

… aber erst einmal einen kurzen Blick auf das Schema der beiden bestehenden FM-Synthesizer (FM-A und FM-B) und auf das, für den FM-C geplant ist.

FM A

Wir beginnen mit dem FM-A. Ihr erinnert euch? wir begannen mit zwei FM-Sinus-Oszillatoren, die jeweils eine Hüllkurve zur Verfügung hatten. Der Frequenzeingang des linken Oszillators (Modulator) wurde durch einen Drehknopf geregelt, der Frequenzeingang des rechten (Träger), durch das Ausgangssignal des Modulators. Der Verstärker zwischen den beiden Oszillatoren sorgte für eine Regelbarkeit der Modulation. Die „langweilige“ und obertonlose Sinuswelle des Trägers erhält so jede Menge interessanter Obertöne und kann nun brauchbare E-Pianos, Bässe, Flächen und vieles mehr hervorbringen.

FM B

Soviel passierte in diesem Schritt eigentlich nicht. Die Oszillatoren bekamen 3 zusätzliche Wellenformen (Dreieck, Rechteck und Sägezahn) und ließen sich nun oktavieren, transponieren und feinstimmen. Die Hüllkurve wurde leistungsfähiger und die Frequenzeinstellung des Modulators aufwändiger. Sowohl die Frequenzregelung als auch der Verstärker wurden durch einen LFO (Sinus und Zufall) modulierbar, deren Modulationsverlauf jeweils mit einer Hüllkurve regelbar.

FM C – ein Blick in die Zukunft

Das sieht jetzt erheblich komplizierter aus, als es ist. Im Prinzip hat hier eine enorme Vereinfachung stattgefunden. Es entbehrt nicht einer gewissen Tragik, dass sich diese so schwer darstellen lässt.

Doch der Reihe nach:

• Ausgangspunkt der Überlgung ist folgender: Bei den bisherigen Modellen hatten wir immer eine Kombination aus Träger und Modulator. Würde man die Anzahl der Klangerzeuger erweitern wollen, hätte man folglicherweise weitere Kombinationen aus Trägern und Modulatoren.
• Träger und Modulator sind aber bis auf einen einzigen Punkt identisch: Die Frequenz des Modulators kann explizit eingestellt werden, die des Trägers wird vom Modulator bestimmt.
• Was wäre, wenn man aus den zwei Elementen eines macht (nennen wir es der Einfachheit halber „Operator“), das beide Fähigkeiten erbt: Die explizite Reglung der Frequenz und die Modulation durch einen (oder viele) weitere(n) Operator(en)?

Wer nun (nicht zuletzt durch den Begriff) „Operator“ an den legendären Yamaha DX7 oder oder den FM8 von Native Instruments denkt, ist auf der richtigen Spur! Unser FM-C wird dem DX7 voraus haben, dass es keine festgelegte Anzahl an Verschaltungen gibt. Mit der Komplexität und Leistungsfähigkeit des FM8 werden wir andererseits nicht mithalten können – aber der spielt softwaretechnisch auch in einer ganz anderen Liga…

Abb. 3 könnt ihr entnehmen, wie das ganze funktionieren soll:

• Die Nummerierten Blöcke (z. B. 1 [grün]) stellen jeweils einen Operator dar. Zusätzlich zur Hüllkurve, bekommt jeder Operator noch einen schicken Filter zu seite gestellt.
• Jeder Operator hat nun soviele Modulationseingänge wie es weitere Operatoren gibt, einen Modulationseingang für sich selbst (Feedback) und zu guter letzt einen für die Frequenz (damit hatte ja alles begonnen).
• Schließlich kann jeder Operator durch jeden anderen Operator, durch sich selbst und durch eine Frequenz moduliert werden.
• Jeder dieser Modulationseingänge wird durch einen LFO mit Hüllkurve beeinflusst.

Nicht im Bild: die Ausgänge der Operatoren durchlaufen eine Lautstärke- und Panormaregelung und danach verschiedene Effekte, deren Funktionsweise ich in späteren Tutorials erklären werde

Das gezeigte Beispiel ist auf 3 Operatoren limitiert. der FM-C soll derer 8 Stück bekommen!

Was ist passiert?

Meine Vorstellung umfasste 8 Operatoren, eine Glide-Schaltung, einen Resonanz-EQ, Chorus, Delay und Reverb, wobei ich die drei letzt genannten Effekte so simpel wie mögliche gestalten wollte (s. 80th Synth-Brass). Nachdem ich den ersten Muster-Operator komplett hatte, vervielfältigte ich ihn in der angestrebten Menge, verband alles miteinander … und war dann recht ernüchtert.

An dieser Stelle kurz einen Einblick in die verwendete Hardware und die Konsequenzen meiner Bastelei::

iMac (Retina 5K, 27″, 2020)

CPU: 3,8 GHz 8-Core Intel Core i7
RAM: 32 GB 2667 MHz DDR4
GPU: AMD Radeon Pro 5500 XT 8 GB

• bei einer Samplerate von 44100Hz (also systemüblich), verweigerte der iMac seinen Dienst (CPU Overload)
• bei einer reduzierten Samplerate von 33075Hz (3/4) schrammt man ständig zwischen 90% Auslastung und nervös blinkendem „Overload“ hin und her.
• erst bei einer halbierten Samplerate von 22050Hz pendelt sich die Belastung um die 60% ein und man kann spielen – mit den der Samplerate geschuldeten Einbußen an der Audioqualität.

Wichtig! Zum Zeitpunkt dieses Blogbeitrags läuft Reaktor nativ nur auf Intel-Hardware

MacbookPro (Liquid Retina XDR 16″, 2021)

CPU: M1 Pro. 10‑Core CPU, 8 Performance- und 2 Effizienz-Kerne
RAM: 32 GB im SoC integriert, 200 GB/s Speicher­bandbreite
GPU: 16‑Core GPU
KI:16‑Core Neural Engine

• bei einer Samplerate von 44100Hz (also systemüblich) reagierte auch das Macbook Pro mit einem CPU Overload, was Angesichts der Software-Emulation (s. unten) nachvollziehbar ist
• bei einer reduzierten Samplerate von 33075Hz (3/4) ist aber eine stabile 80%ige Auslastung vorhanden. Eine nervös blinkende „Overload“-Meldung bleibt aus. Trotz Emulation 10% mehr Reserve.
• bei einer halbierten Samplerate von 22050Hz liegt die Belastung um die 50%, also ebenfalls 10% besser, als auf dem iMac.

Wichtig! Zum Zeitpunkt dieses Blogbeitrags läuft Reaktor nicht nativ auf  Apple-Silicon-CPUs. Die Anwendung wird zur Laufzeit von einem Dynamic Binary Translator (Rosetta2) blockweise übersetzt.

Zuerst freundete ich mich mit einem erheblichen Downsizing an: 3 Operatoren, alles Mono. Eine FM-C SE (Special Edition) also. Den steckte der iMac mit 70% (und ab und an aufblinkendem CPU Overload) bei 44100Hz weg. Das Macbook Pro meisterte diese Herausforderung mit der bekannten 10%igen Reserve, also bei ca. 60%. Das konnt es aber nicht sein.
Schließlich kannte ich weitaus komplexere Reaktor-Basteleien, die nicht so rabiat an der CPU zerrten. Also investierte ich ein Wochenende und ging der Sache auf den Grund. Hilfreich hierbei ist eine Debug-Einstellung des Reaktors, mit der man die CPU-Last verschiedener Module erfahren kann:

• Options > Debug Structure > Measure CPU Usage

Bei eingeschalteter Option ist zwar keine Tonausgabe mehr möglich, dafür werden aber im Fußbereich von Modulen und Macros, anstelle ihres Namens, die CPU-Last in % auf hellgrünem Hintergrund eingeblendet. Wie erwartet waren die Operatoren die Hauptverantwortlichen, weshalb ich mir einen davon nahm, in ein neues Ensemble setzte, dortselbst eine Kopie seiner selbst anfertigte und an letzterer Stück für Stück optimierte, bis am Schluß ein unterschied zwischen 14% (wie bisher) und 1% (optimiert) bestand.

Was wird nun passieren?

Anhand von drei Optimierungen werde ich euch zeigen, wie ihr Rechenleistung freistellt und damit entweder den Computer entlastet, oder Reserven für Neues schafft.

Multiplizieren statt dividieren.

Ein Thema, das unter Softwareentwicklern kontrovers diskutiert wird. Je nach Entwicklungsplattform übernehmen das die Compiler* bei der Optimierung des Codes von alleine. In unserem Fall wird das jedoch vom Reaktor Handbuch explizit vorgeschlagen. Lesen hilft hier tatsächlich:

14.6 Use Multipliers Instead of Dividers
Division is a more expensive process for a CPU to handle than a multiplication. For example, it would be a lot more efficient to multiply by 0.5 rather than divide by 2, even though the result is the same. (Native Insruments, Reaktor-Manual „Building in Primary“)

Zugegeben: Divisionen kommen beim FM-Synthesizer nicht so oft vor, aber Kleinvieh macht auch Mist. Ein effizientes Beispiel zeige ich euch in der folgenden Abbildung. Eine Schaltung, die als „Nebenprodukt“ zu den FM-Tutorials angefallen ist. Mehr dazu werdet ihr in einem künftigen Tutorial zum Resonanz-EQ erfahren. Soviel sei verraten: es geht darum, mit einer Reglerbewegung ein RGB-Lamp Modul von einer RGB-Farbe in eine andere umzublenden. RGB-Farbwerte liegen in der Regel zwischen 0 und 255 pro Farbe vor, die RGB-Lamp im Reaktor erwartet aber Werte zwischen 0 und 1. Aus diesem Grund werden die 6 Eingangswerte (R-, G-, B-Startwert, R-, G-, B-Endwert) durch 255 geteilt, bzw. hier mit 0,00392157 multipliziert. Die Anzahl der Nachkommastellen hängt davon ab, wie genau das Ergebnis an eine „normale“ Division komm soll.

*Compiler: Eine Anwendung im Rahmen der Softwareentwicklung, die ein in einer Hochsprache geschriebenes Programm so übersetzt, dass es von der CPU direkt ausgeführt werden kann.

Monophon statt polyphon

Hier kann richtig Rechenpower gespart werden. Nicht alle Signale müssen zwingend polyphon, also mehrstimmig sein. Monophone Module erkennt ihr an einer einzelnen Note in einem orangen Rechteck, polyphone an einer doppelten Note in einem gelben Rechteck; jeweils rechts unten auf dem Modul.

In Abb. 5 sind zwei Schaltungen zu sehen. Auf der linken Seite monophon und auf der rechten Seite polyphon. Die obere Schaltung dient der Ansteuerung eine Anzeige im Interface des Synthesizers. Hier gibt es absolut keinen Grund, polyphone Signale zu verarbeiten. Eine LED zeigt nicht „mehrstimmig“ an. Abgesehen davon, ist das LED-Modul selbst monophon und benötigt bei polyphoner Ansteuerung einen zusätzlichen Audio Voice Combiner.
Die untere Schaltung stellt die Frequenzregelung des Oszillators dar. Hier wird eine Zahl erzeugt, die dem Frequenzeingang des Oszillators zugeführt wird. Auch dieser Wert bedarf keiner Mehrstimmigkeit. Das gilt ebenso für den LFO (Macro links unten in der Schaltung), die den Wert der erzeugten Zahl variiert.

Wo immer keine Notwendigkeit besteht, mehrere Stimmen zu verarbeiten, können die Schaltungen monophon ausgeführt werden. Das reduziert die Anforderungen an die CPU merklich.

Design

Der Punkt, der in diesem Projekt die meiste Rechenleistung gefressen hat, war die Art und Weise, wie ich Zahlenwerte im Interface dargestellt habe. Er zeigt in bestechender Weise, dass die eleganteste, coolste Lösung nicht immer die beste ist. Aber der Reihe nach: 

Grafik/Design ist die Stärke von Reaktor nicht. Hier ist das Programm in den 90ern der letzten Jahrhunderst steckengeblieben. Das macht sich besonders auf großen Monitoren mit hohen Auflösungen bemerkbar. Responsivität fehlt gleich ganz.
Wer mehr als die mitglieferten Elemente benötigt, braucht eine gute Portion Erfahrung im Umgang mit Photohop, oder einen guten Anbieter fertiger Elemente. Erfahrung mit dieser Materie habe ich zwar (s. meine Photoshop-Tutorials auf be-sign.net), aber neben be-sign.net und unterrichten meist nicht die Zeit, dafür. Deshalb habe ich in diesem Zusammenhang immer wieder auf UI-Mother als hilfreichen Dienstleister hingewiesen.

Knöpfe, Fader, Displays, Gehäuse, ect. waren hier nicht mein Problem Was mich störte, war die Ausgabe von Zahlenwerten. Hier gibt es in Reaktor nicht viel Spielraum. Knöpfe und Fader besitzen eine deaktvierbare Option, ihre Werte im charme eines 80jahre Taschenrechners auszugeben. 6 Pixel hoch. Mehr ist nicht. Für andere Ausgaben gibt es das sogenannte Numeric Readout, dessen darstellende Künste mit denen der Regler und Fader identisch sind: Keine Schriftgröße, Farbe und keinen Schriftschnitt.
Will man mehr, bedarf es eines Multitext Moduls. Das ist aber leider keine eine Anzeige (wie z. B. das Numeric Readout), sondern eine dröge Liste, die je nach anliegendem Wert, ein gespeichertes Listenelement von sich gibt.
In Abbildung 6 kann man einen Knopf-Definition mit dem Wertebereich 0 – 5000 und einer Schrittgröße in Zehntel sehen. Eine typische Situation für den F-Eingang eines FM-Oszillators. Daneben die Darstellung des Knopfes selbst mit der eigenen Pixelschrift-Ausgabe und eine erheblich besser lesbare Ausgabe, die mit dem Multitext Modul erstellt wurden.

So ein Multitext Modul lässt sich nun in zweierlei Art nutzen. Die eine ist etwas mühsamer und recht unflexibel, muss das Modul doch für jeden Regler mit spezifischen Werten gefüllt werden. Die andere nutzt etwas Mathematik, um eine universelle Lösung zu schaffen. Schauen wir und die beiden Möglichkeiten genauer an:

Individuelles Befüllen (linke Hälfte Abb. 7): Ein Wertebereich von 0 – 5000 in Zehntelschritten erfordert 50000 (in Worten Fünzigtausend) Einträge in das Multitext Modul. Keine Frage: das macht man nicht manuell. Dazu bemüht man eine Tabellenkalkulation, exportiert das Ergebnis als CSV-Datei, benennt diese in eine TXT-Datei um und importiert sie in das Multitext Modul. Hierdurch wird die Reaktor-Datei um 379KByte größer.

Mathematik (rechte Hälfte Abb. 7): Das feine Macro „Values Splitter“ hatte ich in der Vergangenheit schon mal als hilfreich erwähnt. Das ist es auch durchaus – solange man nicht zu viele davon beschäftigt! Wie man sehen kann, ist das Macro auf Core-Ebene programmiert. Es zerlegt die eingehenden Werte (z. B. eines Reglers) in ihre Zehnerpotenzen und reicht die Bruchstücke an Multitext Module weiter, die mit den Werten 0 – 9 gefüllt sind. Ferner kümmert es sich um ein evtl. Vorzeichen.
Wer in [02] aufgepasst hat, dem ist sicher nicht entgangen, dass dieses Macro mit 20(!) Divisoren vollgestopft ist. Selbst wenn man die Zweige, die man nicht benötigt, aus dem Macro entfernt, ist dessen CPU-Bedarf nicht unter 0,3% zu drücken.

und jetzt wird es spannend!

Angenommen wir rechnen zu Gunsten des Macros und nehmen dauerhafte 0,3% CPU-Leistung an. Dann ergibt sich bei 41 Macros pro Operator und 4 Operatoren ein Leistungsbedarf von knapp 50%. Nur für die bequeme Typographie. Das ist nicht lustig.

Abb. 8 zeigt einen Snapshot der Macros in der Envelope eines Operators. Alleine hier laufen schon 2,5% CPU-Last auf.

Manchmal

… lässt sich die eine oder andere smarte Lösung nicht vermeiden. In dem vorliegenden Fall ist ein Multi-Text Modul ja auch kein Ausbund an Flexibilität. Bleibt noch eine Option: Das Ausdünnen der Schaltung.
Im untenstehenden Beispiel sind nur 3 Ausgänge des Value Splitters belegt. 10 Ziffern-Ausgänge und der +/- – Ausgang sind – samt deren innenliegenden Komponenten – belegen völlig sinnfrei dringend benötigte Rechenleistung. Alle in der untenstehenden Abbildung blau markierten Bauteile lassen sich also entfernen.

Nach dem operativen entfernen unnötiger Komponenten ist eine Menge Platz (und Rechenpower) frei geworden. Ein Rechtsklick und aus dem Kontextmenü „Compact Board“ ausgewählt, schon ist alles schön aufgeräumt. Im Fall des FM-C hat das knapp weitere 10% Rechenleistung frei gemacht. 

Fazit

Wird die Luft zum Rechnen knapp, setze man entweder auf eine zeitgemäße CPU (z. B. Apple Silicon) oder man optimiert die Schaltungen anhand der drei folgenden Regeln:

• Divisionen durch multiplikationen ersetzen.
• Polyphone Objekte nur dann nutzen, wenn es nötig ist.
• Smarte Lösungen in Form von Macros, die Arbeit abnehmen, wollen dafür in Rechenleistung bezahlt werden. Das muss man einkalkulieren.
  • … oder man legt Hand an und dünnt die smarten Lösung so weit wie möglich aus.

Its Magic

Der FM-C ist mittlerweile auf der Ziellinie angekommen. folgendes ist jetzt möglich:

• 8 Stimmen, 8 Operatoren
• Jeder Operator verfügt über 5 Wellenformen, Hüllkurve, Multi-Filter, eine Modulationsmatrix mit 9 Eingängen und jeweils einem LFO mit Hüllkurve. Ferner eine Begrenzung der Tastaturbreite, einer Startverzögerung (wahlweise in Millisekunden oder Notenlängen und einem Glide-Modul.
• Die Effektsektion gebietet über einen resonanzfähigen EQ (nach dem Vorbild des Resonant-Serge-EQ), einem Ringmodulator, Chorus, Delay und Reverb. Die Effekte (ausser dem EQ) lassen sich wahlweise seriell oder parallel schalten.
• Das Stereopanorama lässt sich modulieren.

Noch muss sich der iMac (Intel i7) mit 3/4 der internen Audio-Qualität (33075 Hz) zufrieden geben. Die Anzeige pendelt zwischen 72% und ab und an aufblinkender roten Warnleuchte.
Das Macbook Pro (Apple Silicon M1 Pro) meistert die Herausforderung mit dauerhaft unter 50% Auslastung – und wir erinnern uns: Reaktor ist noch nicht nativ auf dessen CPU angepasst.

Just heute hat Apple den M1 Ultra vorgestellt. Man darf gespannt sein 😉