Hat sich hier jemand schon mal mit dem Yamaha YM2151 von 1984 befasst? https://en.wikipedia.org/wiki/Yamaha_YM2151 Ich bin vor kurzem darauf gestoßen und erstaunt, was der Chip schon alles konnte. Der YM scheint eine Sinustabelle zu beinhalten. Da würde mich mal interessieren, wie groß die Auflösung sein muss, dass man diese Qualität erreicht: https://www.youtube.com/watch?v=qWhhVkbgbRM
Christoph M. schrieb: > Hat sich hier jemand schon mal mit dem Yamaha YM2151 von 1984 befasst? Ich jedenfalls nicht. > Der YM scheint eine Sinustabelle zu beinhalten. Davon kann man wohl ausgehen. > Da würde mich mal > interessieren, wie groß die Auflösung sein muss, dass man diese Qualität > erreicht: Sehr wahrscheinlich maximal 2kbit Speicher. Wie das dann auf temporal/spatial aufgeteilt ist: keine Ahnung.
>Sehr wahrscheinlich maximal 2kbit Speicher.
2kBit=2^11 .. bei 8 Bit Amplitude währen das 2^3 + 2^8 .. also 256
Tabelleneinträge.
Christoph M. schrieb: > Der YM scheint eine Sinustabelle zu beinhalten. Man braucht ja nur 1/4 der Sinuswelle zu speichern. Hälfte ist ja eh invertiert. Nach der ersten 1/4 muss man einfach die Tabelle rückwärts auslesen.
Christoph M. schrieb: > Der YM scheint eine Sinustabelle zu beinhalten. Da würde mich mal > interessieren, wie groß die Auflösung sein muss, dass man diese Qualität > erreicht: Naja, so 8-16 Bit, müsste man halt mal ausprobieren. Die Datenbusleitung vom Chip früher war 8 Bit breit. Hinsichtlich der Qualität kam es auch ein wenig auf die Programmierkunst (meist Erfahrung) an und auf die Verschaltung der "Operatoren", den "FM-Algorithmen".
Der Chip ist quasi eine Weiterentwicklung/Reduktion des DX-7. Da waren das mehrere Chips. Dafür hat der DX-7 mehr Operatoren/Stimme und doppelt so viele Stimmen. Es gibt eine Seite die ziemlich gut die Funktionsweise des DX-7 erklärt: https://www.righto.com/2021/11/reverse-engineering-yamaha-dx7.html
Ein 10-seitiges Datenblatt von 1991 gibts im Webarchiv: https://archive.org/details/YM2151/page/n1/mode/2up
:
Bearbeitet durch User
Andreas M. (amesser) 15.07.2025 14:06 >Der Chip ist quasi eine Weiterentwicklung/Reduktion des DX-7. Da waren >das mehrere Chips. Dafür hat der DX-7 mehr Operatoren/Stimme und doppelt >so viele Stimmen. >Es gibt eine Seite die ziemlich gut die Funktionsweise des DX-7 erklärt: > https://www.righto.com/2021/11/reverse-engineering-yamaha-dx7.html Ah sehr gut, so was hat mir gefehlt.
1 | DX7 used two custom chips: the YM21290 EGS "envelope" chip generated frequency and envelope data, which it fed to the YM212805 OPS "operator |
Interessant .. die Seriennummber YM2151 is ja viel kleiner als die YM21290 und YM212805. Der YM2151 läuft aber auch nicht alleine, sondern braucht noch den 16Bit DAC YM3012.
Schon seit einigen Jahren gibt es Signalprozessoren, die trigonometrische Funktionen in wenigen (z.B. 3-4) Zyklen berechnen können. Damit kann die Anzahl der Operatoren und deren Verschaltung um einiges gesteigert, und auch mit anderen Methoden der Klangerzeugung kombiniert werden. FM klingt sonst irgendwie immer nach FM. Wenn man nicht gerade ein historisches Artefakt besitzt, dass einen YM2151 beinhaltet, ist es wohl sinnvoller sich ein wenig umzusehen.
Cartman E. schrieb: > FM klingt sonst irgendwie immer > nach FM. Naja, wenn ich so einen OPL nehme, dann will ich ja FM. Klar kann man mit genügend Operatoren auch andere Klangfarben erzeugen. Dann kann ich aber auch gleich Wavetable, Subtraktiv oder mit Granular Synthese machen. Der Nachteil an FM ist halt die Komplexität der Konfiguration. Was ich damit meine sieht man ganz gut am DX-7 Programmer: https://www.dtronics.nl/dt-7 Christoph M. schrieb: > Der YM2151 läuft aber auch nicht alleine, sondern braucht noch den 16Bit > DAC YM3012. Im DX-7 ist der DAC auch extern. Da wird ziemlich viel getrickst. Das ist 12 Bit DAC, dessen Ausgang dann nochmal durch einen schaltbaren Teiler geht. Darüber werden dann alle 16 Stimmen im Zeitmultiplex ausgegeben. Der DAC läuft mit 768kHz. https://www.righto.com/2022/02/yamaha-dx7-chip-reverse-engineering.html
Andreas M. (amesser) 15.07.2025 14:06 >Es gibt eine Seite die ziemlich gut die Funktionsweise des DX-7 erklärt: > https://www.righto.com/2021/11/reverse-engineering-yamaha-dx7.html Die Chips sind wirklich interessant. Da Multiplizierer ziemlich viel Chipfläche brauchen, hat man in dem Chip die Multiplikationen nach dem Prinzip "Rechenschieber" durch Addition der logaritihmischen Werte ersetzt. Hier wäre interessant, wie der "log2 sine" genau kodiert ist.
1 | |
2 | One ROM computes the log2 sine for the waveform. The chip has two identical exponential ROMs computing 2x. One converts the log-frequency increment value into a linear increment value. The second converts the log waveform value into a linear waveform value. |
Andreas M. schrieb: > Der Nachteil an FM ist halt die Komplexität der Konfiguration. Der eigentliche Nachteil ist, dass es für eine gewünschte Klangfarbe keinen einfach deterministischen Algorithmus gibt, die Operatorkonfiguration und deren Parameter zu bestimmen. Da hilft nur ein wenig Erfahrung und Intuition im Umgang damit. Aber der Nachteil bleibt eben doch. Und ein Instrument, dass nur FM kann, würde ich auch nicht wollen. Das mag bei dir ja anders sein. Die technisch sicherlich interessanten Verenkungen muss man sich jedenfalls heute nicht mehr antun. Multiplizieren geht bei Signalprozessoren gewöhnlich in einem Zyklus. Manche schaffen sogar mehrere Multiplikationen per Zyklus. Und den Sinus gibts in 3 bis 4 Zyklen.
Christoph M. schrieb: > Hier wäre interessant, wie der "log2 sine" genau kodiert ist. Der Schreiber hat sich mehrfach mit dem DX-7 auseinandergesetzt, alle Beiträge findet man über die "Site information" bzw. Index. Hier der Beitrag zum Log2Sine: https://www.righto.com/2021/12/yamaha-dx7-reverse-engineering-part-iii.html Es gibt auch eine ziemlich genaue Nachbildung in Software wo man viel nachlesen kann: https://asb2m10.github.io/dexed/ Cartman E. schrieb: > Multiplizieren geht bei Signalprozessoren gewöhnlich in einem Zyklus. > Manche schaffen sogar mehrere Multiplikationen per Zyklus. > Und den Sinus gibts in 3 bis 4 Zyklen. Ich beschäftige mich gerade zufällig mit dem Thema. Ich baue gerade einen 4-OP Synth mit etwas Inspiration vom DX-7 in einem FPGA. Ich möchte allerdings nicht nur Sinus sondern verschiedene Wellenformen mit Überblenden dazwischen. Je nachdem wieviel Platz noch ist dann noch ein bis zwei Filter hinter die Oszillatorsektion. Mein Problem ist eher das der FPGA zu schnell ist, für die Envelopes brauche ich jetzt schon 40 Bit damit ich bis auf 20s Attack/Decay/Release komme.
Andreas M. schrieb: > Mein Problem ist eher das > der FPGA zu schnell ist, für die Envelopes brauche ich jetzt schon 40 > Bit damit ich bis auf 20s Attack/Decay/Release komme. Das kann man mit einem Gleitkommaformat sehr einfach abbilden. Z.B. 8 bit Exponent und 8 bit Mantisse. Das reicht sowohl für den gewünschen Gesamtwertebereich als auch eine angemessene Genauigkeit des zeitlichen Ablaufs. Wird das Zeitraster hörbar zu grob, kann man ja recht aufwandsarm interpolieren.
Cartman E. schrieb: > Das kann man mit einem Gleitkommaformat sehr einfach abbilden. > Z.B. 8 bit Exponent und 8 bit Mantisse. Das reicht sowohl für > den gewünschen Gesamtwertebereich als auch eine angemessene > Genauigkeit des zeitlichen Ablaufs. Ja das stimmt. Das hatte ich mir auch überlegt. Aber bisher sind meine VHDL Kenntnisse noch nicht so gut. Ich will mich in die ganze Thematik überhaupt erstmal reinarbeiten. Im Moment benutze ich IEEE.fixed_pkg. Hab aber gerade gesehen, das es das gleiche auch für floats bereits fertig gibt. Mal sehen ob ich darauf umschwenke.
Andreas M. schrieb: > Cartman E. schrieb: >> Das kann man mit einem Gleitkommaformat sehr einfach abbilden. >> Z.B. 8 bit Exponent und 8 bit Mantisse. Das reicht sowohl für >> den gewünschen Gesamtwertebereich als auch eine angemessene >> Genauigkeit des zeitlichen Ablaufs. > > Ja das stimmt. Das hatte ich mir auch überlegt. Aber bisher sind meine > VHDL Kenntnisse noch nicht so gut. Ich will mich in die ganze Thematik > überhaupt erstmal reinarbeiten. Im Moment benutze ich IEEE.fixed_pkg. > Hab aber gerade gesehen, das es das gleiche auch für floats bereits > fertig gibt. Mal sehen ob ich darauf umschwenke. Es ist nur das Format. Arbeiten kann man damit auch mit Bitvektoren.
Andreas M. (amesser) 15.07.2025 16:36 >Ich beschäftige mich gerade zufällig mit dem Thema. Ich baue gerade >einen 4-OP Synth mit etwas Inspiration vom DX-7 in einem FPGA. Mit FPGAs zu spielen ist sehr schön, weil man da z.B. einen Sigma-Delta-Wandler direkt implementieren kann, was auf einem Mikrocontroller eher umständlich ist. Allerdings ist es auch recht aufwändig, ein FPGA zu programmieren und meiner Einschätzung nach ist der Zeitaufwand mindestens Faktor 5 mehr um eine Projekt zu realisieren. Meiner Erfahrung nach ist es so: - FPGA Zeitaufwand x5 - Mikrocontroller sind heutzutage sehr schnell und viele Algortihmen lassen sich damit realisieren - FPGAs sind für die Tonerzeugung zu schnell und man landet sehr schnell bei Mikrosequenzerarchitekturen, die Blöcke mehrfach verwenden. - Verwendet man keine Mikrosequenzer, ist das FPGA schnell voll. Sieht am man Beispiel hier: Beitrag "Re: VHDL Grundlagen Tonerzeugung" Ein Starting-Point zur Tonerzeugung mit VHDL ist hier: Beitrag "Re: VHDL Grundlagen Tonerzeugung"
Cartman E. schrieb: > Das kann man mit einem Gleitkommaformat sehr einfach abbilden. > Z.B. 8 bit Exponent und 8 bit Mantisse. Das reicht sowohl für > den gewünschen Gesamtwertebereich als auch eine angemessene > Genauigkeit des zeitlichen Ablaufs. Ich hab darüber jetzt mal nachgedacht und komme nicht dahin das Gleitkomma hier weiterhilft. Ich verwende für die Hüllkurve die Formeln für ein R/C Glied, so wie man es in analogen Synths hat:
(xt ist der Zielwert, also bei Attack hier 1.3, bei Decay 0-1 und bei
Release 0.0) Schon bei ~10ms Attack ist k kleiner als 1/1000 während x_i
Größenordnung 1 ist. Die Summanden liegen damit um so viele
Größenordnungen ausseinander, das sich die Addition in x_{i+1} gar nicht
niederschlagen kann. Welchen Algorithmus schlägst Du dafür vor?
Christoph M. schrieb:
> Meiner Erfahrung nach ist es so:
> - FPGA Zeitaufwand x5
> - Mikrocontroller sind heutzutage sehr schnell und viele Algortihmen
> lassen sich damit realisieren
> - FPGAs sind für die Tonerzeugung zu schnell und man landet sehr schnell
> bei Mikrosequenzerarchitekturen, die Blöcke mehrfach verwenden.
> - Verwendet man keine Mikrosequenzer, ist das FPGA schnell voll. Sieht
> am man Beispiel hier:
Ja der Zeitaufwand ist höher, aber das spielt hier keine Rolle, weil
mich damit ja beschäftigen will. Mit der Rechenleistung sehe ich das
etwas anders. Meine Aktuelle Umsetzung hat 64 Stimmen a 4 Operatoren
(=256 Oszillatoren und Hüllkurven). Das Ganze bei ~160kHz Samplerate. Da
wirds mit den üblichen Mikrocontrollern schon arg eng. Und viel Platz
braucht das auch nicht. Von der Architektur her habe ich das als
Pipeline umgesetzt, so wie im DX-7. Das scheint auch der übliche Ansatz
für Datenverarbeitung im FPGA zu sein. Belegt sind im Moment gerade mal
~3%. Midi ist da auch schon mit drinnen, man kann den Synth schon
spielen. Im Moment bin ich gerade dabei SysEx für die ganzen Parameter
umzusetzen.
Ich fand das gar nicht so einfach hier etwas vorschlagmäßiges zu schreiben. Yamaha selber hatte ja auch eine schöne Evolution mit FM. (und mein Liebling ist nach wie vor ARM + DSP - OS noch nicht ganz klar) Bei FPGA hat man u.a. auch noch die Spannungsfrage, ganz abgesehen von der Speicherfrage. Ein problematischer Aspekt ist auch: die FPGA-Synths klingen oft sehr flach. Oder hören sich einfach flach an, weil es halt ein bekannter Sound ist. Aber kann das sein? Der wahre Grund, warum analoge Aufnahmen besser sind https://www.youtube.com/watch?v=Zq4BOSaKiYo Zur Orientierung fand ich (für mich) diese Power-Point-Show von TI ganz gut: https://www.ti.com/europe/downloads/Choose%20the%20right%20data%20converter%20for%20your%20application.pdf Am meisten Spaß hatte damals der Minimoog gemacht, der hat nur eine Stimme ;) Darüber hinaus kann man immer "LA-Synthese" machen - bzw. konnte Windows mit dem FM-Synth schon GM, was man vielleicht auch im Hinterkopf haben könnte. Ich meine aber nicht GM mit FM, sondern mit den aktuellen Möglichkeiten die man hat(te). Klingt(klang) ja auch deutlich besser. (https://en.wikipedia.org/wiki/General_MIDI) .. Naja, und wenn der Zusammenhang passt: Whigfield - Saturday Night (Official Video) https://www.youtube.com/watch?v=8DNQRtmIMxk https://www.reddit.com/r/synthesizers/comments/8u4gew/saturday_night_whigfield_remake_yamaha_tx81z/
Christoph M. schrieb: > - FPGAs sind für die Tonerzeugung zu schnell Das ist nun eine etwas uninspirierte Ansicht. Andreas M. schrieb: > x_{i+i} - x_{i} = k*(x_T - x_{i}) > [/math] > > (xt ist der Zielwert, also bei Attack hier 1.3, bei Decay 0-1 und bei > Release 0.0) Schon bei ~10ms Attack ist k kleiner als 1/1000 während x_i > Größenordnung 1 ist. Die Summanden liegen damit um so viele > Größenordnungen ausseinander, das sich die Addition in x_{i+1} gar nicht > niederschlagen kann. Welchen Algorithmus schlägst Du dafür vor? Probleme löst man, in dem man sie in kleinere Probleme aufteilt. In den Teil der Stützwerte erzeugt, und den Teil der aus diesen Stützwerten dann final den Koeffizienten für die Hüllkurve berechnet. Ob letzterer nun 27 bit oder 48 bit Vektorwortbreite braucht, ist offensichtlich relativ egal. Du solltest vielleicht die ganze Rechnerei lassen, und versuchen das Ganze als digitales Schaltwerk zu verstehen und zu entwerfen. Etwa so, als wenn man das tatsächlich mit einzelnen ICs aufbauen müsste. Von den Stellen mal abgesehen, wo man wirklich rechnen muss.
Angehängte Dateien:
-
ym2151_envelope.png
100 KB
Andreas M. (amesser) 16.07.2025 09:25 >Ich hab darüber jetzt mal nachgedacht und komme nicht dahin das >Gleitkomma hier weiterhilft. Ich verwende für die Hüllkurve die Formeln >für ein R/C Glied, so wie man es in analogen Synths hat: So richtig klar wird mir aus dem Referenzmanual nicht, ob die Hüllkurve linear oder in der Tiefpassform implementiert ist. Der SID-Chip des C64 macht es linear, wenn ich es richtig weiß. Ob die Unterschiede gravierend hörbar sind wäre die Frage. Im Anhang habe ich noch ein Matlab-Script, um die Hüllkurve linear zu visualisieren.
Christoph M. schrieb: > So richtig klar wird mir aus dem Referenzmanual nicht, ob die Hüllkurve > linear oder in der Tiefpassform implementiert ist. Wozu soll jetzt eine Tiefpassform gut sein? Bei den Analogen hat der Filter eine eigene Hüllkurve. Bei den Casios gab es eine extra CPU für den Filter. Bei FM ist das ein wenig anders - aber man kann einen Teil in einem Modularsynth nachbauen. Bei FM wird eben viel moduliert ganz nebenbei bemerkt ;) Probier das z.B. mit dem "Filter FM" auf alle Fälle ein paar mal bzw. gut (bis zum Abwinken) aus. What is Filter FM an how to Sound Design with it? https://www.youtube.com/watch?v=3bC793UJFA0 bzw. Waveforms & Filter Effects | FM Synthesis Explained 2 https://www.youtube.com/watch?v=kUAv9h9O-lU oder besorge dir auch einen richtigen FM-Synth, so hast du eine gute zusätzliche Referenz.
Bei Yamaha ist die Hüllkurve implizit exponentiell. Die Hüllkurve selbst wird linear gerechnet, wird dann aber auf das logarithmische Sinussignal addiert bevor dieses durch den log2lin Konverter geht. Dadurch ist der Decay/Release wie bei einem Analogen Synth, der Attack aber exponentiell. Da das Gehör logarithmisch arbeitet passt das gut.
Andreas M. schrieb: > Bei Yamaha ist die Hüllkurve implizit exponentiell. Danke für die Erklärung. Yamaha fing ja früh an mit der digitalen Synth-Welt, so ist wohl auch jede Menge Know How darin eingeflossen. Hier noch ein Video mit John Chowning zur FM: John Chowning "Origins of FM Synthesis" (Web 85) https://www.youtube.com/watch?v=w4g92vX1YF4 (hatte ich fairerweise hier gefunden: https://articles.roland.com/ultimate-guide-fm-synthesis/ ) (Bert Marx, der war in den 90ern Product Manager bei Roland, der hatte auch mal in Braunschweig E-Technik studiert.) (hier ist noch ein etwas längeres Video, war in der Asso, scheint auch nicht schlecht zu sein - https://www.youtube.com/watch?v=tpysRrYXxg4 Dr. John Chowning - The History of FM Synthesis | Knobcon 2019)
:
Bearbeitet durch User
Angehängte Dateien:
-
Bell_Chowning_1-09-30.png
300 KB
Rbx (rcx) 16.07.2025 20:54 >https://www.youtube.com/watch?v=tpysRrYXxg4 >Dr. John Chowning - The History of FM Synthesis | Knobcon 2019 Ein interssantes Video. >> So richtig klar wird mir aus dem Referenzmanual nicht, ob die Hüllkurve >> linear oder in der Tiefpassform implementiert ist. >Wozu soll jetzt eine Tiefpassform gut sein? Bei den Analogen hat der >Filter eine eigene Hüllkurve. An der Stelle habe ich mich wohl etwas missverständlich ausgedrückt. In der physikalischen Welt sind viele Vorgänge exponentiell. So wird die Lautstärke eines Glockentons exponentiell anstatt linear abklingen. Im Video sieht man auch exponentiell abklingende Hüllkurven (1:09:30) Mit Tiefpass bzw. Hochpass meinte ich einen RC-Tief- oder Hochpass, mit denen sich die gezeigten Hüllkurven erzeugen lassen (nicht einen Tiefpass mit dem der Ausgangston gefiltert werden soll).
Angehängte Dateien:
Für mich erstaunlich: Ich höre quasi keinen Unterschied zwischen der exponentiell- und der linear abfallenden Hüllkurve.
Angehängte Dateien:
-
fmCore.png
75 KB
Aber zurück zur eigentlichen FM-Sounderzeugung. Im Referenz-Manual befindet sich ein Signalflussbild dafür. Wenn ich es richtig verstehe, ist das der Kern der verwirrender-weise sogenannten "Operatoren". Ich verstehe das so, dass jeder Operator zwei Sinusgeneratoren und zwei Hüllkurvengeneratoren beinhaltet. Damit hat ein Operator ziemlich viele Einstellmöglichkeiten.
Christoph M. schrieb: > Aber zurück zur eigentlichen FM-Sounderzeugung. > Im Referenz-Manual befindet sich ein Signalflussbild dafür. > Wenn ich es richtig verstehe, ist das der Kern der verwirrender-weise > sogenannten "Operatoren". Ich verstehe das so, dass jeder Operator zwei > Sinusgeneratoren und zwei Hüllkurvengeneratoren beinhaltet. Damit hat > ein Operator ziemlich viele Einstellmöglichkeiten. Normalerweise bezeichnet Operator einen "Oszillator + Hüllkurve". Einen Operator dessen Ausgang zum "Lautsprecher" geht bezeichnet man als "Carrier", einen Operator der einen anderen moduliert als "Modulator". Dein Bild zeigt nach der Schreibweise also zwei Operatoren. Die werden Operator genannt, weil man bei den meisten FM-Synths diese Einheiten variabel Verschalten kann. Wenn du Dir mal auf Wikipedia die Bilder vom DX-7 anschaust, dann findest rechts über dem Display so eine große Darstellung von vielen Kästchen in unterschiedlichen Konfigurationen, Die Kästchen sind die Operatoren.
Angehängte Dateien:
-
DX7_Algorithm.png
510 KB -
YM2151_algorithm.png
26 KB
>Normalerweise bezeichnet Operator einen "Oszillator + Hüllkurve". Einen >Operator dessen Ausgang zum "Lautsprecher" geht bezeichnet man als >"Carrier", einen Operator der einen anderen moduliert als "Modulator". 7 Das hatte ich falsch verstanden. >Wenn du Dir mal auf Wikipedia die Bilder vom DX-7 anschaust Nach einigem "Zoomen" habe ich es gesehen. Im Vergleich zum YM2151 sind das ja schon ein paar mehr. Ich meine gelesen zu haben, dass der YM2151 32 Oszillatoren hat.
Angehängte Dateien:
-
Timewarp.png
66 KB
Ich hatte mal einen DX7 von einem Kollegen ausgeliehen, daher kenne ich diese Diagramme noch. Fast wie vom Vampir-Tanzlehrer gezeigt https://www.youtube.com/watch?v=-w0WPkB3XJ4
Angehängte Dateien:
Bei der Hüllkurve scheint es einen deutlichen Unterschied zwischen dem YM2151 und dem DX7 zu geben. Die Hüllkurve des YM2151 ist gegenüber der einfachen ADSR-Hüllkurve https://de.wikipedia.org/wiki/ADSR wie sie vielen Soundgeneratoren verwendet wird, ja noch mal um eine Stufe erweitert, so dass die Lautstärke nach dem schnellen Decay auch langsam abfallen kann, obwohl die Taste noch gedrückt ist. Beim DX7 ist das noch mal anders. Für was wird das gebraucht?
Christoph M. schrieb: > Für was wird das gebraucht? Meistens braucht man es eher nicht, jedenfalls ich nicht. Kommt aber drauf an. Spannender wird es, wenn man einen Joystick hat (davon abhängig, was der steuern kann) oder wenn man Klänge übereinander legt. Und an dieser Stelle (ist halt theoretisch, wenn man keine Erfahrung damit hat) kann man dann auch Midi-Steuerungen einsetzen. Sind also 2-3 Sachen, hier eine Rolle spielen. Zum einen hat der DX7 keinen Joystick, weswegen eine andere Stelle der Komplexität nicht verkehrt ist. Dann hilft es etwas weiter, wenn man sich mit der Physik der Musikinstrumente beschäftigt. Naja, und zum Dritten kommt dann noch die MIDI-World bzw. die Sound- und Musikgestaltung an sich. Beim früheren Cubase hatte man noch so einen "Logical Editor" der auch für so einigen Spaß gut war. Kann man irgendwie schlecht mit einem Satz beantworten die Frage. Beispielsweise hat man bei einem Modul-System gewisse Freiheiten. Hier kommen dann aber eher LFOs für die Steuerung in Frage, meist hat man da ja mehrere... das wäre dann übrigens eine zweite Sache, bzw. eine zweite Empfehlung: Nicht nur einen FM-Synth besorgen, vielleicht auch ein Modulsystem.. ;)
Mich interessiert ganz konkret, wie die einzelnen Stimmen im Soundbeispiel aus dem ersten Post konfiguriert sind. https://www.youtube.com/watch?v=qWhhVkbgbRM Welche Einstellung braucht man für Algorithmus und Operatoren? Super wäre, wenn man das Beispiel in eine Midi-File packen könnte.
Wäre übrigens auch schön, wenn man die einzelnen Spuren als Einzelne vorliegen hätte. (https://soundcloud.com/bitleytm/fm-fun-moments) Im Netz könnte man sich nach "DX7 Patches" umsehen. (https://yamahablackboxes.com/collection/yamaha-dx7-synthesizer/patches/) oder die AI mithelfen lassen https://theintrovert.net/2023/05/13/deep-dx-creating-dx7-sounds-with-ai-part-2-the-sounds/
Hier gibt es einen DX7-Emulator für Ubuntu. Hat jemand eine Ahnung, wie und was man da als Midi-Port angeben muss, wenn man mit einem über einen Adapter angeschlossenen Midi-Controller steuern will? https://github.com/chiaccona/VDX7
1 | ~/.local/bin/vdx7 -h |
2 | |
3 | Usage: /home/christoph/.local/bin/vdx7 |
4 | -h (this help) |
5 | -v (version) |
6 | -q quiet (no terminal stdout) |
7 | -a don't autoconnect Jack midi |
8 | -m send MIDI directly to DX7 serial interface |
9 | -k don't show keyboard on GUI |
10 | -c filename (sysex cartridge file) |
11 | -n filename (create new sysex cartridge file) |
12 | -r filename (load a firmware ROM) |
13 | -b [0-7] (bank number: load factory voice cartridge into internal memory) |
14 | -B [0-7] (bank number: load factory voice cartridge into cartridge memory) |
15 | -s filename (save/restore RAM memory file, default ~/.config/vdx7/vdx7.ram) |
16 | -t master tuning (+/-256 steps, ~.3 cents/step, default 0=A440) |
17 | -V MIDI velocity curve (.25 to 4.0, default 0.4, 1.0=linear) |
18 | -p port (jack audio port) |
19 | -i midi-in (jack midi in port regex) |
20 | -o midi-out (jack midi out port regex) |
:
Bearbeitet durch User
Hab's selber raus gefunden, ist aber umständlich:
1 | https://github.com/chiaccona/VDX7 |
2 | |
3 | DX7 mit Midi starten: |
4 | |
5 | Erst QJack im Ubunut-Menue starten |
6 | - Wenn offen, dann auf "Start" drücken |
7 | |
8 | dann in der Kommandozeile |
9 | a2jmidid -e |
10 | "Most MIDI controllers show up as ALSA MIDI devices, not JACK MIDI devices. To bridge ALSA MIDI (your MIDI controller) to JACK, use a2jmidid" |
11 | |
12 | dann in der Kommandozeile VDX7 starten: |
13 | ~/.local/bin/vdx7 -i "a2j.*" |
:
Bearbeitet durch User
Christoph M. schrieb: > Hier gibt es einen DX7-Emulator für Ubuntu. Hat jemand eine > Ahnung, wie und was man da als Midi-Port angeben muss, wenn man mit > einem über einen Adapter angeschlossenen Midi-Controller steuern will? Im README steht unter Usage, 2. Abschnitt: "A Jack server needs to be running," Ist der überhaupt installiert? Für einen laufenden jackd gibt's genügend grafische Werkzeuge zum verbinden der einzelnen Midi-Geräte.
Michael L. (nanu) 20.07.2025 20:53 >Im README steht unter Usage, 2. Abschnitt: "A Jack server needs to be running," Danke für die Antwort, aber ich habe ja einen Post über Deinem schon eine Lösung gefunden. Ich habe parallel zu dem ganzen Rosegarden und Qsynth installiert: https://rosegardenmusic.com/ Allerdings wird es jetzt zum großen Durcheinander. Wenn ich VDX7 nach der obigen Anleitung starte, wird vermutlich durch "a2jmidid -e" das Midi-Interface ausgehebelt und man kann dann keinen Midi-Synthesizer mit Rosegarden benutzen, sondern nur noch Fluidsynth. D.h. mit dem Midicontroller lassen sich dann Töne auf dem VDX7 spielen, und gleichzeitig auf Rosegarden Midi-Tracks mit Fluidsynth. Eigentlich wollte ich ja VDX7 mit Rosegarden steuern.
Angehängte Dateien:
Hier mein etwas kläglicher Versuch, die Hauptmelody aus "PowerOfTitans" https://www.youtube.com/watch?v=qWhhVkbgbRM mittels Gehör, einem Midi-Controller und Rosegarden in ein Midi-File zu verwandeln .. jedem Musiker werden sich wahrscheinlich die Zehnägel rumdrehen :-)
Cartman E. (cartmaneric) 16.07.2025 13:03 >Christoph M. schrieb: >> - FPGAs sind für die Tonerzeugung zu schnell >Das ist nun eine etwas uninspirierte Ansicht. "Inspiriert" war diese Aussage von meinen Experimenten mit FPGAs zur Tonerzeugung. Aber da habe ich mich wohl etwas missverständlich ausgedrückt. Etwas besser verständlich könnte man es vielleicht so sagen: Wenn man ein FPGA mit 50MHz Samplingrate laufen lässt und z.B. einen DDS-Tongenerator mit der Frequenz implementiert, muss der Akkumulator eine ziemlich hohe Bitbreite aufweisen, um Frequenzen im Audiobereich zu erzeugen. Viel ressourcensparender ist es, die Samplingrate auf 50kHz zu setzen und den DDS-Tongenerator über eine Load/Store-Architektur mehrfach zu verwenden. Andreas M. (amesser) 16.07.2025 09:25 >Von der Architektur her habe ich das als >Pipeline umgesetzt, so wie im DX-7. Das scheint auch der übliche Ansatz >für Datenverarbeitung im FPGA zu sein. Meinst du damit dasselbe wie das was ich oben als Load/Store-Architektur beschreibe? Vielleicht kannst du ein paar Worte dazu schreiben. Hie habe ich ein Projekt in VHDl gefunden: https://github.com/MJoergen/ym2151
Christoph M. schrieb: > Meinst du damit dasselbe wie das was ich oben als Load/Store-Architektur > beschreibe? Vielleicht kannst du ein paar Worte dazu schreiben. Hmm, ich würde es Pipeline nennen. Das ganze läuft aktuell mit ~41MHz Takt und ist wie folgt aufgebaut: - die erste Stufe erzeugt einfach nur einen stupiden Zähler, der alle Stimmen und die 4 Operatoren durchnummeriert (64*4 = 256). Diese Zählwert wird mit jedem Takt an die nächste Stufe weitergegeben. - die zweite Stufe lädt dann aus einem (Array-)Speicher den Phasenakkumulator entsprechend dem Zähler, addiert auf den Phasenwert was drauf und speichert das wieder in den Array-Speicher (Besteht eigentlich aus aus mehreren "Unter-"stufen) - die dritte Stufe nimmt die Phasenwerte und holt sich dann die Amplitude aus einer Sinustabelle - dann gibt es noch weitere Stufen, u.a. für Hüllkurven und Lautstärke, die laufen teilweise parallel ab - dann werden zunächst die 4 Operatoren einer Stimme zusammenaddiert. Dafür gibts dann einen Summenspeicher für alle 64 Stimmen, bei Operator 1 wird der mit der Amplitude von Operator 1 initialisiert, jeder weitere Operator der kommt, drauf addiert und beim 4. Operator die Summe an die nächste Stufe gegeben. (Zähler 0, 64,128,192 für die erste Stimme, usw.) Die Daten kommen hier also nur noch mit 1/4 der Taktrate raus. - die letzte Stufe summiert dann alle 64 Stimmen auf, das Summensample kommt dann mit 1/4/64 Takt da raus und geht an den DAC. Daneben gibts dann noch die ganze Logik für Midi usw. Ich werden den Code auch auf gitlab öffentlich machen sobald das Grundgerüst so halbwegs steht. Aber momentan ist das noch zu sehr Kraut und Rüben.
:
Bearbeitet durch User
Andreas M. (amesser) 22.07.2025 11:17 >- die erste Stufe erzeugt einfach nur einen stupiden Zähler, der alle >Stimmen und die 4 Operatoren durchnummeriert (64*4 = 256). Diese >Zählwert wird mit jedem Takt an die nächste Stufe weitergegeben. >- die zweite Stufe lädt dann aus einem (Array-)Speicher den >Phasenakkumulator entsprechend dem Zähler, addiert auf den Phasenwert >was drauf und speichert das wieder in den Array-Speicher (Besteht >eigentlich aus aus mehreren "Unter-"stufen) Danke für diesen informativen Beitrag. Die Stufe 1 mit dem Programmzähler ähnelt ein wenig einem Programmzähler in einer CPU. In dem Fall wäre dann die Stufe zwei die Ausführung der Befehle mit laden und speichern ( die Load/Store Architektur). Planst du einen DA-Wandler ( z.B. Sigma-Delta ) mit einzubauen? Das könnte für ein Stand-Alone-System interessant sein. Auf welcher Hardware (FPGA) wird es denn laufen?
Christoph M. schrieb: > planst du einen DA-Wandler ( z.B. Sigma-Delta ) mit einzubauen? Das hatte ich ganz am Anfang zu Testzwecken mit im Projekt drinnen, aber so einfach ist ein vernünftiger Sigma-Delta gar nicht umzusetzen. (Zumindest für mich) Von daher habe ich inzwischen einen einfachen 16Bit SPI DAC aus einem CD Laufwerk drangepappt. Christoph M. schrieb: > Auf welcher Hardware > (FPGA) wird es denn laufen? Im Moment entwickle ich hiermit: https://www.microchip.com/en-us/development-tool/mpfs-disco-kit. Da ist ein PolarFire SoC MPFS095T drauf. Ich benutze aktuell nur den FPGA Teil. Allerdings habe ich schon festgestellt, das alleine dieser Chip nur für relativ viel Geld zu erwerben ist, viel mehr als das ganze Discovery Kit kostet. Löten will man das selbst nicht und die Module von Trenz sind dementsprechend auch hochpreisig. Aber im Prinzip läuft der VHDL Code ja auch auf anderen FPGAs. Ich versuche möglichst wenig bzw. gar keine Chip spezifischen Konstrukte zu benutzen.
Andreas M. (amesser) 25.07.2025 12:50 >Christoph M. schrieb: >> planst du einen DA-Wandler ( z.B. Sigma-Delta ) mit einzubauen? >Das hatte ich ganz am Anfang zu Testzwecken mit im Projekt drinnen, aber >so einfach ist ein vernünftiger Sigma-Delta gar nicht umzusetzen. Vor einiger Zeit hatte ich mal den DAC unten implementiert. Vom Klang her war es meiner Erinnerung nach OK. Wenn man den Klang verbessern will, muss man die Integrator-Range vielleicht etwas aufbohren.
1 | ------------------------------------------------------------ |
2 | -- sigma delta DAC |
3 | -- 20. Okt. 2017 by mchris |
4 | -- 1.st order implementation |
5 | ------------------------------------------------------------ |
6 | library IEEE; |
7 | use IEEE.STD_LOGIC_1164.ALL; |
8 | use IEEE.NUMERIC_STD.ALL; |
9 | |
10 | entity sigmaDeltaDac is |
11 | port ( |
12 | clk : in STD_LOGIC; |
13 | pwmValue: std_logic_vector( 15 downto 0); |
14 | pwmOut : out STD_LOGIC |
15 | ); |
16 | end sigmaDeltaDac; |
17 | |
18 | architecture logic of sigmaDeltaDac is |
19 | |
20 | signal integrator : integer;-- range -2048 to 2047; |
21 | signal oldvalue : integer;-- range -1024 to 1023; |
22 | |
23 | |
24 | begin |
25 | process begin |
26 | |
27 | wait until rising_edge(clk); |
28 | |
29 | integrator <= integrator + to_integer(signed( pwmValue)) - oldValue; |
30 | |
31 | if( integrator >0 ) then |
32 | oldValue <= 32768; |
33 | pwmOut <= '1'; |
34 | else |
35 | oldValue <= -32768; |
36 | pwmOut <= '0'; |
37 | end if; |
38 | |
39 | end process; |
40 | |
41 | |
42 | end logic; |
Wie viele LUTs bzw. welche Resourcen braucht deine Implementierung im Moment?
Durch einen Hinweis im anderen Thread bin ich auf den Chiptune-Tracker Furnace gestoßen, https://github.com/tildearrow/furnace Der eine YM2151 Emulation eingebaut hat. Meine Hoffnung war, das *.vgn File für TowerOfTitans (erster Thread) laufen lassen zu können. Leider kann ich es nicht laden. Weiß jemand, woran es liegt?
Angehängte Dateien:
Christoph M. schrieb: > Wenn man ein FPGA > mit 50MHz Samplingrate laufen lässt und z.B. einen DDS-Tongenerator mit > der Frequenz implementiert, muss der Akkumulator eine ziemlich hohe > Bitbreite aufweisen, um Frequenzen im Audiobereich zu erzeugen. Viel > ressourcensparender ist es, die Samplingrate auf 50kHz zu setzen und den > DDS-Tongenerator über eine Load/Store-Architektur mehrfach zu verwenden. Das stimmt so aber nur, wenn du nur einen Kanal betrachtest. Um einen FM-Synth mit mehreren Stufen zu erzeugen, braucht es mehrere Sinüsse und man will in einem Synthesizer auch Polyphonie. Meiner arbeitet bekanntlich mit 256 Stimmen @768kHz -> ~200 MHz FPGA. Der FM-Teil nutzt im Vollausbau 8 Multiplizer. Die ursprüngliche Version hier unten ist mit der ARchitektur 8x96kHz realisiert, um sich die vielen Multiplizier zu sparen und weil meine allerersten Synthesizer auf 96kHz liefern. http://www.96khz.org/htm/fmsynthesis2.htm
Ob S. schrieb: > Sehr wahrscheinlich maximal 2kbit Speicher. Wie das dann auf > temporal/spatial aufgeteilt ist: keine Ahnung. Ich weiß es leider auch nicht, allerdings ist die Tabelle da sicher nicht sonderlich groß. Es wäre möglich, daß ein anderes Syntheseverfahren für den Sinus mit Teilabschnitten verwendet wird. Es gab da ein Verfahren, das auch auf mehrfacher Tabellenauslese basierte und den Sinus aus Teilbögen zusammensetzte. Wurde früher in Zeiten des RAM-Sparens öfters benutzt. Mir fällt leider der Name nicht mehr ein, aber wir hatten das hier vor einigen Jahren schon mal thematisiert. Aus der Erinnerung gab es eine Kombination für die höheren Bits und die niederen Bits getrennt. Eventuell kommt ja jemand auf den Namen. (?) Oder es ist eine Näherung. Von einem aktuellen Synthesizer aus Fernost weiß ich, daß sie es iterativ mit einem DSP in 32 Bit machen. Für einfache Fälle in FPGAs habe ich auch die hier schon genutzt: https://www.mikrocontroller.net/articles/Digitale_Sinusfunktion#Sinus-Approximation_2 Für eine FM-DDS muss man in jedem Fall beachten, daß dort bei multiplikativer Verknüpfung der Oszillatoren zu Ringoszillatoren sehr hohe Frequenzen erzeugt werden, die sehr rasch klirren, wenn die Sinuswerte nicht gut stimmen. Es braucht da eine sehr genaue Berechnung, wenn das sauber sein soll. Insbesondere, wenn da später mal Tongeneratoren zusammen klingen sollen, um Akkorde zu bilden.
J. S. schrieb: > Das stimmt so aber nur, wenn du nur einen Kanal betrachtest. Um einen > FM-Synth mit mehreren Stufen zu erzeugen, braucht es mehrere Sinüsse und > man will in einem Synthesizer auch Polyphonie. Meiner arbeitet > bekanntlich mit 256 Stimmen @768kHz -> ~200 MHz FPGA. Die Größenordnung passt, aber ich sehe nicht wo dein Ablauf ein FM Synth ist. Der Sinn des FM Synth ist ja gerade, das ein Operator(Oszillator + Env + VCA) die Frequenz eines anderen steuert. Diese Kopplung sehe ich in Deinem Bild nicht.
Andreas M. schrieb: > Env + VCA) die Frequenz eines anderen steuert. Diese Kopplung sehe ich > in Deinem Bild nicht. Vergiss es, ich habs gefunden :-D
Angehängte Dateien:
-
logsin.png
47 KB
J. S. (engineer) >Ob S. schrieb: >> Sehr wahrscheinlich maximal 2kbit Speicher. Wie das dann auf >> temporal/spatial aufgeteilt ist: keine Ahnung. >Ich weiß es leider auch nicht, allerdings ist die Tabelle da sicher >nicht sonderlich groß. Es wäre möglich, daß ein anderes >Syntheseverfahren für den Sinus mit Teilabschnitten verwendet wird. Mittlerweile hat sich im Laufe dieses Threads herausgestellt, dass der Sinus nicht linear, sondern logarithmisch abgelegt ist. In irgendeiner der C-Implementation habe ich gesehen, dass sie eine 16K Tabelle verwendet hatten. Mich wundert ja, dass der Sinus nach den verschiedenen Transformationen noch gut klingt. Vielleicht müsste man mal ein wenig damit experimentieren.
:
Bearbeitet durch User
Christoph M. schrieb: > Vielleicht müsste man mal ein wenig damit experimentieren. Gute Idee. Beim Roland D-50 gab es auch schon (bzw. noch) ein wenig Trickserei https://www.amazona.de/vintage-digital-roland-d-50-d-550-pg-1000-synthesizer-1987/ (Suchen nach: "Sägezahn-Pulsbreitenmodulation")
Yamaha hat nicht nur den hier im Thread behandelten FM-Soundchip YM2151 hergestellt, sondern ein ganze Familie. Hier ist eine guter Übersichtsartikel, der verschiedene Chips vergleicht: https://www.thingsmadesimple.com/2023/04/29/ym3812-part-6-patches/ Die Nummerierung der Chipgenerationen scheint mir etwas eigenwillig. In der Tabelle kommt der YM3526 zuerst, wurde aber wohl auch 1984 ausgeliefert: https://en.wikipedia.org/wiki/Yamaha_OPL In dem Artikel findet sich auch die Erklärung und die Größe der Log-Sinustabelle. Und hier noch die riesige Liste der Soundchips verschiedener Hersteller: https://en.wikipedia.org/wiki/List_of_sound_chips
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.