FPGA Synth. Was ist machbar?

Was heißt Du beschäftigst Dich damit?

Zur Frage, ich würde da lieber das Oversampling hochschrauben statt so viele Stimmen zu haben.
Problem dabei ist wahrscheinlich, wie man das Audio nachher rausbekommt bekommt mit Standardhardware.
 
Na ja, ich beschäftige mich seit 3-4 Jahren mir Arduino im Allgemeinen und mit Atmega im Speziellen, also Micro Controller Programmierung. Nachdem ich dann erfuhr, dass der PEAK mittels FPGA umgesetzt wurde, hat mich das aufhorchen lassen. Sowas passiert nach 40 Jahren Programmierung (auch Assembler) und die Affinität zur Elektronik.

Von meinen Kindern bekam ich gestern zum Vattertach "FPGAs for Makers" geschenkt. Was daraus wird weiß ich nicht, bin aber im Moment ziemlich angefixt.
 
Schicke Sache, hast Du eine fertige DSP Softcore verwendet, oder alles selber geschrieben?
 
starling schrieb:
Zur Frage, ich würde da lieber das Oversampling hochschrauben statt so viele Stimmen zu haben.


richtig, lieber 100 mal weniger stimmen aber doppelt so guten sound
 
Stopp. Das von mir Verlinkte ist nicht von mir. Wäre froh, wenn ich soweit wäre.

Achso. WIe auch immer. Ich habe mal selbst einen Synth gebastelt. Mit 2 ATMegas und DDS. Die beiden habe ich über I2C miteinandert verdrahtet der eine war für MIDI zuständig und der andere für die Klangerzeugung. Wenn man so will war das MIDI Modul im Prinzip nur ein MIDI-2-CV Interface mit i2C Schnittstelle. Ich bin da schnell an Grenzen gekommen. Hat aber trotzdem Spass gemacht. :phat:
 
Die o.g. Seite ist von mir. Zu dem Thema FPGA und Musik habe Ich im Microcontroller-Net recht ausfühlich Stellung genommen.

Tenor: Es gibt einige spezielle Dinge, die man im FPGA BESSER machen kann und insbesondere im Bereich der Echt-Zeit-Parameter-Änderung beim Hall und der Klangerzeung NUR im FPGA machen kann, weil man die Kanäle und Signale alle parallel "sieht". Das erfordert aber spezielle HW-orientierte "Programmiertechniken" = Schaltungen / Schaltungsbeschreibungen, die stark von dem abweichen, was man in SW macht - bzw WIE man es in SW macht. Ich meine damit nicht VHDL als solches, sondern eine HW, die macht was sie soll, dies aber unter Berücksichtigung der Technologie tut. Dazu gehören auch einige Dinge wie 3D-pipelines, FSM-pipeline, die Ich entwickelt habe und die nirgends in den Büchern stehen. Ferner sind einige Themen aus dem Umfeld Audioaufnahme, Tonaufnahme eingearbeitet, die sich nur in dem mehrdimensionelen Raum anwenden lassen.

Die z.B. 4096 Kanäle ergeben sich - wie einige andere Dinge auch - aus dem Verhältnis der Taktfrequenz zur Sameplefrequenz und ist kausal. Ohne da jetzt zu weit einzusteigen, erfordert das dann auch RAM ohne Ende, um diese Kanäle zu fahren und auch zu parametrieren und modulieren. Diese RAMs sind Limiter! Weitere Themen sind die Verschachtelungen der Filterketten im Bezug auf Kanal, Sample und Zeitpunkte. Daraus ergeben sich je nach Struktur Sub-Systeme mit der Granularität 4,16 und 64 Takten, wobei das Trimming da das Problem ist, damit alles richtig ineinandergreift. Wenn man alles voll parallel macht, bekommt man nicht viele Stimmen und bei voller sequenzieller Arbeitstechnik (SW) wird es langsam und letztlich ineffektiv.

Man muss genrell mit bestimmten Randbedingungen im FPGA leben und kann da nicht alles so bauen, wie man das in SW kann - speziell bei Filtern. Diese sind mitunter aufwändiger und nicht immer effektiv zu implementieren. Berücksichtigt man das, wird der FPGA aber sehr effizient. Effizienter, als alles andere, auch z.B. GPU! Konkret lässt sich das an der Speicherbandbreite messen:

