Waldorf Kyra (ehem. Exodus Digital Valkyrie): Der Virenkiller?

[Martman]

Wer braucht eine Supernova 3, wenn's bald eine Walküre gibt?

Der neue VA-Platzhirsch heißt wohl Exodus Digital Valkyrie. Er wurde erschaffen von jemandem, dem die Stagnation beim Virus auf den Keks ging (fast die Hälfte der Zeit, die es den Virus jetzt gibt, ist er schon der TI2) und der fand, da geht noch einiges. Und wenn Kemper nicht liefert, dann greift man eben zur Eigeninitiative.

Das Ergebnis ist, wie es aussieht, endlich mal wieder ein featurestrotzender Oberklasse-VA, der noch dazu nicht diese 90er-Jahre-Tendenzen hat wie der Virus. Die Unmengen an Leistungsreserven kommen daher, daß der Valkyrie auf FPGAs aufsetzt. Gute Nachrichten für Reglerjunkies: Zumindest die ersten beiden Oszillatoren haben jeweils eigene Bedienelemente, und die Effektsektion (EQ, Zerre, Delay, Phaser, Chorus, Hall – schon wieder kein Flanger, was soll das) hat eine Bedienmatrix.

Preislich wird's auch interessant: Die Pultversion soll einsacht UVP kosten. Wenn das dann einssechs Straße werden, wird's lustig, und Kemper kann sich schon mal warm anziehen. (Oder vielleicht sollte Caballero nebenher einen Profiling-Amp bauen...) Tastenversion ist übrigens auch angekündigt. Sagen wir zwei Straße für die Tastenversion, und ich glaube, der wird hier nicht gerade unpopulär.


Martman

 

[taxman]

Der Valkyrie ist zweifelsohne interessant und wahrscheinlich bezüglich der verbauten Technik die Zukunft. Der Virus ist mit seinen DSPs ausgereizt, da ginge ohne komplett eine neue Struktur aufzusetzen nicht mehr viel. Insofern hat Herr Kemper den noch gut gepflegt zudem wie ich letztens testen konnte immer noch mit einem guten Support. Nach wie vor ist der Virus, wenn man den Grundsound mag, ein schöner Synth. Ich würde meinen jetzt nicht einfach in die Tonne treten, nur weil was neues rauskommt. Und ich erwarte auch nicht, das Herr Kemper unbedingt einen TI3 raushaut und in Konkurrenzkampf geht. Vielleicht kommt demnächst ein Moddelingstagekey...

 

[egoldstein]

Plot Twist: Valkyrie heißt jetzt Kyra. Und stammt nicht mehr von Exodus Digital, sondern Waldorf.

Joachim Flor, Geschäftsführer von Waldorf, hat den Valkyrie auf der Messe entdeckt, direkt dessen Entwickler Manuel Caballero angesprochen und einen Deal für Produktion (und Design) über Waldorf eingefädelt. Die Produktion soll zur NAMM 2019 anlaufen, der Preis ist auf 1899€ angesetzt.

 

[hybrix]

Wow! Könnte der neue Stern am VA-Himmel werden!

 

[Martman]

Wie stehen wohl die Chancen, daß das Ding MuBo-tauglich mit einer 61-Tasten-TP8/S mit Aftertouch für unter 2.000 Straße zu haben sein wird?

Andererseits, ob der hier wirklich populär werden wird, wenn er keine Multisamples streamen kann...


Martman

 

[murmichel]

Als ich die Videos von der Musikmesse gesehen habe, war ich schwer beeindruckt. Insbesondere von der Leistung, die Manuel Caballero als einzelner Entwickler da vollbracht hat.

Beim Blick auf die technische Umsetzung als Hardware, also ein physisches Gerät, schleichen sich bei mir aber Zweifel ein. Der Klang der Valkyrie/Kyra wird algorithmisch ("virtuell") erzeugt, da spielt es eigentlich keine Rolle, ob diese Algorithmen nun auf einem FPGA laufen oder auf der CPU eines gewöhnlichen Computers.

Die Erwiderung darauf könnte sein, dass es zwar prinzipiell so ist, dass die Rechenleistung des FPGA für diesen speziellen Anwendungsfall aber weit über der Rechenleistung eines üblichen Computers liegt. Ist das plausibel?

 

[Telefunky]

Rechenleistung ist in diesem Kontext ein irreführender Begriff.
Es geht um Zeit - und die ist bei einem FPGA quasi zementiert, da funkt kein BS oder CPU Interupt dazwischen. Die Kompensation von Algorithmen (die über DSP Chipgrenzen verteilt sind) entfällt.

Auch die 'Modellierung' selbst ist grundverschieden von dem, was man auf einer CPU entwirft.
Deswegen ist das Wissen um diesen Bereich relativ wenig verbreitet, was den Waldorf Schritt absolut nachvollziehbar macht.

 

[taxman]

Och, .... wenn da noch freies RAM für eigene Sample drin wäre, würde ich meinen Post oben noch einmal überdenken

 

[Martman]

Beim Blick auf die technische Umsetzung als Hardware, also ein physisches Gerät, schleichen sich bei mir aber Zweifel ein. Der Klang der Valkyrie/Kyra wird algorithmisch ("virtuell") erzeugt, da spielt es eigentlich keine Rolle, ob diese Algorithmen nun auf einem FPGA laufen oder auf der CPU eines gewöhnlichen Computers.

Was wäre die Alternative?

Ich glaube nicht, daß die Fähigkeiten des Valkyrie bzw. Kyra mit analoger Hardware im selben Umfang umsetzbar wären – mit diskreter analoger Hardware à la 70er Jahre erst recht nicht.

Die Erwiderung darauf könnte sein, dass es zwar prinzipiell so ist, dass die Rechenleistung des FPGA für diesen speziellen Anwendungsfall aber weit über der Rechenleistung eines üblichen Computers liegt. Ist das plausibel?

Von der Performance her stecken FPGAs bei dieser Aufgabe jeden DSP locker in die Tasche (VA-Synths basierten bisher auf DSPs), der bei derselben Aufgabe seinerseits wiederum jede Computer-CPU in die Tasche steckt. Ich wage kaum mir vorzustellen, was an x86_64-CPU-Leistung nötig wäre, um auch nur die volle Power eines Virus TI2 ohne Stocken und ohne nennenswerte Latenz abzufahren – geschweige denn die eines Valkyrie/Kyra. Man bräuchte wahrscheinlich ein ziemlich opulentes internes Netzteil und aktive Kühlung per Lüfter.


