Waldorf Kyra Synth - (Valkyrie) 2018-2023

View post --
Waldorf wird den Valkyrie bauen und mit neuem Design dann 2019 bringen zur NAMM

und jetzt 2023 - abgekündigt.


was war nochmal: Exodus Digital Valkyrie?

Waldorf-Kyra.jpeg
 
Zuletzt bearbeitet:
Der Tom Shoebridge's hat schön zu reden :) Aber am Sinn hat er nichts geändert :) So wie Doctor Mix und die andere, die Produkte quasi schön reden.... Die eigene Ohren sind immer entscheidend :)
Finde das Fazit von Tim S. (nicht Tom) schon sehr kritisch. Einen sehr schlechten Sound nehme ich auch nicht wahr, habe aber keine eigenen Erfahrungen mit dem Gerät, er spricht mich aber nicht wirklich an.

Doctor Mix... ja, das ist auch so einer, den ich nicht wirklich ernst nehmen kann. Das Schönreden fällt wirklich bei einigen auf, das kann man aber mittlerweile recht gut einschätzen finde ich.

Hätte ich noch einen Virus würde der Kyra ihn wohl nicht ersetzen, würde der Kyra näher am mQ/Q sein, dann würde ich schwach werden.
 
Was Du hier schreibst, @JS-Sound, mag Deine Ansicht sein und für Deinen Geschmack gelten, es ist ansonsten aber Polemik ohne jede sachliche Grundlage. Die Kyra ist ein 8fach multitimbraler Synth, der Dir sicher immer volle 128 Stimmen liefert. Das kann so genau kein anderer Synth auf dem Markt. Der Preis pro Stimme ist einer der niedrigsten auf dem kompletten Synth-Markt. Schlägt sogar Behringer noch um Längen.

Ist scheinbar eher was für Freunde des eher cleanen Sounds, die FPGA Oszillatoren werden entsprechend kosten (???), dafür sollen sie auch weitgehend aliasing frei sein.
Die gesamte Klangerzeugung einschließlich der Filter, Hüllkurven, VCAs usw. wird in dem FPGA berechnet. Nur die Effekte sind DSP-basiert. Ja, der Klang ist zu 100% frei von Aliasing - jedenfalls sofern ich meinen Ohren trauen kann. Ansonsten clean (wenn gewünscht) und berechenbar "dirty", wenn entsprechend programmiert.

Die Kosten erklären sich wohl eher durch den immensen Entwicklungsaufwand, als allein durch die Hardware oder die Produktionskosten. Aller Voraussicht nach wird beim jetzigen Preis damit niemand jemals wirklich etwas verdienen, nicht Waldorf und auch nicht der Entwickler. Er wird wohl niemals einen halbwegs akzeptablen Arbeitslohn für seine Arbeit an der Entwicklung der Kyra erzielen. So jedenfalls habe ich ihn im Gespräch verstanden - er hat das nur durch die Blume gesagt. Einige Leute haben offenbar komplett falsche Vorstellungen. Etwas wie die Kyra ist mehr oder weniger ein reines Liebhaber-Projekt. Wenn man dafür Geld ausgibt, erhält man ein hochwertiges Instrument und unterstützt Menschen, die noch die Initiative haben, technisch etwas wirklich Neues zu wagen.

Ja, aber bei dem was ich gerne mit dem mache geht die polyfonie von TI1 gut in die Knie - da bin ich froh wenn ich am Ende noch 8-Stimmen hab' ;-) Bin halt eher mit Formant-/Grain-Wavetables unterwegs und weniger mit dem Classic Virus Oszillator Modell.
Genau. Technisch liegen Welten zwischen Virus und Kyra. Es ist ungefähr so, als würde man einen Mac mit Power-PC G4 mit einem heutigen M1-Mac vergleichen.
 
