DX7 Details des Chips im DX7

Faszinierend, ein Blick in ein anderes Digitalzeitalter. Heute gilt FM als ein eher CPU-effizientes Syntheseverfahren - 1983 musste man noch alles tun, um Audio-Multiplikationen zu vermeiden!

Angewandte Mathematik: Anstatt zwei Audiosignale zu multiplizieren, werden sie adidiert (was um ein Vielfaches weniger aufwendiig ist), worauf diese Summe einer Exponentialfunktion zugeführt wird. Diese Funktion wird dann durch simples Auslesen einer Wertetabelle ("table lookup") umgesetzt.

Dass die eigentliche Phasenmodulation, hier FM genannt, durch (unterschiedlich schnelles) Auslesen einer Sinus-Wertetabelle gelöst wird, wusste ich ja schon.

Was mir aber neu ist: Offenbar werden die 96 Operatoren (16 Stimmen a 6 OPs) abwechselnd, also nacheinander, abgearbeitet. Und das Berechnen der jeweiligen Phasenlage ist wiederum getrennt von der Erzeugung der Sinustöne

Und im Ergebnis hat das alles nicht nur funktioniert, sondern es war auch noch alltagstauglich und hochmusikalisch - Chapeau to Mr Chowning and the Yamaha team :)
 
Zuletzt bearbeitet:
Faszinierend, ein Blick in ein anderes Digitalzeitalter. Heute gilt FM als ein eher CPU-effizientes Syntheseverfahren - 1983 musste man noch alles tun, um Audio-Multiplikationen zu vermeiden!

Angewandte Mathematik: Anstatt zwei Audiosignale zu multiplizieren, werden sie adidiert (was um ein Vielfaches weniger aufwendiig ist), worauf diese Summe einer Exponentialfunktion zugeführt wird. Diese Funktion wird dann durch simples Auslesen einer Wertetabelle ("table lookup") umgesetzt.

Dass die eigentliche Phasenmodulation, hier FM genannt, durch (unterschiedlich schnelles) Auslesen einer Sinus-Wertetabelle gelöst wird, wusste ich ja schon.

Was mir aber neu ist: Offenbar werden die 96 Operatoren (16 Stimmen a 6 OPs) abwechselnd, also nacheinander, abgearbeitet. Und das Berechnen der jeweiligen Phasenlage ist wiederum getrennt von der Erzeugung der Sinustöne

Und im Ergebnis hat das alles nicht nur funktioniert, sondern es war auch noch alltagstauglich und hochmusikalisch - Chapeau to Mr Chowning and the Yamaha team :)
Das mit der Wertetabelle finde ich äusserst interessant!
Auf solche Lösungen muss man erstmal kommen, sehr pragmatisch.

Manchmal sieht man, gerade als Ingenieur, die einfache Lösung im Wald vor lauter Bäumen nicht.
 
LUTs wurden viel genutzt in den 70er/80er und auch noch teilweise 90er, für alles mögliche, also immer da wo man Multiplikationen(auch Sinus usw) vermeiden wollte/musste, da diese sehr viele Taktzyklen fraßen. Diese Technik war eigentlich auch schon Assembler Programmieranfänger recht schnell geläufig. Früher war der Speicher im Verhältnis zur CPU noch sehr schnell, heute ist das RAM extrem langsam, weswegen unter anderem eine Multiplikation in der CPU schneller ist, als in den LookUpTables im Speicher rumzuschrubben, wenn dieser nicht gerade gecached wurden. Dann kommen heute auch noch Erweiterungen der CPU zum Einsatz wo man z.B. mehrere Multiplikationen in einem Rutsch erledigen kann usw.
Hier mal eine Tabelle was das Verhältnis der Geschwindigkeit von Speicher und Prozessor im Laufe der Jahre zeigt.

Part6-CPU-and-RAM-speeds.jpg
 
Soweit ich weiss liegen die internen Cachespeicher bei aktuellen AMD GPUs im Terrabyte Bereich von der Geschwindigkeit her. Externe Speicheranbindung sind immer langsamer.
 