Martman

 

[murmichel]

Was wäre die Alternative?

Die Alternative wäre gewesen, die Walküre nur als Software/Plugin zu realisieren.

Da habe ich mich gefragt, ob es realistisch gewesen wäre.

 

[Telefunky]

wenn du Seite 3 von Martmanns Link gelesen hättest (das Interview mit dem Entwickler), würdest du dir die Frage nicht stellen
Er kam aus der DSP-Ecke (Sharc, die auch im Solaris arbeiten) und hatte bestimmte Ideen, die sich nicht realisieren liessen. Da er Leute mit FPGA Erfahrung kannte, hat er diese Ideen mit ihnen diskutiert und schlussendlich ist ein Projekt daraus geworden.
Die 'quasi-Codierung' wurde dann aber komplett an externe FPGA Fachleute delegiert.
Das hat wirklich nichts mit den geläufigen DSP-Algorithmen zu tun.

 

[murmichel]

Aha, das erklärt es dann wohl.

Wer den Link sucht: https://www.amazona.de/preview-exodus-digital-valkyrie-interview-manuel-caballero/3/

Das hat wirklich nichts mit den geläufigen DSP-Algorithmen zu tun.

Das habe ich auch nicht behauptet, aber ein Algorithmus liegt dem Ding trotzdem zugrunde, nur dass der in Hardware realisiert ist, nicht in ausführbarem Code. Derselbe Algorithmus könnte auch auf auf einem DSP oder einem gewöhnlichen Computer ausgeführt werden, nur dass dann die Performance anscheinend erheblich (unbrauchbar) schlechter ausfallen würde.

 

[engineer]

Jetzt muss Ich wohl auch mal, da sich bei mir in der mail box die Nachrichten häufen:

Wie die meisten wissen, habe Ich einen kompletten Synthesizer in FPGA-Technologie gebaut, inklusive Klangerzeugung, DSP für Mehrkanalton und auch MIDI-Vorsatz wie man das von den Drumcomputern kennt. Das System ist 2003 entstanden, immer wieder erweitert worden und Teile davon tuten auch in Form von Klängen auf CDs, in kommerziellen Klangerzeugern von OEMs, einem ASIC und vielen Applikationen - allerdings vorwiegend industriellen Anwendungen / industrial Audio.

Der Grund, warum ich damals auf FPGAs gesetzt habe, war dreierlei:

1) FPGAs wieder auffrischen. Hatte das zu Beginn der 90er im Studium, dann länger nicht mehr

2) Dinge machen, die kein anderer hat. Immer wieder habe Ich an Synths Dinge vermisst, Firmen angeschrieben und Tipps gegeben. Selten wurde was umgesetzt.

3) Dinge bauen, die in DSPs nicht gehen.

Der Punkt 3 ist eigentlich der Wichtigste, dazu muss man aber sagen "die nicht GINGEN", denn die Thematik der hohen Rechenleistung, der IO-Leistung, hat sich in den letzten 10 Jahren ja sehr entspannt. Heute bekommt man kleine kompakte Audio-DSPs inklusive S/PDIF-Schnittstelle, die HDMI-Chips haben das onboard und die Standard-Mikrocontroller machen für unter 10,- alles, was machen braucht, inklusive high-speed Schnittstellen. So ist es möglich, hochschnelle Datenverbindungen zwischen DSPs zu erzielen, die man früher so nicht hinbekommen hat. Damit kann man kaskadieren, Leistung multiplizieren und die s.g. Massiv-Parallelen-Systeme bauen.

Somit gab es früher definitiv viel mehr Gründe, einen FPGA ins Spiel zu bringen, als heute. Denn eines muss klar gesagt werden:

Die effektive interne Bandbreite bei FPGAs ist zwar höher, insbesondere die dadurch bedingte maximale Rechenleistung und Datendurchsatz - eine definierte, vorgegebene Rechenleistung erledigen DSPs im Vergleich aber erheblich billiger.

Daher bin Ich auch recht erstaunt, dass nun immer mehr Synthi-Firmen auf den Trichter kommen, jetzt doch auch vermehrt auf FPGAs zu setzen - insbesondere, wenn Ich sehe, dass die Strukturen der Synths sich nicht wirklich ändern und kaum elementare Funktionen hinzu kommen, die FPGAs erfordern. Auch sehe Ich nichts Greifbares realisiert, was FPGAs ermöglichen und DSPs nicht.

Bis auf wenige Dinge, lassen sich übliche Rechnungen auch mit DSPs machen und dies sogar teilweise einfacher. Ich habe einige derartige Dinge integriert, von denen Ich auch nach wie vor überzeugt, dass sie andere nicht haben (Ich habe regelmäßig in meinem Job mit entsprechenden Leuten zu tun, die ebenfalls high-tech Signalverarbeitung machen, z.B. MRT, Ultraschall, Radar, Lidar und etc.) und kann das einschätzen, was da unterwegs ist. Mit diesen Konzepten kann Ich dann in FPGAs auch Strukturen erzeugen, die sich nicht standardmäßig bauen lassen - das gilt für allem für eine von mir entwickelte pipeline - Technologie in mehreren Zeitebenen sowie die Multi-FPGA-Matrix:

http://96khz.org/htm/scalableaudiodsp.htm

Das Konzept ist in ähnlicher Form in einer Industrie-App verbaut und vom Kunden patentiert.

Wie auch immer, scheint die Musikwelt nach vielen Jahren der Fortentwicklung der DSPs, die eigentlich FPGAs absorbieren, nun die FPGAs entdeckt zu haben. Was Ich bisher gesehen habe (wir haben einiges erworben und auch aufgesägt - ) bestätigt mich aber in der Annahme, dass die FPGAs - zumindest bei manchen Firmen und Produkten - auch ein bisschen der Versuch sind, sich ein Alleinstellungsmerkmal zu schaffen und irgendein Gimmik reinzuwerfen, das nicht wirklich Gehalt hat und haben kann.