Zuletzt bearbeitet:
Ich hab' hier auch noch einen XP Rechner stehen, weil darauf die Software läuft die ich brauche ;-)
Ja klar, so war das ja nicht gemeint ;-) ... Aber der Vergleich passt ganz gut. Auch ein Virus hat natürlich noch seine Berechtigung, wenn man den Klang oder die speziellen Möglichkeiten eben besonders mag. Nur technisch gesehen ist er eben Steinzeit verglichen mit der Kyra. ... Na ja, sagen wir Eisenzeit. ;-) ...
 
Zuletzt bearbeitet:
Aeh ... da läuft aber nur die Steuerungslogik drauf und evtl. noch ein paar Envelopes und LFOs. Die Synthese ist entweder Analog, oder DSP, FPGA ... und nur in Ausnnahmen auf ziemlich flotten ARM prozessoren ...

Spielt aber für den Kyra überhaupt keine Rolle, der hat sogar beides. FPGA und ARM, und wenn die das nicht ganz falsch angestellt haben, dann ist das sogar nur ein Chip in dem beides ist (Cyclone Serie von Intel z.B.).

Der wesentliche unterschied zwischen DSP/CPU und FPGA ist, daß ein FPGA alles parallel verarbeitet. Das heißt, wenn man 128 Oscillatoren hat, dann arbeiten die eben nicht nur pseudoparallel (das kann eine CPU eben nicht), sondern wirklich parallel. Gleiches gilt für alle Filter, alle VCAs etc. pp.

Was mich am Kyra eigentlich abhält ist, daß es eben ein Hobby Projekt ist. Leider merkt man das in der "Liebe" die der Synth von Waldorf bzw. dem Entwickler bekommt. Man sollte eigentlich annehmen, daß der Entwickler da was dran entwickelt - ist aber leider nicht der Fall.

Auch dieser Synth wurde nun letztendlich released und die Bugs bleiben ungelöst.

Wenn ihr mich fragt, dann wird an dem Synthesizer nichts mehr gemacht. Walldorf macht noch Hardware Support, ansonsten nichts. Und das ist für einen FPGA synth, der ja eigentlich alles dann programmierbar (also irgendwie auch Software) macht ziemlich traurig.
 
Auch dieser Synth wurde nun letztendlich released und die Bugs bleiben ungelöst.

Wenn ihr mich fragt, dann wird an dem Synthesizer nichts mehr gemacht. Walldorf macht noch Hardware Support, ansonsten nichts. Und das ist für einen FPGA synth, der ja eigentlich alles dann programmierbar (also irgendwie auch Software) macht ziemlich traurig.
Welche Bugs denn? Es gibt einige Dinge, die der ein oder andere vermisst oder gerne hätte, aber von wirklichen "Bugs" ist mir nichts bekannt.

Ob neue Features kommen, muss man abwarten. Ich denke, für Manuel Caballero ist der Synth im Prinzip so "vollendet", wie er zurzeit ist. Er hat aber gesagt, dass er natürlich auf Wünsche der Anwender eingehen und ggf. Features nachreichen wird. Bzgl. der LFOs und der Velocity z.B. ist das ja auch geschehen. Ob noch Weiteres kommt oder nicht, weiß nur er - alles andere ist Spekulation.
 
Also weder "wirkliche Bugs", noch sonstige Bugs hab ich bislang in den ganzen Monaten, bei fast täglicher h-langer Nutzung festellen können. Ich benutz Kyra aber auch nur via Midi. Wie es sich bei
intensiver USB/DAW Anbindung verhält, weiß ich nicht. Selbst bei vollen Midispuren läuft Kyra problemlos. Da bleibt eher mal der Peak oder Blofeld hängen. Kyra noch nie.
Grade die Kombo Deluge/Kyra is genial :)
Wie's allerdings mit Updates aussieht, steht in den Sternen.... :mrgreen:
 
Ich vermute, das ein Update des FPGA Teils für die meisten Anwender eher unfreundlich ist.
Der Bitstream (die Daten für den FPGA) ist proprietär, d.h., man benötigt im Falle von Altera deren Quartus Software (mit dem Tool wird das "Innenleben" des FPGAs designt).
Es gibt eine abgespeckte Variante hiervon, aber so ganz simpel ist es für den unbedarften Endanwender nicht - besonders für Mac User.