Muss man dann abwiegen was mehr bringt, dafür zur Sorgen dass man viele Cachehits hat, was ganz und gar nicht trivial ist oder doch die CPU rechnen lassen. Auf jeden Fall sollte man Speicherzugriffen meiden, wo es nur geht, denn die sind sau langsam. Da war früher anders, weswegen man auch völlig anders optimiert hat. Wie gesagt die Daten die man gerade braucht im Cache zu halten ist wirklich nicht einfach. Im schlimmsten Falle muss die ganze Software Architektur so gestaltet sein, damit möglichst viel mit den schnellen Caches der CPU gearbeitet werden kann. Das passiert ja nicht automatisch, wenn viel hin und her gesprungen und gewerkelt wird, mit den Daten, muss sich der Cache immer wieder neu füllen, was viel Zeit kostet.
Da gibt es heute extra Algorithmiker für, die nix anderes tun als zu versuchen so eine CPU so gut es geht zu nutzen in Punkto Cache, Multicore usw. So ist es jedenfall bei allen Anwendungen wo es zeitkritisch wird, auf ein Button Klick zu reagieren gehört sicher nicht mehr dazu.
 
Auf jeden Fall sollte man Speicherzugriffen meiden, wo es nur geht, denn die sind sau langsam. Da war früher anders, weswegen man auch völlig anders optimiert hat. Wie gesagt die Daten die man gerade braucht im Cache zu halten ist wirklich nicht einfach. Im schlimmsten Falle muss die ganze Software Architektur so gestaltet sein, damit möglichst viel mit den schnellen Caches der CPU gearbeitet werden kann.
Das klingt plausibel, auch wenn ich von Programmierung zu wenig verstehe.

Beachte aber, dass Yamaha die FM-Operatoren damals gerade nicht auf einer CPU berechnet hat. Das Auslesen der Tabellenwerte wurde von spezialisierter Hardware, dem erwähnten FM-Chip, erledigt, weil eine damalige CPU damit um Größenordnungen überfordert war.

Mich würde mal interessieren, welcher Universalrechner im Jahr 1983 leistungsfähig genug gewesen wäre, den DX7 in Echtzeit zu simulieren. Vermutlich hätte man eine Cray-X-MP gebraucht :)
 
Zuletzt bearbeitet:
LUTs wurden viel genutzt in den 70er/80er und auch noch teilweise 90er, für alles mögliche, also immer da wo man Multiplikationen(auch Sinus usw) vermeiden wollte/musste, da diese sehr viele Taktzyklen fraßen. Diese Technik war eigentlich auch schon Assembler Programmieranfänger recht schnell geläufig. Früher war der Speicher im Verhältnis zur CPU noch sehr schnell, heute ist das RAM extrem langsam, weswegen unter anderem eine Multiplikation in der CPU schneller ist, als in den LookUpTables im Speicher rumzuschrubben, wenn dieser nicht gerade gecached wurden. Dann kommen heute auch noch Erweiterungen der CPU zum Einsatz wo man z.B. mehrere Multiplikationen in einem Rutsch erledigen kann usw.
Hier mal eine Tabelle was das Verhältnis der Geschwindigkeit von Speicher und Prozessor im Laufe der Jahre zeigt.

Anhang anzeigen 125415
Da fällt mir noch ein - Synths nutzen heute oft kleine Arm Prozessoren der mitteleren Art, also Cortex A4 - mal etwas mehr, aber selten annähernd so wie zB irgendwelche iPhones neuerer Generation.
Auch Raspberry Pi und Microcontroller sind nicht selten heute - dh - Yamaha hat damals Custom machen KÖNNEN und sie konnten HiTech machen - beides findet nach meiner Beobachtung faktisch nicht mehr statt. Die Rechner sind also oft schnell genug, aber weit hinter dem wie ein Mac oder Pc das könnten.

Das ist ein echter Nachteil für HW Angebote heute - allerdings muss man auch sagen, dass sehr viele Syntheseverfahren nur in den 70/80ern zu wenig Power hatten, heute aber oft genug Rechenpower bekommen.