FPGAs erfordern - wenn man sie effektiv nutzen will - die Einhaltung ganz bestimmter Randbedingungen und diese führen technologiebedingt, immer zu einem Überangebot an Taktgeschwindigkeit und Mangel an RAM, was dazu führt, dass die Entwickler Daten in externe RAMs auslagern und stark sequenziell arbeiten, um Architektur zu sparen. Dann aber hat man verloren und kann das onthefly das FPGAs beherrschen nicht nutzen.

Wer dazu (Vergleich) mehr wissen will, kann eine "Stellungnahme" von mir dazu hier lesen:
https://www.mikrocontroller.net/topic/327505#4435830

Ich bin aber mal gespannt, was Waldorf da bringt. Was Ich bisher gelesen habe, wird es im Wesentlichen eine hochgenaue Wave-Synthese sein, vermute Ich mal, d.h. hoch abgetastetes Material, das sich sehr fein modulieren lässt. Zu diesem Thema habe Ich vor ca 2 Jahren mal in der Access Virus Gruppe eine Abhandlung geschrieben, welche erklärt, welches die Vorteile sind - auch im Bezug auf FPGAs. Werde den Beitrag mal suchen und linken.

Ein derartiges System habe Ich 2006 als Wellenformgenerator in einer Ultraschall-Applikation realisiert und sie ist in etwas ausgebauter Form (höhere Auflösung und mehr Kanäle) in meinem Morpher drin -> Beatmorph. Der kann Samples in Echtzeit auf 0,001% genau modulieren. Man benötigt solche Dinge beim Radar und beam forming, wenn es jemanden interessiert.

Was Ich damit sagen will ( und was mich beschäftigt):

Das Problem ist nicht, etwas ins FPGA zu bringen. Solche Sachen sind weitläufig bekannt und gemacht und ich erwarte da nichts Neues. Das Problem der Musikelektronik ist, es BILLIG genug zu machen, d.h. für einen Preis, den der Anwender bezahlen will, ein komplettes Gerät hinzustellen. Bei DEN Preisen um 2000,- abwärts, bleibt da nicht viel über, für aufwändige Entwicklung und Technologie, d.h. mehr, als ein 100,- Euro FPGA bekommt man da nicht rein. Für Dasselbe Geld erhalte Ich in DSP-form Silizium, das 3x mal soviel kann.

Auch in meinem System sind inzwischen Dinge angefallen, die Ich in Software mache, zunächst ein NIOS Softcore-System (MIDI) und mittlerweile ein Zynq (USB). Weitere Sachen würde Ich heute mit einem 3,- STM32 lösen, statt VHDL zu schreiben und Silizium zu verschwenden. Der Grund ist einfach, dass die DSPs die FPGAs von unten her "einholen".

Ein FPGA macht nur dort Sinn, wo es absolut nötig ist, wegen der Bandbreite, um z.B. 150 MHz Video zu verarbeiten. Für die Erzeugung von 192kHz Audio brauche Ich aber keine HW. Das kann ein DSP und sie können es zunehmend besser. Damit kommt es also letztlich nur noch darauf an, was insgesamt an algorithmischer Leistung erzeugt werden muss, wieviele Stimmen z.B. erzeugt werden können und die ergeben sich aus der Taktfrequenz / Abtastrate, also in meinem Fall 200 MHz mit 1024 Stimmen zu 192kHz oder eben 4096 zu 48Khz. - als Minimum für ein Modul:

Beispiele hier: http://96khz.org/htm/fpgamusicsynthesizercyclone4.htm

Dann kommt es noch darauf an, wieviele solcher Einheiten man parallel ins FPGA bekommt und was da noch alles an Verarbeitung rein muss, wie USB, UART oder eben S/PDIF Wandlung, die ich am Anfang komplett händisch gemacht habe. An der Stelle kommt die Komplexität des Systems rein und irgendwann gehen einem die Resourcen aus.

Nun kommt bei Vielen sicher das Argument: "Die FPGAs sind in den vergangenen Jahren leistungsfähiger geworden". Das greift aber nicht, wenn es o.g. Minimalanforderung nicht gibt und diese von FPGAs schon vor 10 Jahren locker übertroffen wurden. Mein erster Synth von 2004 konnte schon 1024 Oszillatoren-Stimmen bei 50MHz.

Es geht also in der Tat um die Euros / Rechenleistung und die war und ist bei DSPs erheblich günstiger. Aus genau dem Grund arbeiten auch wir in vielen Schaltungen immer noch mit DSPs / wieder mit DSPs oder nur noch mit DSPs. Es gibt heute Video-DSPs, die das leisten, was Ich vor 10 Jahren mit Spartan 3 FPGAs gemacht habe.

Ein absolute Anforderung für FPGAs sehe Ich da eigentlich nicht. Warum nun ausgerechnet die kostenkritische Musikindustrie auf FPGAs setzt ... ???

Wir haben ja von der anderen Seite her die PCs, die mit richtig guten 64-Bit CPUs daher kommen und auch die Grafik-Chips, die erheblich mehr können, als ein FPGA. Nehmen wir mal die PCIe-Technologie: Da sind die Intel-Cores den FPGAs 2 Jahre und die Grafikkarten 4 Jahre voraus. Ein mir bekannter Hersteller für 3D-Rendering im Med-Bereich (der nicht aufs Geld schauen muss) nimmt z.B. preisgünstige Grafikkarten zum Rechnen. Die macht ganz normale Gleichungen, die aus MATLAB kommen zu 300,- das Stück. Wollte Ich dasselbe im FPGA machen, bräuchte Ich einen Kintex-FPGA im Bereich 1500,- und das Dreifache an Entwicklungsaufwand.

D.h heute ist es eigentlich um so schwieriger, eine Hardware hinzustellen, weil die CPUs im PC schon soviel können. Das, was ein typischer DSP 56303, der z.B. in der UAD1, in meinem Tascam-Mischpult, in der Soundart Chameleon und anfänglich auch im Access-Virus verbaut war, kann - das kriegt heute ein Kern einer 4GHz-CPU hin - als plugin.