Hier kann man sich den Prozess am Beispiel des Rainmakers oder Shapeshifter mal anschauen.

Das wird man bei Waldorf dem Kunden nicht zumuten wollen.
 
Aeh .. jetzt verwechselst Du bitstream erstellung mit Update. Für die Erstellung, also .vhdl code in ein bitstream image für den FPGA braucht man die richtige Software (z.B. Quartus). Für das aufspielen des Images eher nicht.

Novation zeigt wie es geht, schließlich sind da auch wesentliche Teile des Klanges in einem FPGA implementiert (OSC, Effekte).

Das ist total einfach. einfach mit der Software per USB auf den Synth hochladen - fertig. Das funktioniert wirklich super.

Habe hier ein Altera Cyclone V Testboard (MISTer lässt grüßen). Die Prozedur ist dort auch fertig eingestellt. Letztenendes ist der FPGA nach dem Booten immer leer und muss erst mal mit Informationen gefüllt werden (programmiert werden). Und zwar jedes mal - nicht nur einmal. Das heißt das Bitstream Image liegt irgendwo im FLASH des ARM cores und der nimmt das dann beim Booten und stopft es dem FPGA rein.

Der User muss da gar nichts machen und das Update würde nur bedeuten, daß man dem ARM core ein neues Image gibt, der es beim booten dann in den Flash schreibt.
 
Aeh .. jetzt verwechselst Du bitstream erstellung mit Update. Für die Erstellung, also .vhdl code in ein bitstream image für den FPGA braucht man die richtige Software (z.B. Quartus). Für das aufspielen des Images eher nicht.
Es gibt meines Wissens nach keine 3rd Party Software zum Flashen der Daten (weder bei Xilinx noch bei Altera, bei Lattice sieht es afaik besser aus).
Ist Dir eine bekannt - wäre interessant.
Vielleicht hat sich Novation was exklusiv von Altera erstellen lassen - wer weiß?

Ich frage mich aber ernsthaft, warum es bei Intellijel so kompliziert gemacht wird (das Video hast Du gesehen?), wenn es - wie Du sagst - einfacher gehen könnte.

Achja, ich habe hier ein älteres SPARTAN3 Board herumfliegen - ich bin nicht ganz jungfräulich im Umgang mit FPGAs.
Es ist nur ewig her und entworfen habe ich mit VHDL auf einem sehr bescheidenen Niveau.
... und das Update würde nur bedeuten, daß man dem ARM core ein neues Image gibt, der es beim booten dann in den Flash schreibt
Hm, vielleicht liegt hier der Unterschied - die im Rainmaker/ Shapeshifter verbauten Boards sind reine FPGAs - ohne ARM Core.

Edit:
Auf dem Trägerboard selbst sitzt ein ARM - der separat geflasht werden muss.
 
Zuletzt bearbeitet:
@Jeltz - Das Update auf Firmware 1.78 ist simpel. Hier wurden neue Funktionen für die LFOs implementiert und die Velocity regelbar gemacht. Da diese Dinge bei der Kyra in dem FPGA errechnet werden, scheint es also kein grundsätzliches Problem zu geben, hier auf einfachem Wege Updates vorzunehmen.

@SerErris - Der Vergleich mit Novation hinkt m.E. etwas, da bei Peak und Summit meines Wissens nur die OSCs mit Hilfe des FPGAs errechnet werden. Der restliche Signalweg ist analog bzw. die Effekte kommen doch (wie bei der Kyra) aus einem DSP, oder nicht?
 
@Jeltz,

ohne CPU kann man einen FPGA nicht verwenden. Der wird bei jedem Booten geflashed, wie schon gesagt. Dazu muss man auf irgendeiner CPU bzw. Microcontroller ein Programm laden, daß dann den FPGA initialisiert und ihm das Programm gibt.