Im aktuell designten Minimalsystem mit Synth und DSP arbeiten fast alle BRAMs parallel mit 2,3 oder 4 Zugriffen. Das sind etwa 200 MHz x 3 x 8 Bit x 320 RAMs. Hinzu kommen Zwischenspeicher in FFs. Das entspricht etwa dem von 50 PCs, wollte man das mit SW und DDR3-Controllern bieten, um allein die Daten zu schieben - ohne was zu rechnen. Bei der Rechenleistung ist es etwa Faktor 10-20, d.h. man bekommt mit EINEM FPGA, das perfekt getrimmt ist, eine Rechenleistung von rund 15 PCs.

Die Problematik ist, ob und wie man die musikalisch einsetzen kann. Es macht nicht umbedingt Sinn, so viele Stimmen voll parallel zu fahren. Auch für das Klavier fahre Ich derzeit "nur" 88 Töne x3 Saiten x8 Oberwellen. Zudem sind qualitativ viele Dinge bei Synths schon da und lassen sich in DSPs viel einfacher und billiger realisieren. Einen Synth, wie er in DSPs vorliegt, im FPGA ohne "Meine" Funktionen nachzubauen, ist nicht sonderlich schlau, weil in VHDL anspruchsvoller und daher nicht wirklich besser. Ihn sogar auf der Basis von Softcore-DSPs oder in Verbindung mit hardcore ARM nachzubauen, ist IMO kontraproduktiv. Das wird an Hochschulen allenthalben gemacht, führt aber zu extremem Overhead mit wenig output.

Siehe auch meine Ausführungen dazu im ucNET: https://www.mikrocontroller.net/topic/327505#4450381

Ein FPGA kann aber ganz bestimmte Dinge, die man als Ergänzung zu DSP-Synths nutzen kann. Ich plane derzeit die Bereitstellung eines abgespeckten Systems als Modul für Bastler : http://www.pyratone.de

Das sind auch solche Spielchen wie PDM-Ausgabe für 8 Kanal, 4 Kanal bass Array möglich.
 
Dass MIDI innerhalb eines Computers (welcher Form auch immer) nur an die zeitlichen Limits dieses Computers gebunden ist, ist klar. Wie ist das aber mit 12 Bit gemeint? MIDI erfasst Daten, soweit ich weiß, standardmäßig in 7 Bit und 14 Bit Auflösung. Bestimmte Wandler arbeiten mit 12 Bit. Wie hängt das aber mit FPGA zusammen?
 
Interessantes Thema - da es ja irgendwo auch fragt - was können wir noch tun?
Oder? Meinst du das auch so?

Es gibt noch einen anderen FPGA Synth, dh mehrere - den AVS04 zB von Martin Hollinger aka Airbourne viewtopic.php?f=36&t=18031&p=347330#p347330
und den Paradigm viewtopic.php?f=2&t=120105&hilit=paradigm#p1412592

dh - einiges muss sich da noch beweisen. Aber - die Technik ist eigentlich egal, solang das Ergebnis toll ist. So generell dazu.
Was machbar ist? Ich glaube "alles",
wobei ich mehr als 128 Stimmen schlicht für unnötig halte für die meisten Anwendungen, außer Drone und Co, SpezialAmbient,Layer-Zeugs vielleicht..
viewtopic.php?f=47&t=123120 <--- Mindestzahlen sind das, daher nur so. Gewünschte Zahl haben wir noch nicht umgefragt, wäre ggf. interessant.
Ich denke ich als eher Layermuffel würde wohl wenige ausreichend finden.. aaaaber…

ich würde den Schwerpunkt immer auf Synthese und Klanginsgesamt legen, Bedienung natürlich auch. Zuweilen haben Akademiker andere Ziele als zB Popmusiker und div. Genreanforderungen und so gibt es schon auch. Daher - der ideale Synth kann alle ansprechen. Wobei - im akademischen Bereich werden auch seltener "Synthesizer" eingesetzt im heutigen Sinne als viel mehr genau definierbare Modelle, also meist Software. FPGA bedeutet was für dich? Also was genau assoziierst du damit anderes als zB mit DSPs, Prozessoren aller Art, Embedded?
Aduino und Co ist für mich einfach ein kleiner Prozessor für die Massen - also super um was zu machen, weil günstig und massig hergestellt. Gute Basis. Aber FPGA…?
 