Nun werfen einige gerne ein, dass man FPGAs auch über C programmieren kann, indem man C in FPGA übersetzt und so alten Code nutzen kann und effektiv entwickeln kann. Nun, Ich habe das auch mehrfach durchexerziert: Ja, kann man, ist aber ineffektiv. Beispiel ist z.B. die Vivado HLS und der Versuch von vor 10 Jahren von Mentor mit Catapult C, C++ zu übersetzen. Auch der aus embedded MATLAB erzeugte FPGA-Code ist ineffektiv und eignet sich nur fürs Prototyping. Der Grund ist einfach: Es kommt am Ende immer eine Ablaufstruktur heraus, die eine Art Prozessor darstellt, welche das Programm ausführt. Gerad mal HLS ist in der Lage eine pipe zu generieren, aber eine 1D ist immer ineffektiver, als linearer C-Code, eine 2D nicht durch C spezifizierbar und eine 3D pipe baut ausser mir offenbar niemand :-D Allen gemein ist, dass das Universal-Silizum im FPGA teuer ist im Vergleich zu einer CPU. Einer meiner Kunden hat daher schon um 2011 herum mit meiner Unterstützung eine Radar-Applikation auf eine Industrie-PC-Plattform integriert und 40% des vormaligen VHDLs- inklusive FFT und IFFT in Software gemacht. War schnell genug und stromsparender zum halben HW-Preis.

Wie gesagt, sehe Ich nicht, dass man wesentliche Teile von Klangsynthesen preisgünstig(er als DSPs) in FPGAs verpacken kann. Was dort geht, ist z.B. Surround-Prozessierung, n-D-Faltung, aber dann reden wir auch von HW-Kosten in der Preislage von 500,- allein für die FPGAs. Auch mein System füllt inzwischen FPGAs in dem Umfang, ich mache aber auch Sachen, die keiner braucht

Das, was Ich in meinem Drum-Computer an Logistik und MIDI-Funktion habe, würde man auch in einen PC-plugin auf einem 90er-Jahre Rechner schaffen, mit 10% Rechenzeit. Einzig der Resampler arbeitet mit entsprechender Auflösung von 128x 768kHz , also quasi analog. Der belegt aber auch den halben FPGA

Siehe die Grafik ganz unten: http://96khz.org/htm/drumcomputerspartan6.htm

Zu dem Thema könnte man noch mehr schreiben, Ich verweise aber auf diesen Beitrag dazu:

https://www.mikrocontroller.net/topic/327505#4450381

 

[engineer]

Was Ich noch nachwerfen möchte - allgemein und mit Bezug zu dem neuen Synth:

Wer meine Webseite 96khz.org verfolgt hat, der weiß, dass sie am Beginn mal gegründet wurde, um die 96kHz-Technik zu puschen - auch im Zusammenhang mit der SACD. Daher finden sich dort auch viele Grundlagenartikel zu dem Thema, die immer auch in Richtung "hohe Abtastrate", "hohe Auflösung", "Präzision" gehen und zeigen, dass man 96kHz wirklich begründen kann und ein SACD Sinn macht.

In den letzten Jahren hat sich die Sache aber so entwickelt, dass die Musikfans keineswegs einsehen (oder "einhören") dass 96kHz besser klingt. Nein, sie schmeißen sogar die CDs weg und hören MP3! Wir alle wissen aber, wie sehr dieses Format die Höhen beschneidet und verfälscht, am TV-Bild kann man das live sehen, was MPG4 (auch unter H.265!) über DVBT2 mit flachen Farbverläufen macht und das waren nur 8 oder 10 Bit in der Kamera und keine 24 wie beim Audio.

Es ist also so, dass ein Großteil der Hörerschaft ein kaputtes Gehör und/oder mangelnde Ansprüche hat. Wozu dann noch hochgenaue Klänge? Wozu dann noch Überabtastung beim Audio? Wir haben ja DSD-Audio, sowohl als Gerät, als auch als Download. Brauchen wir das? Hört das jemand? Nutzt das jemand?

Die Fakten: Man kann unter Zuhilfenahme akustisch - physiologischer Randbedingungen zeigen, dass man mit 24Bit/192kHz alles abtasten kann und darstellen kann, was der Mensch hören kann. Es ist sogar erheblich mehr, als die Lautsprecher wiedergeben können und somit stellt die Reduktion von DSD auf 24/192 keine Verschlechterung dar.

Will man nun einen solchen Datenstrom modulieren (und das tut man ja bei der Wavetable-Synthese) dann muss man entweder die 192kHz mit umständlicher Filterung umrechnen (was zu 100% geht!) oder man hinterlegt einen hochgesampelten Datenstrom. Genauer: Man nimmt sich exakt das. was der Delta-Sigma-Modulator im ADC-Chip liefert und dezimiert es nicht runter. Dann kann man sehr genau modulieren, ohne massiven Rechenaufwand zu haben. DAS ist der Vorteil der Überabtastung und der DSD-Datenströme.

Aaaaaaaaber: Wie bereit angedeutet, muss man das nicht so machen, sondern kann auch eine Mathematik bemühen, die das tut und die wäre in DSPs wieder billiger und einfacher ...

Uuuuuund: Versuche an der Hochschule Detmold haben ergeben, dass Viele keinen Unterschied hören zwischen DSD64 und normalen Wave-Dateien.

Die Schlussfolgerung: Es gibt:

a) wenig Kunden, denen es was bringen kann
b) wenige, die gute Monitorlautsprecher haben
c) wenige, die den Unterschied im Ergebnis hören
d) keinen absoluten Grund, einen FPGA einzusetzen.

Wenn man einen FPGA einsetzen muss, dann deshalb, weil man es so präzise braucht, wie Ich es tue (Industrie, Ultraschall, 500kHz) und dann kann / muss man auch mit hohen Raten abtasten. Ich habe dazu z.B. ein DSD512 für 192kHz Audio definiert und einen PDM-Wandler gebaut (also einen Standard, den es nicht gibt). Dieser ist durchaus in der Lage. präziser und fehlerfreier zu modulieren, als es mit "normaler" Technik ginge, einfach, weil die FIR-Filter zu lang werden und zu ineffektiv.

Das taugt aber nur für die hohen Frequenzen, wo sich die Geister scheiden. Für das, was unser Ohr hören kann, braucht man nur einen guten AA-Filter und Überabtastung mit 768kHz. Es würde also ein normaler Audio-DSP reichen, der mehrkanalig rechnet. Kostenpunkt €21,95