Das starten des FPGA und das erstellen des Bitstreams sind zwei verschiedene Sachen, wie schon beschrieben. Wie die Routine der CPU geschrieben wird, daß die den FPGA initialisiert ist einfach Sache des Herstellers. Wenn man sich das einfach machen möchte, dann nimmt man eine komplett Lösung (Cyclone etc). Da ist auch das schon vorgedacht. Es gibt ein kleines Linux OS für den ARM teil und der kann dann den FPGA initialisieren mit jedem beliebigen Image. Beides liegt dann auf einer SD Card oder in einem Flash.

Vom Hersteller wird dann das Image bereitgestellt und muss dann nur noch auf den Synth gebracht werden. Wie gesagt das ist was ganz anderes als den Bitstream erst mal herzustellen. Dazu braucht man FPGA individuelle toolchains.

@Horn: Nein, der Peak und auch der Summit haben die OSC und die Effekte in FPGA implementiert. Der Peak hat keinen DSP. Wenn mann schon auf einen FPGA setzt, dann kann man auch leicht die Effekte in FPGA implementieren, das ist nicht weiter schwer und bietet sich gradezu förmlich an. Grade in diesem Hinblick ist die Implementierung des Summit so unverständlich (serielle Effektchain verbuggt).

Aber das soll es dann hier auch wirklich dazu gewesen sein. Es ändert an der ganzen Sache ja nichts.
 
ohne CPU kann man einen FPGA nicht verwenden.
Sorry, das kann man nicht so verallgemeinern. Ein FPGA kann sich serwohl selber um den Bootvorgang kümmern (oft per JTAG, die Platform Flash IC haben das passende Interface an Board).
Da ist keine CPU nötig, aber natürlich kann man eine verwenden.

Aber das ist in der Tat mächtig OT.
 
Zuletzt bearbeitet:
Ist scheinbar eher was für Freunde des eher cleanen Sounds, die FPGA Oszillatoren werden entsprechend kosten (???), dafür sollen sie auch weitgehend aliasing frei sein.

Der große Vorteil ist der, dass man Schaltungen in FPGAs (in dem Typ, der in der KYRA verwendet wird) mit grob 200MHz laufen lassen kann. Bedeutet, man kann alle Gleichungen quasi-Analog benutzen nach Euler-Cauchy integrieren und differenzieren, bzw iterative Lösungen suchen. Damit bekommt man sehr hohe Abtastraten hin, die es erlauben, einfache Gleichungen mit 192kHz zu produzieren und/oder gleich mehrere Kanäle zu generieren. Laut dem Entwickler verwendet er partiell eine 32-fache Überabtastung. Wären also 1536kHz. Ich benutze 768kHz mit entsprechendem AA-Filtern. Man kan zeigen, dass das ausreichend ist, um analoges Audio zu repräsentieren, ohne Artefakte / Aliasing zu bekommen.


Das heißt aber nicht, dass die Werteverläufe automatisch aliasing-frei sind - nur weil FPGAs benutzt werden. Auch dort sind es letztlich virtuelle Oszillatoren, also digitale Schaltungen mit FlipFlops und Kombinatorik, die diskret rechnen und erst mal nicht mehr Genauigkeit bringen, als DSPs. Im Gegenteil: Mit 64-Bit Systemen ist der Aufrechterhalt der Genauigkeit sogar einfacher, als in FPGAs, weil die dort (Artix, Zynq) verbauten Multiptizierer nur 25x18 Bit können und oft kaskadiert werden müssen.

Zu den Kosten: Solche Bausteine, also z.B. der Xilinx-Zynq (Kyra) oder ein Xilinx-Artix (gleiche Technik wie Zynq nur ohne integrierte ARM-CPU) liegen im Bereich von 50,- ... 150,- Euro das Stück. Eine vollständige Platine mit einem DDR3-Ram, Flash und Pwer, die autark arbeitet, gibt es im Handel zwischen 100,- und 350,- Euro. Ich benutze für meinen FPGA-Synth welche mit einem Artix-200 zu 280 Netto. In dem sind über 700 Multiplizierer vorhanden. Ein typischer idealer Oszillator, der wie ein mechanischer Schwinger nach DGL 2.Ordnung funktioniert, benötigt deren 6..8 je nach Genauigkeit. Die Version die ich verwende, welche mehrere Parameter für nichtsättigende Dämpfung und Reibung hat, wie sie bei Saiten und Blechschwingung benötigt werden (2-fach gekoppelte DGL3 mit Rückkopplung) braucht 12 solcher Multiplizierer. Mit einem solchen Oszillator kann man dann wegen der Rückkopplungen "nur" alle 20 .. 30 Takte einen Wert erzeugen. Macht so etwa 10MHz "Rechenfrequenz". Damit bekommt man für einen Sinus, der mit 10 kHz schwingen soll, immerhin 1000 Punkte. Das ist schon sehr "analog". Anteiliger Preis: 3 Euro !