Urs Heckmann und einige anderen haben es ja geschafft wirklich analog klingende Filter in SW zu bauen. Dabei wurde völlig neue Algorithmen verwendet die nur mit der heutigen Rechenleistung in Echtzeit zu meistern sind. Wie sieht es in FPGA aus, kann man dort auch solch analoge Schaltungsimulationen fahren wie beim u-he Repro-1 oder TheLegend?
 
Prinzipiell sollte das gehen aber bei einer hohen Samplerate braucht man das eigentlich nicht unbedingt.
 
Gesammelte Antworten:

SW = Software ja, und hier meine Ich eben klassische C-Software. Viele FPGA-Implementierungen, die heute angestossen werden, sind praktisch MCUs in VHDL, die dann ablaufen wie in C. Das ist ineffektiv und nur gerechtfertigt, wenn man wirklich Strukturen hat, wie Listen und Klassen und abstrakt programmieren muss. Bei Audio und Synthese ist das eher NICHT der Fall. Daher ist C kein Muss und kein Vorteil sondern nur eine Erleichterung in der Entwicklung.

Dazu nochmal: Im FPGA gehen Sachen, die in SW grundsätzlich nicht gehen, vor allem nicht in Echtzeit.

Weiter: Im FPGA geht generell alles, was die SW kann. Wenn dort "neue Algorithmen" vorliegen, wie oben eingeworfen, wären die also auch im FPGA zu machen. Die Frage ist nur, WARUM? Wenn es in SW - genauer mit einem Prozessor geht - braucht man keinen FPGA. Von meiner Seite kam der FPGA seinerzeit ins Spiel, weil damit Dinge machbar sind, die in SW, genauer DSPs und Prozessoren eben NICHT gingen und vielfach nach wie vor nicht gehen und in einigen Fällen auch nicht gehen werden, egal wie schnell die sind.

Grundsätzlich kann man mal sagen, dass die Implementierung der meisten mathematischen Funktionen, wie sie für Elektronikemulation und Mathe / Physik nötig sind, in VHDL im FPGA aufwändiger sind. Daher haben da ja viele die Segel gestrichen :)

Ich habe aber in all den Jahren eben auch Techniken und Algos identifiziert, die sich da eben besonders effektiv machen lassen. Nehmen wir einen echten "analogen" Schwingkreis: Der erfordert mit Einflussparametern eine Berechnung von 20-40 Schritten, womit man einen loop von 5-10 MHz hinbekommt. D.h. die physikalische "Welt" die der FPGA durchrechnet, wird sehr fein aufgelöst. Damit kann man Resonatoren sehr genau auf elementarer physikalischer Ebene schwingen lassen und bekommt ein sehr natürliches Verhalten gegen "Spannungsänderungen", "Rauschen", Nichtlinearität und Filterkoppllung, OHNE dies erst in analytische Gleichungen packen zu müssen. Wenn man z.B. die Zustände in einer Klaviersaite (Spannungsausbreitung, Schall in Metallen) berücksichtigt, bekommt man ein anderes Ergebnis, als wenn man versucht, das mit fertigen Gleichungen zu rechnen, dei oft nur Näherungen sind, weil sie analystisch nicht mit Differentialgleichungen lösbar sind. Stichwort "Numerische Simulation".

Wie gesagt, sind viele Ideen diesbezüglich bereits in technischen Produkten drin, um umgekehrt Ideen aus technischen hiQu-Simualtionen für Ultraschall, Radar und anders in diese Modelle eingeflossen. Ich habe z.b. ein Modell für BH-Kennlinien für magnetische Werkstoffe, mit dem Ich gemäss obigem Schema, das Verhalten bis über 100kHz in Echtzeit genau nachbilden kann. Stichwort: Bandkompression.

Weiter Techniken ergeben sich um Umfeld der Reflektionsberechnung für den Hall.
 


News

Zurück
Oben