Oder aber man hat den Anspruch auf die Höhenrepräsentation, dann aber reicht der Faktor 32 (laut Interview) nicht aus. Ich nehme mal an, der ist auch nicht Folge einer Berechnung sondern einfach nur die FPGA-typischen 200MHz / 128 Stimmen also Soll. Da komme Ich auf 1,5MHz. Allerdings sind das nach meiner Rechnung nicht Faktor 32, sondern nur Faktor 8, denn Ich rechne mit 192kHz als Basisfrequenz. Anders ausgedrückt: Er sampelt gerade einen Faktor 2 höher, als Ich im Drum Computer. Ich habe das aber ausgerechnet und kann ingenieurwissenschaftlich zeigen, dass man damit auskommen kann. Liegt vor allem an meinem speziellen Digitalfilter! Er hätte also auch, wie Ich, 256 Stimmen einbauen können. Ist aber am Ende egal, weil man das beliebig einstellen und aufteilen könnte. Bei mir z.B. hängt es an den RAMs: Doppelte Stimmenzahl erfordert doppelte Zahl der RAMs und die sind limitiert.

Wie gesagt, bin Ich sketisch, ob diese hochauflösende Klangerzeugung erfolgreich sein wird. Die wurde ja auch schon anderweitig probiert und realisiert: http://ewms.scidata.eu/ewmsscidataeu-produkt Laut Explikation arbeitet er mit einem 128fach oversampling Wandler, offenbar auf Chip-basis. Der Takt liegt im Bereich von 2MHz, also auf ähnlichem Niveau. Er sampelt die Klänge auch mit einem dafür geeigneten Wandler, so wie er es erklärt und speichert die Daten mit einer Art RLE-Kompression mit voller Dynamik ab. Dieser Kira dürfte es ähnlich machen.

Ich persönlich würde dann aber - wenn man schon auf ideales Resampling setzen will - den Weg zu Ende denken und direkt DSD64 aufzeichnen. Das kommt aus jedem schnöden 44100er Wandler raus, hat mit fast 3MBit nochmal 50% headroom und entspricht im Takt in etwa den aktuellen MEMS-Mikrofonen. Dann kann man handelsübliche Audio-DSPs und I2S-Wandler direkt anschließen und fertig ist die Laube. Ein Fifo davor und einen gesteuerten PLL-Takt zum Abspielen. Dürfte nochmals genauer sein und man hat die Chance, direkt DSD-Material zu laden und zu verwenden und das in Echtzeit. Meine kann das

Ungeachtet dessen noch der Punkt:

Wichtiger, als eine genauere Klangerzeugung wäre ohnehin, mal das Thema Latenz anzugehen. DA ist nämlich der Hinkefuss in der Nutzung externer Synthesizer! Auch, wenn man heute über USB arbeitet, ist es trotzdem nicht möglich, mit einem Win-PC oder einem typischen Masterkeyboard wirklich "analog", also direkt reagierend zu spielen und es auch direkt wieder zu kriegen. Mich hat das schon immer gestört, vor allem, als man noch mit Standard-MIDI rumhampeln musste. Ich mache das so:

http://www.96khz.org/oldpages/enhancedmiditransmission.htm

Das System habe Ich schon um 2001 auf der Messe verschiedenen Herstellern vorgeschlagen, war aber kein Interesse. Die setzten auf USB 1.0 und klassischem MIDI. Genau so wenig, wie um 2005, als Ich das zuletzt probiert hatte, den Herstellern FPGAs nahezulegen - sprang bis auf einer keiner drauf an. Denen war das damals alles zuviel

Meines Erachtens wäre das wichtig gewesen, weil inzwischen viele Produzenten genau aus dem Grund die HW aus dem Setup geworfen haben: Man kriegt mit externer Hardware nur umständlich eine gute Integration in die DAW-Software hin. Die, die so produzieren, nehmen da nach wie vor Analogtechnik. "Der Digitalkram ist einfach zu langsam" durfte Ich mir erst vor Monatsfrist wieder anhören

Meine Klangerzeugung hat in der Version 3 maximal 375 - FPGA - Takte (inklusive 8-kanaligem DSP) = unter 2 us! Der Datentransport - auch das "MIDI" - erfolgt über S/PDIF, braucht also minimal 2 x 64 Takte = 20us. Weitere Latenz, wie bei USB, gibt es nicht.

Mal schauen, die Zeichen stehen aber nicht schlecht, dass es in naher Zukunft ein preisgünstiges FPGA-System als Zusatzmodul geben wird, ähnlich dem HOAX (Hammond Orgel im FPGA). Das frisst dann MIDI aus einem USB-Masterkeyboard und high speed MIDI aus einer VST-Schnittstelle. Ist gerade in Entwicklung. Der Vorteil gegenüber normalen MIDI-Geräten wird u.a. sein, dass Regler, die bedient werden, mit entsprechend hoher Rate übertragen und auch abgebildet werden. Mein S/PDIF MIDI kann standardmäßig 12 Bit pro Controller und nicht nur 8. Damit erfolgt die Aufzeichnung einer Potibewegung wie auch die Klangerzeugung so, wie man am Regler gedreht hat und nicht gerastert oder intern gesmoothed.

 

[Reinhard]

Da ist man einmal nicht auf der Musikmesse und dann das!

Habe mir das Youtube angehört: Die Flächen, die er ganz zu beginnt, greift, hören sich echt gut an. Der Rest ist aber nicht so vom Hocker hauend. Soll aber keine Wertung sein, YT komprimiert viel weg. Es ist jedenfalls interessant, daß Waldorf da sofort zuschlägt. Das muss demnach schon was Besonderes sein. Kann aber auch sein, daß sie das deshalb einkaufen, um sich den Markt zu sichern und zu vergrößern: Einfach schnell die Niesche selber besetzen, statt sie einem Konkurrenten zu überlassen. Die Sache ist ja die, dass es schon einiges an FPGAs in Synthesizern gibt und nur halt Waldorf da noch nichts hatte, oder?