Letztlich kommt es darauf an, wie komplziert der Erbauer seine Schaltung gestaltet und wie genau er z.B. Elektronik nachbaut. Da gibt es eine große Bandbreite.

Wer sich dafür interessiert: Mein MOOG-Filter braucht - wenn es so einigermaßen genau arbeiten soll - bei dieser Timing-Konstellation minimal fast 15% eines solchen FPGAs und berechnet dann z.B. 32 Kanäle gleichzeitig. Das sind rechnerisch noch 1,50 Euro je Kanal! Wenn ich aber anfange, richtige Transistorgleichungen wie z.B. Gummel-Poon zu nehmen, wird nicht nur der FPGA halb voll, sondern er packt auch nur noch 2 Kanäle mit ausreichender Frequenz, dass es für 20kHz "ehrliche" Bandbreite reicht. Damit kostet das Filter schon schlappe €25,00 ;-) Da ist der Aufbau in echter Elektronik nach wie vor billiger. :cool:

Und Gleichungen, wie wir sie aus der Halbleiterelektronik kennen, z.B. das vereinfachte SRH-Modell, sind gar nicht mehr in Echtzeit zu berechnen, ober man bräuchte etliche FPGAs parallel. Man kann sich also leicht ausrechnen, wie "genau" und "echt" digitale Nachbildungen von solchen Filtern- und Verzerrern sind und wie einfach sie gebaut sind, wenn sie von der DAW per plugin berechnet werden.

Beispiel zur digitalen Modellierung von analogen Schaltungen:
 
Ich glaube der wesentliche unterschied macht sich erst mit mehreren OSC bemerkbar. Währen ein DSP eine CPU ist und somit eben nur sequentiell dinge bearbeitet, kann ein FPGA jeden Oszillator tatsächlich parallel verarbeiten. So lange man genug Multiplizierer hat für die Gesamtaufgabe kann man die alle gleichzeitig laufen lassen. Es gibt also keinen Qualitätsverlust bei den OSC wenn man mehrere hat und auch keine Latenzen oder Phasenverschiebung.

Wenn man die ganze Signalkett in FPGAs unterbringt, dann sitzen die weiteren Teile natürlich hintereinander (also auch Sequentiell), aber tatsächlich ist dann jeder Audiokanal wieder vollständig parallel.

Wenn man sich einen OSC - Filter - VCA in Reihe vorstellt, so wird nur der Audio Teil weitergereicht, aber trotzdem verarbeiten alle ihre Schritte immer gleichzeitig.

Um es besser darzustellen: Eine CPU/DSP muß zuerst den OSC berechnen, dann schwenkt er zum Filter und dann zum VCA, dann beginnt er wieder mit dem OSC. Also immer nur eines von allem. Wenn das dann 32 OSC-Filter-VCA sind, dann ist die Reihenfolge erst 1. OSC, 2.OSC ... 32. OSC, 1.Filter ... usw. oder 1. OSC, 1. Filter, 1.VCA, 2. OSC, 2.Filte, 2.VCA. Alles gleichzeitig geht halt einfach nicht, auch nicht mit Multicore Prozessoren (ein bissl).

Man kann also sehen, daß wenn man z.B. immer eine komplette Voice rechnen würde, dass es zu Phasenverschiebung zwischen den Voices kommt...