Nicht mal mehr Korg würde heute einfallen die Resonanz wegzulassen, weil die HW das nicht packt (haben sie mit der Wavestation gemacht). Man lässt heute Aftertouch und MIDI Thru weg - kostet 7€ bzw 1-2€. Scheint sich für ne Serie zu lohnen.

Das aber nur nebenbei als Abgleich - Yamaha war auch schon eine der wenigen Firmen, die echte eigene sehr leistungsstarke Baugruppen selbst herstellten. Custom Knöpfe, Displays und so hingegen waren nicht so selten.

Deine Aufstellung hat einen Knick bei 2004/2005 - was etwa stimmen könnte - wenn man allein Apples M1 und ARM Verlauf auch vor dem M1 mit nimmt wären das Welten drüber. Würde dann noch dazu nehmen, dass Mehrkern für Audio noch immer nicht jeder hinbekommt - deshalb sind das meist heute 1-Kern Teile.
alles weit weit kleiner als das was technisch "machbar" ist - selbst wenn man direkt Kunde bei einem ARM Outlet wäre oder vergleichbar.

So gesehen haben wir alle eine mehrfache Cray in der Tasche.
 
Danke für die Ergänzung. Mir ging es nur darum zu zeigen warum die LUTs heute unter Umständen eher hinderlich sind als hilfreich(je nach Komplexität der Berechnung), jetzt mal unabhängig von der jeweiligen Architektur. Von der Leistung heute leben wir in einem Schlaraffenland im Gegensatz zu früher, aber wissen auch gut sie zu verballern, damit auch 4K auf einem Daumennagel noch genug Power bekommen 😅
Im Energie verbrauchen sind wir ja Weltmeister, allen schon ständig mit unseren Bildschirmen gegen das Sonnenlicht ankämpfen ist völlig daneben, aber die E-Ink Technologie ist leider noch nicht schnell genug. Aber 80% Akkuenergie für den Kampf gegen das Umgebungslicht zu verballern ist echt traurig.
Der M1 macht das schon toll mit er Energieeffizienz und andere werden folgen, das ist so sicher wie das Amen in der Kirche.

Ok ich werde zu Offtopic hier.
 
Mich würde mal interessieren, welcher Universalrechner im Jahr 1983 leistungsfähig genug gewesen wäre, den DX7 in Echtzeit zu simulieren. Vermutlich hätte man eine Cray-X-MP gebraucht.
Nicht zu vergessen die Programmiersprachen und Entwicklungstools. C++ wurde erst 1983 eingeführt. Die Dexed-Entwickler nutzten eine Library von Google, sprich die haben ein Grundgerüst gekriegt. Das hätte man den frühen 80ern alles selbst entwickeln müssen und Softwareentwicklung steckte noch in den Kinderschuhen.
 
Nicht zu vergessen die Programmiersprachen und Entwicklungstools. C++ wurde erst 1983 eingeführt.
Den Vorgänger "C" gibts schon seit Anfang der 70er, also daran hat das sicher nicht gelegen oder man hat wie beim Synclavier einfach 'ne eigene Entwicklungsumgebung geschaffen.
 
Das hat weniger mit der Programmiersprache zu tun als mit der reinen Rechenleistung. Selbst mit Assembler war Ende der 80er mit einem Amiga500 gerade mal reines summieren 4x2 8 Bit Soundkanälen in Assembler möglich, daraus wurde dann der Oktalyzer. Ich würde sagen erst ab Pentium konnte man so langsam was in Echtzeit gebacken bekommen.
 
Ich würde sagen erst ab Pentium konnte man so langsam was in Echtzeit gebacken bekommen.
Ich habe 1995/1996 meinen 486er mit der ersten Version von Generator (0.96 Beta oder so) gequält. Die Minimoog Emulation hat es auf eine Stimme gebracht. Sound lief noch über eine spezielle Karte ohne Windows-Treiber.
 


News

Zurück
Oben