Wie dem auch sei, es wurde ja langsam Zeit, dass mal wieder was Neues kommt! So ganz habe ich es aber noch nicht vestanden, was das Gerätchen können soll und wie es arbeitet. Auf der einen Seite lese ich was von VA-Synthese und auf der anderen Seite wieder "wavetable" - so die Verlautbarung von Waldorf. Widerspricht sich das nicht? Oder hat Waldorf einfach die eigene Technologie gemeint, die man zu der neuen addieren wird? "Wavetable" heißt für mich "Samples abspielen". Unter VA stelle Ich mir aber die tatsächliche Abbildung von Elektronik vor. Roland macht das angeblich in den clones der TB-Geräten so. Mit begrenztem Erfolg, wie man lesen kann.


Mit großem Interesse habe Ich den Beitrag von engineer gelesen, dem ich in weiten Teilen zustimmen kann. Ich habe dazu aber einige Anmerkungen:

a) Ich denke auch, dass der Markt für neue Geräte klein ist, aber exakt deshalb muss ein Hersteller etwas haben, was andere nicht haben. Das dürfte die Motivation von Waldorf sein. Man weiß ja, wie die Marketingmänner denken: Hauptsache, man vergrößert das portefolieo, egal, ob es im eigenen Stall entstanden ist, oder nicht. Stefan Stenzel dürfte nicht so begeistert sein, daß dort Konkurrenz eingekauft wird, die hätten sowas auch selber entwickelt, wenn sie gedurft hätten.

b) Deine technischen Erläuterungen verstehe Ich nicht 100%, aber ich entnehme, dass Du der Ansicht bist, man müsse noch höher abtasten. Dem würde ich mich anschließen und zwar mit der Begründung, dass das PDM-Audio, dass in den 1-Bit-Anlagen verwendet wird, heute schon höher gelagert ist. Was Du als DSD64 bezeichnest, ist nur der Mini-Standard aus der CD-Ära. Heute wird ein Vielfaches von 96kHz (256?) gemacht und Du selbst schreibst das indirekt ja auch. Meine Frage wäre, wie teuer es wäre, so ein Datenformat zu erzeugen und zu verwenden? Soweit ich es verstanden habe, geht das mit deiner Technologie.

c) In dem von Dir gelinkten Artikel in dem Microcontroller-Forum führst Du aus, dass sich Oszillatoren bis etwa 1/40 der Taktfrequenz bilden lassen. Wie passt das bitte mit der Tatsache zusammen, dass es gelingt, Audio bis 20kHz mit 48kHz abzubilden? Oder anders herum: Wenn ein FPGA es schafft, mit den angenommenen 200MHz in 40 Schritten einen Oszillator zu berechnen, dann würde dieser mit 5 MHz schwingen. Das wäre reichlich höher, als benötigt oder? Warum braucht man einmal diese hohe Frequenz und einmal nicht?

d) Welche von dir angesprochenen Möglichkeiten bestehen im FPGA, die in der Microcontroller-Welt nicht funktionieren? - abgesehen, von dem Tempo und der Menge an Stimmen. Ich bin selbst in der Branche tätig und habe eine gute Übersicht, über die Controller-Technik und würde generell sagen, dass man damit alles machen kann.

e) Wenn Du einen vollwertigen Synthesizer hast, solltest Du vlt. überlegen, den jemandem anzubieten. Die Zeit ist wohl reif dafür. Wenn das so leistungsfähig ist, gibt es da bestimmt Interessenten.

 

[Telefunky]

"Wavetable" heißt für mich "Samples abspielen". Unter VA stelle Ich mir aber die tatsächliche Abbildung von Elektronik vor.

genau das macht 'Wavetable' nicht - es geht um das Durchlaufen einer Wellensequenz, was dem permanten Wechsel der Oszillator-Wellenform entspricht. Der Durchlauf kann zeitlich und mit Überblendung moduliert werden.

VA Synthese ist ein allgemeiner Begriff, der lediglich das Nachbilden von analogen Ereignissen mit Digitaltechnik bezeichnet.
Das kann rein ergebnisbezogen erfolgen (ein Filter wird direkt berechnet) oder aber durch konkretes Modellieren der beteiligten analogen Schaltelemente (die analogen Komponenten des Filters werden modelliert).
Das Ergebnis hängt von der individuellen Umsetzung ab - weder die eine, noch die andere Methode ist per se leistungsfähiger oder 'besser'. Bauteile modellieren kommt aber besser an (Marketing) und ist wohl prestigeträchtiger...

 

[engineer]

"prestigeträchtiger" klingt gut

Zu dem Thema der generellen Möglichkeit der Modellierung von Elektronik habe Ich hier mal was verfasst:
http://www.keyboarder-forum.de/show...wieder-da-nach-30!!!-Jahren&p=86036#post86036

Tenor: Wenn man sehr genau modelliert, bekommt man in einem aktuellen FPGA gerade mal die Mathematik hin, um EINEN Transistor wirklich zu 99% genau zu berechnen. Alles, was schneller rechnet, z.B. pSPICE nutzt stark vereinfachte Modelle und selbst ein SPICE-Modell 2 eines MOS-Transistors ist schon viel zu komplex, um es in Echtzeit rechnen zu lassen. Ich habe das seinerzeit mit Visual C++ Einbindung gemacht. Um das real in Echtzeit zu machen, bräuchte es eine gigantische Abtastung im Femtosekundenbereich und mit Einschränkungen geht sich das in einem FPGA gerade so aus, damit es unter Betrachtung der 20kHz Grenzfrequenz beim Audio genau genug berechnet werden könnte.

Echtes VA bleibt also weiter Illusion

@Reinhard[/USER]: Hallo, Ich möchte den thread nicht kapern, daher zu der Inmarktbringung meines Systems nur soviel: Teile sind schon an mehreren Stellen verbaut und da wären auch rechtliche Dinge zu klären, bevor diese in eine selbstvermarktete Consumer-Hardware fließen können, was Ich aber angegangen habe. Was Ich sehe, ist ein plugin-Modul, indem Ich das mache, was eine echte Erweiterung der bisherigen Synths darstellt und das sich in OEM-Systeme integrieren lässt. Dabei sind aber auch technische Randbedingungen zu lösen, weil die typische Hardware, die die Orgeln, Synths und Masterkeyboards bereitstellen, nicht reicht, um meine HW zu nutzen. Es geht da vor allem um das MIDI, aber auch um die Art des "downmixes" in den Geräten und der Audioverarbeitung.