Wenn wir uns eine Sinuswelle vorstellen, die sagen wir mal 1000ms Frequenz hat. Und eine Berechnung von einer Voice 30ms dauert, dann ist Voice 1 bei 30ms fertig, Voice2 bei 60 ms, Voice3 bei 90 ms, usw. Das bedeutet gleichzeitig daß eben alle Voices um 11,8° verschoben sind. Das ist schon ne Menge und wenn man einfach nur ne Sinus Welle hätte, dann würden sich die Voice 1 und die Voice 15 sich gegenseitig überlagern und auslöschen.

TLDR:
Ein FPGA kann alles parallel verarbeiten (alles ist Hardware und somit gleichzusetzen wie diskrete Bausteine in analogen Signalketten.) Das ist die eigentliche Stärke gegenüber DSPs.
 
Da lief schon zu Single Core DSP Zeiten 'ne Menge parallel, das war ja der große Vorteil der damaligen DSPs, mehrere Berechnungen gleichzeitig in einem Schritt ausführen zu können. Ich bin eher davon ausgegangen dass jeweils Oszillatoren, Modulatoren (LFO&Envelope &Co), Filter etc. gleichzeitig berechnet werden und nicht pro Stimme gearbeitet wird. Afair kann man z.B. bei N.I. Massive davon ausgehen dass die Last für weitere Stimmen - dank der Parallelisierung durch div. DSP Funktionen neuerer Prozessoren - jeweils 4rer Schritten angestiegen ist.
 
Da lief schon zu Single Core DSP Zeiten 'ne Menge parallel, das war ja der große Vorteil der damaligen DSPs, mehrere Berechnungen gleichzeitig in einem Schritt ausführen zu können. Ich bin eher davon ausgegangen dass jeweils Oszillatoren, Modulatoren (LFO&Envelope &Co), Filter etc. gleichzeitig berechnet werden und nicht pro Stimme gearbeitet wird. Afair kann man z.B. bei N.I. Massive davon ausgehen dass die Last für weitere Stimmen - dank der Parallelisierung durch div. DSP Funktionen neuerer Prozessoren - jeweils 4rer Schritten angestiegen ist.

Prozessoren haben keine DSP Funktionen ... Prozessoren haben mehrere Kerne, die dann parallel was berechnen können. Aber da ist ziemlich schnell Schluss. Jeder einzelne Prozessor kann alles nur sequentiell berechnen und ein DSP je "kern" besser evtl. Thread auch nur sequentiell. Diese Parallelität ist sehr schnell am Ende ... Man kann in keinem Fall die gleiche Parallelität wie in einem FPGA erreichen.
 
Prozessoren haben keine DSP Funktionen ...
Hier wird beschrieben was ich meine, das ist auch nicht groß anders als die Befehle die man von Motorola bzw. Freescale DSPs kennt, wobei es schon wieder über 25 Jahre her ist dass ich mir den Assembler zum 56001 im Falcon angeschaut hab.


Siehe auch, wobei da afair noch ein paar mehr Befehlsgruppen dazu gekommen sind als im Artikel beschrieben.


Elemente von DSPs finden sich auch zunehmend in Desktop-CPUs wieder, wie zum Beispiel in den AltiVec-Erweiterungen des PowerPC oder (abgeschwächt) in den SIMD-Erweiterungen von Intel und AMD. Dies liegt an der zunehmenden Verbreitung von Multimedia-Inhalten; Datenformate wie das JPEG-Format, MP3 oder MPEG2 erfordern eine DCT-Kodierung beziehungsweise -Dekodierung, deren Berechnung eigentlich eine klassische DSP-Aufgabe ist. Auch die Berechnung der immer weiter verbreiteten Verschlüsselung profitiert von diesen Befehlssatz-Erweiterungen. Auch im Bereich der Embedded Systeme werden die Microcontroller durch DSP-Funktionalitäten ergänzt, wodurch die Rechenleistung gesteigert und der Stromverbrauch gesenkt werden kann. Typische Beispiele sind der Arm Cortex-M4, die Erweiterung NEON bei den großen Arm Cortex-Cores, der dsPIC von Microchip sowie die XS1-Serie von XMOS.

Edit: Zitat:
Programme können mithilfe von AVX und dessen 256 bit breiten Register im x64 Modus bei jedem Takt vier Fließkommaoperationen mit doppelter Genauigkeit und acht Fließkommaoperationen mit einfacher Genauigkeit bei bspw. einer einfachen Addition berechnen. Dabei befinden sich jeweils vier Werte doppelter Genauigkeit oder acht Werte einfacher Genauigkeit in jeweils einem der 16 AVX Register, die dann mit jeweils einem Partner verrechnet werden.
 
Zuletzt bearbeitet:
Ja SIMD ist schon hübsch ... aber wie gesagt .. ein FPGA macht das alles in einem Schritt. ..

Ein FPGA is einfach ganz anders als eine CPU, nicht zu vergleichen. Man kann ganze ketten von Dingen basteln und alles passiert immer genau gleichzeitig.

Ja, CPUs sind viel besser geworden, aber das was mit einem FPGA möglich ist wird nicht mit einer CPU möglich sein. CPUs machen das halt mit viel höherem Speed wieder gut, aber wenn es eben um gleichzeitig geht, dann ist das gleichzeitig eben auch limitiert. Und ausserdem will man ja auch keine SIMD CPU einbauen ...

Die angesprochenen Befehlserweiterungen gibt es eben auf den klassischen Desktop/Server CPUs. Die sind aber extrem teuer im vergleich. Wie wir ja wissen (Korg Wavestate) kann an das auch mit einem RASPI machen :)
 
Die angesprochenen Befehlserweiterungen gibt es eben auf den klassischen Desktop/Server CPUs. Die sind aber extrem teuer im vergleich. Wie wir ja wissen (Korg Wavestate) kann an das auch mit einem RASPI machen :)
Ja - der Cortex-A53 hat wohl auch div. DSP Erweiterungen, daher wird die Plattform wahrscheinlich auch gerne als DSP Ersatz eingesetzt.

Quelle: https://developer.arm.com/ip-products/processors/cortex-a/cortex-a53

ArchitectureArmv8-A
Multicore1-4x Symmetrical Multiprocessing (SMP) within a single processor cluster, and multiple coherent SMP processor clusters through AMBA 4 technology
ISA Support
  • AArch32 for full backward compatibility with Armv7
  • AArch64 for 64-bit support and new architectural features
  • TrustZone security technology
  • Neon advanced SIMD
  • DSP & SIMD extensions
  • VFPv4 floating point
  • Hardware virtualization support
Debug and Trace
CoreSight DK-A53
 
Zuletzt bearbeitet:
So lange man genug Multiplizierer hat für die Gesamtaufgabe kann man die alle gleichzeitig laufen lassen. Es gibt also keinen Qualitätsverlust bei den OSC wenn man mehrere hat und auch keine Latenzen oder Phasenverschiebung.
Das gilt aber nur, wenn man es quasi-analog ausgeben will, wie bei HF-Anwendungen. Da das digitale Audio meistens mit 192kHz auf DACs geht, es ist vollkommen ausreichend, als 5us ein Sample fertig zu haben, egal wie zeitversetzt mehrere Kanäle berechnet werden. Die 200MHz Abtastrate braucht man wiederum auch nur dann, wenn man - wie ich es beschrieben habe - quasi Analog arbeiten will. Mit genügendem Rechenaufwand für Filter und Klangerzeung kann man auch im Spekralbereich arbeiten und mit geringfügig mehr Abtastrate, als 20kHz arbeiten - jedenfalls für die Synthese. In der DSP-Gruppe gab es gerade zu dem Thema kürzlich eine nette Diskussion zwischen mir und den DSP-Freaks hinsichtlich der Erzeugung AA-freier Rechtecksignale. Man muss diesbezüglich die Aufwände in den DSPs sehen und sie mit einer gleichwertigen Struktur im FPGA vergleichen. Die Mathematik muss im FPGA zwangsläufig eine andere sein, um effektiv zu werden. Damit ergeben sich ganz bestimmte Nieschen, in denen FPGAs Vorteile haben. Hat man aber eine dedizierte Aufgabe und packt sie im DSP / CPU in der vorgebenen Zeit in Echtzeit, ist die CPU immer die billigere Lösung und vor allem die stromsparendere.