Ein plugin wird es auch deshalb, weil es recht aufwändig ist, Hardware rechtskonform darzustellen und zu vertreiben. Zudem ist ein Synthi, der von einem in Hardware unerfahrenen Nutzer gut bedient werden kann, mehr, als nur die Syntheseeinheit. Da gäbe es recht viel zu tun, um das direkt als Gerät hinzustellen. Letztlich ist das auch eine Kostenfrage: Die Zeit, um all das anzuleiern, was für ein komplette Geräteentwicklung nötig ist, kann Ich als Entwickler besser umsetzen, wenn Ich mein Knowhow konzentriert high-tech-Firmen zur Verfügung stellen

Was Ich plane, sind Module zum Selbstbau von eigenen Synths. Siehe meine Seite.


Jetzt aber zu der Frage mit Bezug auf die Wave-Thematik:

Wie gesagt, ist es kein mathematisches Problem, ein z.B. 24Bit/48kHz mit einem FIR-Filter "überabgetastet" im sub sample Bereich zu verschieben und damit in jede Frequenz inklusive Vibrato zu überführen. Das geht sowohl im Zeit- als auch im Frequenzbereich einfach, wenn man Signalverarbeitung verstanden hat.
Es ist aber vom Filteraufwand einfacher, wenn das Signal auf höhren Raten vorliegt. Daher DSD-Formate. Die lassen sich mit entsprechenden Dezimationsfiltern leicht umsampeln und durch variantes Abtasten direkt modulieren.

Ich habe mit der Methode in den 90ern Gleichlaufjitter von Tonbändern beseitigt. Dabei schwanken die Tonhöhen um weniger, als 1%, man muss also die Abtastung sehr weich und in geringem Umfang nachregeln. Dafür braucht man keine FPGAs. Wenn Ich aber eine so einfache Funktion, wie "hole was aus dem RAM und spiele es moduliert ab" vollziehen will, ist es mit FPGAs etwas einfacher und man hat die Option es sehr viel feiner zu machen, ohne auf aufwändige Filter zurückgreifen zu müssen.

Was mir dabei auffällt: Wenn es wirklich 32fache Überabtastung bei 1,5MHz ist, die dort verwendet wird, dann ist das Material auf 48kHz gesampelt und dann bereits in den Höhen lädiert! Wenn es dann auch noch auf 48kHz zurückgewandelt wird, hat man nochmal Verluste. In der digitalen Domäne ist das zwar perfekt, aber die Schwierigkeit ist bekanntlich das Rekonstruktionsfilter: Nur eine Oktave ist einfach zu wenig, um Passband und Stoppband sehr sauber zu trennen. Dann bringt die Geschichte nichts. Ich habe die Thematik schon an anderer Stelle durch, als Kunden versuchten, mit 96kHz Soundkarten Wellensynthese für Tests zu machen: Viele verstehen da die Grundlagen nicht so richtig, wie mir scheint.

Auch, wenn man das Signal überabtastet, wird der Informationsgehalt dadurch nicht besser. Im Eingangsmaterial schon mal gar nicht und auch im Ausgang nicht, weil das, was man durch die feinere Abtastung zwischenzeitlich an Fehlern beim Frequenzschieben weniger macht, am Ausgang wieder verloren geht. Das Fehlerspektrum ist nur ein anderes. Es wirken Faltungsfehler im Frequenzbereich, statt der Amplitudenfehler des FIR-Filters bei mathematischer Filterüberabtastung. Wenn man höhere Auflösungennutzen will, muss das Eingangsmaterial diese hohe zeitliche Auflösung haben.

Was Wavetable generell angeht, muss man sich näher damit befassen. Das ist in der Tat mehr, als nur gelooptes Abspielen der Samples. Ändert aber am Grundsachverhalt FPGA <-> CPU nichts.

 

[engineer]

Nun noch zu der anderen Frage nach den Oszillatoren:

Diese bestehen bekanntlich immer irgendwie aus rückgekoppelten Systemen und wenn man diese berechnen will, kann der nächste Rechen/Zeitschritt erst erfolgen, wenn die Rechnung durch ist. Ob man das per DSP macht, oder CPU oder im FPGA, ist reichlich egal. Der Unterschied ist aber, dass CPUs alles nacheinander machen, wenig Zwischenspeicher haben und vebrauchen. Der FPGA hingegen muss jede Rechnung als Hardwareobjekt aufbauen, alles statisch zwischenspeichern, was dann alles auch permanent vorhanden sind und (gfs ungenutzt) arbeiten. Das führt letzlich dazu, dass es im FPGA eine echte reale Rückkopplung gibt und die in den Objekten "unterwegs" liegenden Daten in einer pipeline laufen, also mehrere in einander verschachtelte Kanäle bearbeiten können.

Bei den angenommenen 40 Schritten (DGL 2.Ordnung mit Filter und Parametern) kriegt man also 40 Kanäle heraus, die nichts voneinander wissen (dürfen).
Die Abtastrate sind dann in der Tat 5MHz, d.h. mit der Frequenz erfolgt die Berechnung des Oszillators. Denkt man sich einen Sinus aus dann z.B. 50 solcher Punkte, bekommt man einen 1MHz Sinus. Da die Berechnung sehr fein erfolgt, sind die Fehler klein und man kann auch einen Sinus aus 50,11 Punkten exakt berechnen. Die Granularität fällt dabei weg, bzw besteht nur in der Auflösung der Y-Achse. Es gibt nur ein Faltungsspektrum mit den 5MHz.

Mit einer CPU geht das prinzipiell erst einmal genau so fein, allerdings nimmt der Rechenaufwand ganz anders zu: Mit einer Intel CPU ist eine Stimme sogar in erheblich weniger Schritten zu berechnen, weil die in einem Takt 64 Bit kann. Bei dann nur z.B. 30 Schritten käme man bei einer 3GHz-CPU auf immerhin 100MHz Abtastung, d.h. die CPU ist sogar ABSOLUT schneller, als der FPGA und in einem mir bekannten Fall benutzt ein Hersteller auch solche CPUs, um hohe Raten so günstig zu erzeugen.