Man muss auch immer aufpassen, wenn jemand vom "FPGA-System" spricht: Oft ist eben doch ein SOC gemeint, a la Zynq oder UltraScale und in denen sind eben solche leistungsstarken ARM-Cores verbaut und man kann auf Berechnungsvorteile zurückgreifen, die so im FPGA nicht existieren und die dann - wenn man sie in fabric aufbaut - sehr langsam sind.

Üblicherweise werden im PS solche Sachen wie IO, GUI und USB untergebracht. Oder, man packt dort die C-Software aus den alten Prozessoren rein, die man mit dem SOC beschleunigen will, bzw das man benutzt, um ein kompakteres System zu haben. Die eigentliche Intelligenz sitzt dann in eben diesem PS-Teil. So bauen wir auch unsere industriellen Plattformen: Im FPGA sitzt alles, was mit dem ARM nicht in Echtzeit zu machen ist, also was im Bereich der 10-20MHz aufwärts läuft. Aktuelle ARMs packen als Core zwar 800MHz, haben aber letztlich für ihre Aufgabe immer einen Loop und Entscheidungsbaum abzuarbeiten, daher sind sehr schnelle, wiederkehrende Sachen in Bruchteilen von 1us zunehmend ein Problem. Der CPU überlässt man daher die verschachtelten Sachen, die auch dynamischen Speicher brauchen, viel verwalten und ungleichmäßig ablaufen - wo von den Strukturen von C++ profitiert werden kann.

Was mich halt mal interessieren würde: Was genau macht der FPGA-Teil (PL) in der Kyra und was macht der Prozzessor-Teil (PS)?
 
Was mich halt mal interessieren würde: Was genau macht der FPGA-Teil (PL) in der Kyra und was macht der Prozzessor-Teil (PS)?
Laut Auskunft des Entwicklers Manuel Caballero ist der FPGA zuständig für den gesamten Signalweg einschließlich OSCs, Filter, Hüllkurven, LFOs, VCAs. Die Effekte werden in einem DSP berechnet. (Weiß nicht, ob das weiterhilft ... aber so weit ist mein Kenntnisstand aus erster Hand.) Man kann aber sicherlich auch mal bei Waldorf anfragen mit der Bitte, die Frage an Manuel Caballero weiterzuleiten. Er gibt bestimmt gern Auskunft.
 
Hallo,
ich bin nun seit einer Woche im Besitz des Waldorf Kyra und möchte die Besitzer einmal bitten, ob sie beim Spielen von 1/4 - Noten ( mit der Tastatur immer den selben Ton hintereinander anschlagen ) bei einigen Sounds auch dieses " Ploppgeräusch" und Unterdrücken der Releasezeit der vorhergehenden Note haben.
Für mich eigentlich unverständlich, weil doch ein " Stimmenklau" in dem Manual ausdrücklich verneint wird.
Sonst ein schönes Instrument, die Bedienung ist ein bisschen hakelig, fehlt doch wirklich ein Dateneingaberad für Werteänderung ( statt dieses ewigliche " Up-/Down - Getippe "

Viele Grüße
Timkauf ;-)
 
Deine Wahl war......weise! :supi:
Ich werd's, wenn i dahoam bin, mal testen. Polyphonic is bei jedem "Sound" eingestellt? Sprichst du von Presets? Dann kannst du auch das jeweilige nennen. Entspannte 60BPM?! :mrgreen:

UPDATE: Ok...also bei mir is alles fein :) Befeuere (sequenze) Kyra via Arturia Keystep mit gleichen 1/4 Noten, hab mal ne Reihe an Presets der A Bank getestet. Alles in Reih und Glied... :nihao:
 
Zuletzt bearbeitet:


News

Zurück
Oben