Eine echte PC-CPU macht aber zu 50% was anderes und geht zudem bei mehreren Rechnungen "parallel" schnell in die Knie, weil sie über den Cache und sogar das externe RAM gehen muss. Dann dividiert sich die Sache schnell herunter. Nehmen wir 60 Schritte inklusive der RAM-Zugriffe, 50% CPU Zeit zum Rechnen, macht noch 25 MHz. Geschätzt bei 5 Stimmen dürfte dann Ende sein, während der FPGA wie gesagt 40 packt. Man bräuchte auf der PC-Seite also einen perfekt belasteten 8 Kerner, um dagegen zu halten.

Der Unterschied an der Stelle ist also erst einmal eine reine Frage der Kosten und Stimmenzahl. Wenn man 32 solcher Stimmen bauen will, würde Ich eine CPU nehmen. Hinzu kommt der in einigen Anwendungen wichtigen Punkt, dass die CPU jede Stimme etwas anders berechnen könnte, der FPGA aber immer dieselbe Struktur hat und strukturelle Veriationen der Rechnung immer in einem "nutzen" oder "nicht benutzen" und damit verschwendetem Platz münden. Das wäre bei solchen Synthese-Apps aber nicht relevant, weil alle Stimmen eines Instruments ja dieselben Optionen brauchen.

Was es jetzt noch zu berechnen gäbe, ist, ob in einen FPGA mehrere solcher Recheneinheiten passen und was der im Vergleich zur CPU kostet, was die Restelektronik kostet und wie einfach es ist, die Daten rein und rauszubekommen. Mit der Argumentation "mein Spiele-PC ist ohnehin da" dürfte der FPGA immer verlieren
--- Beiträge wurden zusammengefasst ---
Und nun zu der Frage, warum man überhaupt die Rechnungem mit MHz abtasten muss,:

Das ist so zu beantworten, dass man bei der iterativen numerischen Berechnung auch Gleichungen benutzen kann, die nicht analytisch lösbar sind und die sind bei VA wichtig. Alles, was man als f(t) direkt angeben kann, ist auch mit der realen Abtastrate vollkommen exakt zu berechnen. Ist dann nur noch eine Frage, ob man alles rechtzeitg schafft. Es läuft aber immer auf eine mehr oder wenige lange Rechnung hinaus, die einen definierten Wert pro Zeiteinheit liefert. Der ist dann auch exakt! Überabtastung braucht man dann nur einen Faktor 3-5 wegen Nyquist.

Gerade diese numerische Rechnung ist aber wichtig für die Echtzeitmanipulation eines Oszilators und das Wirken von nichtlinearen Komponenten wie Magnetik, Sättigung, Verluste etc. Es ist z.B. sehr einfach möglich, auf diese Weise zwei Feder-Masse-Systeme zu formulieren und gegeneinander arbeiten zu lassen und sich die resultierende Schwingung anzusehen. Wollte man diese "gekoppelten Pendel" mit Mathematik beschreiben, mündet das in eine DGL, die enormen Rechenaufwand hat und sie wäre ungenau, weil sich dynamische Verluste kaum realisieren lassen. Verluste sind aber das Allerwichtigste bei Oszillatoren und analogen Filtern, damit sie echt klingen.

Damit die Rechnung hinhaut, muss auch sehr genau gerechnet und hochaufgelöst gespeichert werden und da reichen im FPGA z.B. die 18x25 Bit, die man z.B. in einem Spartan bei den Multipliern hat, nur lokal aus. D.h. man muss kaskadieren oder skalieren, was den Aufwand in die Höhe treibt. Vor allem muss man sehr gut und intelligent runden, damit keine Fehler kummulieren und die Integrale der Oszillatoren in die Wiese laufen. Hinzu kommt eine dynamische Fehlerbehandlung, die entstehende Rechenfehler glättet, damit nichts ungewollt schwingt. Wenn man sich das Ergebnis so ansieht, macht das dann 60% der Schaltung aus

Beispiel eines einfachen Oszillators im FPGA: http://96khz.org/doc/vasynthesisrolandjp8080.htm

Bevor Rückfragen kommen, nein, es ist nicht so richtig gelungen, den Klang der 8080 nachzustellen

 

[Reinhard]

@engeneer: Danke für die ausführen Infos.

@Telefunky: Wenn ich dich richtig verstehe, würdes du also auch das Aufzeichnen eines Analogklangs und Wiedergeben als Synthese sehen? Wie kann das geschehen, bei den vielen Verhaltensoptionen einer echten Elektronik?

@all: Hat der Walkürensynthesizer eigentlich eine HP? Ich finde dazu nichts. Ich hätte gerne einige echte Samples angehört. Per MPG ist das ja schwierig.

 

[Telefunky]

Wenn ich dich richtig verstehe, würdes du also auch das Aufzeichnen eines Analogklangs und Wiedergeben als Synthese sehen? Wie kann das geschehen, bei den vielen Verhaltensoptionen einer echten Elektronik?

der Begriff der Wavetable Synthese stammt nicht von mir... aber dort werden ua auch analoge Wellenformen aufgezeichnet und später durch modifizierte Wiedergabe neue Klänge erzeugt.

Allerding deutet der zweite Satz in eine ganz andere Richtung - der scheint sich auf typische analoge Synthesizer zu beziehen, die von sich aus Klänge erzeugen.

Ich habe selbst eine Minimoog Emulation, bei der (afaik) das Filter anhand der Schaltung modelliert wurde (Creamware Minimax), mit sehr gutem Erfolg.
Vielleicht nicht mathematisch perfekt, aber immerhin so treffend, dass praktisch kein Hörer den Unterschied zum Original heraushören konnte.
(zumindest wurde das Filter in dieser Hinsicht nie kritisiert, sondern bestimmte Einschwing- und Anschlagsanomalien die Besitzern des Originals auffielen - Elemente, die man nicht explizit modelliert hat)

Das relativ überschaubare Moog Kaskadenfilter soll bereits ziehmlich aufwendig gewesen sein - irgendwann steht das dann in keinem sinnvollen Verhältnis mehr zum Ergebnis.
(der Korrektheit halber: ob die Oszillatoren ebenfalls diese 'in circuit emulation' bekommen haben, entzieht sich meinem Gedächtnis, der kompletten Synth wurde jedenfalls nicht in Einzelkomponenten simuliert)

Ich sehe das durchaus ähnlich, was das 'Verhalten von Elektronik' angeht. Deswegen habe ich ja einen 'echten' Casio 8bit Sampler.