Was macht das Sorgenkind Blofeld?

[intercorni]

PPG hat mit Waldorf gar nichts gemeinsam.

Naja, Wolfgang Düren hat früher den Vertrieb für PPG gemacht, nichts gemeinsam stimmt also nicht. Und ein paar offensichtliche Anleihen gibt es ja auch.

Die Konzeption eines Produktes hat nun mal rein gar nichts mit dem Vertrieb zu tun. Und Wolfgang Düren ist längst nicht mehr bei Waldorf.

 

[dns370]

finde die presets allesamt sehr leise, inspirations- und drucklos - da kann ich die aussage "klingt wie ein billiges vst" schon irgendwo nachvollziehen, aber wenn man selbst schraubt, bekommt auch mit ihm recht schnell richtig dicke bässe und selbstmodulierendes zeug a la autechre oder gridlock hin, was dann definitiv NICHT mehr billig und dünn klingt und für nur 250 euro, die man gebraucht für einen blofeld hinlegen muss, sollte es absolut nichts zu meckern geben...

stimmt

ich finde, er macht sich schon ordentlich breit im Mix

 

[microbug]

stimmt

ich finde, er macht sich schon ordentlich breit im Mix

Kann sich jedenfalls gut durchsetzen, das Ding. Ich hab am Samstag das erste Mal die Gelegenheit gehabt, die Kiste mal näher zu betasten, und das was ich hören konnte, gefiel mir durchaus. Er kann sowohl seidig-schimmernd als auch böse. Hatte 2x einen MicroQ, dessen Sound ich durchaus mochte, aber sowas als Rack war einfach nix, so ein Desktopmodul kommt da schon besser. Von der Bedienung her konnte ich auch nicht meckern, zumindest die Soundanwahl mit den Kategorien ist prima gelöst - gut, das Display dürfte bissl größer sein, aber es wird jedenfalls ordentlich genutzt.

Eigentlich wollte ich ja, wenn schon einen Waldorf, einen mit mehr Knöppen, wie den XT, aber der Kleine hier bringt mich durchaus ins Grübeln

 

[Synthmill]

Ich hab mir einen im Netz gesteigert. Der wurde wahrscheinlich verkauft weil die Controller teils ein wenig gesprungen sind. Mit einem Lötkolben und 12Stk. 470pF Kondensatoren kann man das aber schnell wieder in Gang bringen. Das Problem liegt daran, dass die Controller mit der Abnutzung ein grösseres Rauschen aussenden und dies dann als Signal erkannt wird, dann springen die Werte vor- oder Rückwärts. Für den Preis ist der Blofeld sonst solide verarbeitet.

Die "Reparatur" ist übrigens für einen geübten Hobby-Löter eine arbeit von 10min!

Das ganze ist hier beschrieben: http://synth.stromeko.net/DIY.html

Sonst ist der Blofeld eine geile Kiste, klein handlich und nach 2 Tagen flüssig zu bedienen mit einem sehr guten Sound!

Greetz

 

[Anonymous]

Ich hab mir einen im Netz gesteigert. Der wurde wahrscheinlich verkauft weil die Controller teils ein wenig gesprungen sind. Mit einem Lötkolben und 12Stk. 470pF Kondensatoren kann man das aber schnell wieder in Gang bringen. Das Problem liegt daran, dass die Controller mit der Abnutzung ein grösseres Rauschen aussenden und dies dann als Signal erkannt wird, dann springen die Werte vor- oder Rückwärts. Für den Preis ist der Blofeld sonst solide verarbeitet.

Die "Reparatur" ist übrigens für einen geübten Hobby-Löter eine arbeit von 10min!

Das ganze ist hier beschrieben: http://synth.stromeko.net/DIY.html

Sonst ist der Blofeld eine geile Kiste, klein handlich und nach 2 Tagen flüssig zu bedienen mit einem sehr guten Sound!

Greetz

wirklich vielen lieben dank für dein info und:

 

[microbug]

DAS ist doch mal ne fundierte Info, herzlichen Dank dafür. Vielleicht hätte das dem Schmitz seinem Dave auch mal erzählen sollen

BTW: Holger vom Support ist wirklich gut. Hat mir vorhin (20:39) geantwortet, alle Achtung.

 

[moroe]

die clocked delay clicks sind bei meinem blofeld nach dem beta firmware update verschwunden.

die geschichte mit den clocked lfo´s muss ich erst austesten.


weiter so waldorf

 

[Rasenmähermann]

Der blofeld ist super und ich werde mir auch wieder einen holen, aber die keybaored variante, mag ich lieber.
Wo hab ich das gelesen?
Der blofeld ist wie ein dicker elefant den man ordentlich treten muss bevor er aufsteht und trötet, aber wenn er trötet, dann richtig.

 

[7f_ff]

Wo hab ich das gelesen?
Der blofeld ist wie ein dicker elefant den man ordentlich treten muss bevor er aufsteht und trötet, aber wenn er trötet, dann richtig.

...vlt. in'nem Schmuddelblättchen vonna Tanke...?!


Gruss

 

[dani]

Wo hab ich das gelesen?

beim Jexus (der weiss auch wie er seine Synths treten muss)

 

[Anonymous]

die clocked delay clicks sind bei meinem blofeld nach dem beta firmware update verschwunden.

die geschichte mit den clocked lfo´s muss ich erst austesten.


weiter so waldorf

und ? geht es ?

mir ist noch was anderes aufgefallen : das FM hat, nun, gewisse Eigenheiten

wenn man als FM Quelle denselben Osci auswählt, und eine Sinewave hat, sollte
man eigentlich ein Spetrum (und Welle) kriegen daß einem Sägezahn immer ähnlicher wird
bevor es chaotisch wird.

Stattdessen passiert eigentlich gar nichts ausser daß der Osci extrem verstimmt wird, und zwar
um so mehr je weiter er von irgend einer mittkleren Pitch abweicht,
bis er schliesslich gar keinen Ton mehr spielt
Dasselbe Verstimmunsgproblem tritt auf wenn man einen Osci mit einem bereits moduliertem Osci moduliert.

Das ist eigentlich FM technisch nicht richtig.

Möglicherweise wurde, eventuell bewusst, auf das dafür notwendige 1 Sample Feedback Delay
verzichtet, oder es ist ein DC offset drin oder beides.
DC Offset sollte aber möglichst nirgends drin sein schon gar nicht im Sinus.
Jedenfalls ist das falsch, und damit fallen alle FM Sounds weg die nicht mit einem
einzelnen Mod->Carrier realisiert werden. Schade, auch wenn man damit leben kann.
Das Problem tritt nicht auf wenn als Quelle derselbe Osci verwendet wird und es keine
Rekursion gibt.

Komisch daß das ebenfalls noch keinem aufgefallen zu sein scheint, hab nur ein einsames Posting darüber
gefunden.

 

[Anonymous]

You mean the uncleanliness step effect?
This is a problem of the DSP readpointer and could not be fixed. Our developer will try to make a workaround.
Thank you for understanding!

All the Best,

Holger
--------------------
Waldorf Support

Im englischsprachigen Forum hat jemand auf Anfrage an den Waldorf Support zum Thema "clocked LFO Bug" die oben stehende Antwort erhalten, auf ein Update welches diesen behebt braucht man demnach nicht mehr hoffen .

sodann Raiden

 

[Mr. Roboto]

Firmen die sich auch heute, im Jahr 2012, nicht entblöden so etwas unverschämtes wie "wir danken für Ihr Verständnis" zu schreiben müßte man mal zu einem Seminar schicken.

 

[Anonymous]

seltsame Antwort von Holger und falsche Schlussfolgerung von Dir ( hoffe ich )
erstmal - das ist das ist Geschwurbel,
einen "DSP readpointer" der damit etwas zu tun haben könnte gibt es eigenlich gar nicht
WTF ?
gemeint ist wohl einfach ein Softwarepointer genauer die Phasenrampe des LFO

Gemeint ist vllt daß die Clock halt nur mit ner unbestimmten Rate kommt
und mit der wird der LFO abgedated, wenn das so ist ist das aber halt
einfach falsch implementiert, wobei die Clock sowieso viel zu langsam ist
um überhaupt einen LFO damit zu betreiben, kann es eigentlich nicht sein -

es ist überhaupt kein Problem, einen LFO oder sonstigen Oscillator
mit jeder beliebigen Rate ( zB Audio) upzudaten und gleichzeitig mit einer Clock
mit einer niedrigen Rate zu synchronisieren,

Die einfachste und naheliegendste Lösung ist linear zwischen den einzelnen
Clockevents zu interpolieren

Eine Schwierigkeit tritt erst dann auf, wenn die Clockrate sich ändert, dh
wenn ein Clockevent früher oder später kommt als erwartet, was wahrscheinlich
der Grund ist warum das so implementiert ist
Dieses Problem ist aber vollkommen unabhängig davon ob man nun mit Audiorate interpoliert oder nicht,
ohne Interpolation gibt es halt eine diskontinuierlichen Sprung, mit Interpolation
hat man die Freiheit festzulegen in welcher Zeit der LFO aufholt oder abbremst
und das kann man wiederum an die Clockrate anpassen sowie differenziert je nachdem
ob das Event zu früh oder zu spät kommt, man kann es auch an die LFO Rate anpassen,
oder an die LFO Shape, wenn ich zB will daß ein Sägezahn genau mit der Clock auf "1"
springt egal wie ich das Tempo moduliere, wobei sowas in der Praxis eh nicht vorkommt
Man kann es auch an die notwendige Veränderung der LFO Phase pro Zeit abhängig von der
momentanen LFO Phase abstimmen, dh alles zusammen in einem Schritt, elegant

Hier ist jedenfalls jede Zeitspanne von instantan bis zu mehreren Clockevents oder LFO Phasenzyklen möglich
Das braucht auch nicht mehr Rechenkraft als der ungesynchte LFO, da man die LFOphase
sowieso berechnen muss, und die Anpassung nur mit jedem Clockevent erfolgen muss
was nur etwa alle 500-1000 Samples passiert, das kostet gar nichts

Im Herbst/Winter vor der .16Beta hiess es noch das wird gefixt

Naja, er schreibt ja zumindest sie arbeiten dran

 

[Anonymous]

seltsame Antwort von Holger und falsche Schlussfolgerung von Dir ( hoffe ich )

Moment mal, ich schlussfolgere doch garnichts. Dies ist nichts weiter als die originale Antwort vom Waldorf Support zu genau diesem einen Thema, dem sog. "clocked LFO Bug", ich kenne den Kollegen durch gemeinsame Dubstep Projekte recht gut und ich kenne, in diesem Fall, auch den kompletten eMail Verkehr zwischen Ihm und dem Waldorf Support, da ich diesen, in Kopie, aus persönlichem Interesse, den Bug betreffend, direkt weitergeleitet bekommen habe, da ist nichts mit falsch schlussfolgern oder so, es ging definitiv und ausschließlich nur um diesen Bug und nicht um irgendwelches Geschwurbel.

Was da technisch passiert weiß ich nicht und ich weiß auch nicht inwiefern dies eine seltsame Antwort vom Support darstellt, für uns war nur wichtig ob dieser Bug behoben wird oder nicht und diese Frage dürfte mit dieser Antwort geklärt sein.

Das dir der Support vor einiger Zeit noch geschrieben hat dies würde gefixt werden wundert mich ehrlich gesagt überhaupt nicht, ich könnte da jetzt noch ein paar Anekdoten zum Thema "Blofeld clocked LFO Bug und der Waldorf Support" erzählen da stellen sich einem die Nackenhaare auf aber das lass ich mal lieber sein, für mich ist die Angelegenheit damit eigentlich durch.

sodann Raiden

 

[Anonymous]

seltsame Antwort von Holger und falsche Schlussfolgerung von Dir ( hoffe ich )

Moment mal, ich schlussfolgere doch garnichts.

na doch, und zwar :

auf ein Update welches diesen behebt braucht man demnach nicht mehr hoffen .

also zumindest in dieser Mail schreib er das so nicht er sagt ja sie denken noch ..

Der Rest war natürlich auf Waldorf gemünzt, technisch ist das so wie ich sage, ist mein Job

Man kann jetzt hoffen daß sie das Problem auf dem Schirm haben in dem Fall müssten sie es eigntlich
für den Pulse und Sledge auch fixen, vielleicht havben sies deswegen erstmal verschoben

oder es hat dort niemand auf dem Schirm wie sich der Bug in echt auswirkt und noch niemand genau angeschaut
oder angeschaut und dann vergessen und dann ist es wegen Fehleinschätzung irgendwo ganz unten auf der Prio Liste gelandet

Ich schätz mal das ist mit 2-5 Zeilen Code locker gelöst (kann ich natürlich nicht sicher wissen )
Der Aufwand und die Zeit die drauf geht ist natürlich viel grösser, das ist klar, so drei Zeilen können
auch ne Woche verschlingen mit allem was da noch drumrum dranhängt, nicht zuletzt muss es am Schluss
als Download auf die Website, all der Kleinscheiss kostet Zeit von mehreren Leuten
alleine sich nach ner Pause wieder so nem Projekt zuwenden und das mal ankucken kann viel Zeit kosten
nach Hofstadters Gesetz länger als man laut Hofstadters Gesetz denkt

EDIT : mir wird gard klar das Holger vermutlich von dem Delay spricht oder das verwechselt - da ist es natürlich so, daß der Readpointer
nicht springen darf, und man den auch nicht einfach mal schneller und mal langsamer laufen lassen kann sonst gibts
je nachdem Knacksen oder Pitchshift, das ist klar

 

[Anonymous]

also zumindest in dieser Mail schreib er das so nicht er sagt ja sie denken noch ..

Wo steht das denn bitte, dort steht ganz klar das jenes Problem nicht gefixt werden kann ("This is a problem of the DSP readpointer and could not be fixed"), evtl. fällt dem Entwickler noch ein Workaround ein ("Our developer will try to make a workaround"), mehr steht dort nicht. Deine Interpretation in allen Ehren aber es ging weder um das Delay noch um sonst irgendwelche anderen Probleme mit dem Blofeld, nochmal es ging nur um den "clocked LFO Bug" und um nichts anderes, ich bin mir sicher das Hr. Steinbrink da auch nichts verwechselt hat ("You mean the uncleanliness step effect"). Ich würde mir an deiner Stelle keine Hoffnungen mehr machen das dies noch gefixt wird, würde dies wirklich so easy zu erledigen sein wie du es schreibst ("Ich schätz mal das ist mit 2-5 Zeilen Code locker gelöst") hätten die Jungs bei Waldorf dies schon längst getan. Ich will auch garnicht weiter darüber diskutieren, ich wollte dies nur kurz mitteilen und mehr nicht.

sodann Raiden

 

[Anonymous]

Ok, aber Holger ist kein Entwickler, er ist ja nicht derjenige der das dann fixt,
und beim Beantworten von zig Mails pro Tag kommt es schon mal vor daß man Unsinn oder
schlecht formuliertes absondert, besonders wenn man nur zwischen Instanzen vermittelt.

Ich glaub dir ja daß es um den LFO Synch ging, klar. Für mich ist halt Workaround und Bugfix
in dem Fall gleichwertig, deswegen versteh ich das anders.

Danke für die Info jedenfalls.

Übrigens sind fast alle Bugs mit wenigen Zeilen Code gelöst, das ist eher die Regel,
bei dem hier weiss ich halt zufällig wie man's normalerweise so machen kann das es funktioniert.

Und das funktioniert bei meinen Synths genauso wie allen anderen die mir bekannt sind.
Sonst würd sich ja keiner drüber aufregen.

Egal. Naja nicht egal, aber soll man machen.

 

[Anonymous]

Hm kein Ding aber für mich sind halt ein Workaround und ein Bugfix zwei komplett unterschiedliche Dinge. Wie gesagt, ich hab keine Ahnung von Codes und dem ganzen Gedöns, was in der Kiste technisch abgeht interessiert mich eigentlich null, ich bin nur Musiker, aber ich denke mir halt, wenn es so einfach wäre wie du schreibst, hätten die das bestimmt schon längst gefixt und dazu passt auch die Aussage von Hr. Steinbrink, vielleicht ist der DSP einfach zu schwach oder was weiß ich, ist ja oftmals am Limit die Kiste, ich kenne das so jedenfalls von keinem anderen Synth, das ist alles schon echt eigenartig.

Egal, wie gesagt ich wollte diese Info nur weitergeben.

sodann Raiden

 

[microbug]

Bevor hier wild rumgemutmaßt wird, sollte man sich erstmal über die verwendete Hardware klar werden.

Der Blofeld besteht im Kern aus einer MC9S12 MCU von Freescale (ex-Motorola) und einem 24Bit-DSP 56371 (DSPB56371AF180), ebenfalls Motorola/Freescale.

Wenn man das mal mit den "Vorgänger" MicroQ vergleicht: Dort steckte ein Motorola 68331 (68K/CPU32) und 1 Motorola 56303 drin. Der DSP im Blofeld ist neuer, aber die MCU dafür eine Klasse drunter. 68331 ist ja 680x0-Basis, also 32bit, bekannt aus Atari TT, neueren Amigas, etlichen Synths und natürlich auch den letzten 68K Macs. Der 9S12 (S12UF) dagegen stammt aus der HCS12-Familie (68HC11/12), ist also 16Bit und mindestens eine Klasse unter der 68331. Hat dafür aber schon ein Interface für diverse Flashspeicher sowie USB schon eingebaut, weil eigentlich für USB-Sticks oder Kartenleser gedacht.

Die Limitierungen sehe ich daher auf der Seite der MCU, ebenso diesen Readout pointer. Es wurde ja schon irgendwo gesagt, daß der DSP auch die Displayansteuerung mit erledigt.

Die MCU hat einen Stückpreis von 6,15€ (Mouser) bei Einzelabnahme, die sich bei 100 fast halbiert, der DSP kostet pro Stück 13,27 (bei 100 Stück 11€), also durchaus eine Lowcost-Lösung. Die im MicroQ verwendeten Komponenten waren deutlich teurer (der 68331-16 kostet einzeln 19€, die schnelleren entsprechend mehr).

Das nur mal als Diskussionsgrundlage, falls bisher nicht bekannt.

 

[dns370]

dann haben die aber für eine lowcost-lösung mächtig was rausgeholt

 

[microbug]

dann haben die aber für eine lowcost-lösung mächtig was rausgeholt

Allerdings. Ich war selbst überrascht, als ich die Komponenten zu Gesicht bekam.

BTW: neuere Blofeld-Boards haben eine MIDI Out- Buchse vorgesehen, Ältere nicht. Spart ebenfalls getrennte Platinen für die KB-Variante.

 

[Anonymous]

also die Synthengine wird ja komplett auf dem DSP laufen, das Display weiss ich nicht aber der Microcontroller wird die Peripherie steuern,
MIDI, Knöpfe etc, mit oder ohne Graphik, soviel ist da auch nicht dran, wenn die Graphik nicht dabei ist

meine Rede kurz war eigentlich, daß der LFO ja im freilaufenden Modus offensichtlich mit
einer vernüftigen Rate berechnet wird, evtl sogar Audio, ist ne Weile her daß ich mir das angeschaut habe

Nun gibt es keinen Grund daß er gesynched deutlich langsamer laufen muss, das ist ganz unabhängig davon,
ob es irgendweinen sehr langsamen getakteten Loop im DSP gibt oder was immer, auch unabhängig davon
wie performant der DSP ist, und vom MC ist das praktisch sowieso unabhängig auch wenn der die Clockevents liefert

es ist einfach so daß der LFO zwischen jedem Synchevent ganz normal berechnet werden kann
genau wie ungesyncht, mit der gleichen Rate, das kostet nicht mehr als ungesyncht abgesehen
vom Neusetzen der Rate aber das passiert ja so oder so, auch jetzt

wenn man ihn auch linear interpoliert zwischen den Clock Events schneller oder langsamer
laufen lässt kostet das etwas mehr, aber nicht viel wenn man eine globale samplegenaue Songposition berechnet die per Clockevent gesyncht ist
und alle LFO Phasen aller Stimmen von dieser ableitet, zB

Also mir ist das Problem das da bestehen soll vollkommen unklar, vom Effekt wie es aussieht
sieht es für mich einfach so aus als ob in dem Modus schlicht die ganze LFO Berechnung vergessen wurde
dh nicht ausgeführt wird, so daß ein neuer Wert nur mit nem langsameren Clockupdate gesetzt wird,
quasi als Nebeneffekt der den Bug erstmal verschleiert beim testen.

Aber natürlich steck ich auch nicht drin

 

[microbug]

Das Display wird beim Blofeld vom DSP aus angesteuert, diese Aussage kam von Waldorf selbst.

Ich glaube nicht, daß da irgendwas vergessen wurde, sondern es aufgrund der gewählten Bauteile einfach nicht anders geht. Möglicherweise muß der LFO gepollt werden, was dann anderes Timing einbrechen ließe, das will dann keiner.

Wenn Du es genau wissen willst, fragt Stefan Stenzel oder Wolfram Franke danach.

 

[Anonymous]

Die werden sich bestimmt freuen - bei Laune probier ich ma stenz@waldorf mal sehen obs ankommt

Der LFO kann ruhig durch die Clock gepollt werden wenn das sein muss obwohl mir
das mehr als unelegant vorkommt - und trotzdem mit Audiorate oder welcher Rate auch immer laufen
Auch andersrum, falls die Clock aus dem MC abgefragt werden muss, auch wenn das polling
in nicht definierten Abständen erfolgt, usw. -
Und das gewählte Bauteil ist ja ein DSProzessor, auf dem geht prinzipiell alles...
ist relativ egal wie der mit dem Microcontroller verwurstelt ist

Nicht ausgeführter Code ist auch nicht sooo ungewöhnlich, grad bei Audiogeschichten
bin nicht der einzige dem das passiert, naja egal - Thema ist durch

Ich werd da sicher nochmal nachhaken bevor ich den Blofeld verkaufe,
weil ich ihn ganz gern wegen der Tastatur und denm Drivecurves behalten würde
und weil er schick aussieht und ich soviel Verlust mache wenn ich ihn verkaufe
der ist ja gebraucht nur ca 450,- Wert, und ich brauchte n neues MasterKB, lohnt sich kaum :|

 

[drfreq5168]

wer hat eigentlich behauptet das blofeld ein sorgenkind ist... noch stehen die dinger im laden und werden verkauft, glaube ich zumindestens

 

[android]

wer hat eigentlich behauptet das blofeld ein sorgenkind ist... noch stehen die dinger im laden und werden verkauft, glaube ich zumindestens

ich war es nicht aber das eine muss das andere ja nicht zwangsläufig ausschließen oder!?

 

[Anonymous]

wer hat eigentlich behauptet das blofeld ein sorgenkind ist... noch stehen die dinger im laden und werden verkauft, glaube ich zumindestens

stimmt, bei Ebay sind sie auch dauernd im Angebot,
"Erst vor 6 Wochen gekauft, nur einmal für 3 Stunden gespielt und wieder eingepackt, wie neu"
"Ich garantiere, daß das Gerät ohne Fehler ist die nicht durch das Betriebssystem verursacht sind"

Muss echt der Renner sein das Teil

Oder auch, O-Ton im Musikladen : "Und Du willst den wirklich kaufen, den Klofeld ?"
klar, die wollen natürlich lieber was verkaufen wo die Gewinnspanne 3 mal so hoch ist, trotzdem

Ist insofern ein Sorgenkind als Waldorf Probleme hatte, zB den "Init Bug" zu finden, und die letzte
Beta auch nur "eine mögliche Ursache" des Bugs ausmerzt
Glücklich darüber, daß auch jetzt noch Bugs nicht gefixt sind und Features mit denen er beworben wurde
nicht funktionieren sind die sicher nicht, niemand hat Spass dran Bugs zu suchen wenn eigentlich ganz andere
neue Projekte auf dem Plan stehen

 

[Anonymous]

oh, und bei der ersten Serie ging der Lack ab, dh die Beschriftungsschicht hat nicht gehalten
einer der Gründe warum die schwarze Serie aufgelegt wurde glaub ich, weil das auch dem Handel signalisiert daß es eine neue Auflage ist
von der solls 500 Stück gegeben haben ( kA ob das stimmt ) gabs etwa 1/2 Jahr glaub ich, dazu gabs ne Pause zwischen den Auflagen - reich werden die damit nicht wenn das stimmt

 

[drfreq5168]

Du suchst zur Zeit nen Q? Ich hatte den Q Rack gehabt, SPDIF ist cool... zahl für das Ding keine 7 oder 800 € das ist er nicht wert. höchstens 300 bis max. 500 € Vergiss auch nicht das er nur 16 Stimmen hat, das wirst du auch ziemlich schnell zu spüren bekommen, gerade wenn du Polyphon und Modulation benutzt. Die OSC alleine sind sehr schwach. Der Q klingt ziemlich drahtig, digital mit metallischem grundklang. der q gefällt mir schon ganz gut aber wenn ich ehrlich sein soll würde ich dir eher einen virus ans herz legen.. ich hate mal einen virus gehabt und wenn ich zurück denke glaube ich das der virus der bestklingenste synth war den ich hatte, neben der super nova 2. wie gesagt für den q nicht die aktuellen preise zahlen, die sind zu hoch... da kannst du auch de largo kaufen und hast sogar mehr features, der largo klingt genauso wie die hardware. was mir beim q auch gut gefallen hat war der comb filter und die five fx den filter routing / panning misch masch modulation vom q ist zwar lustig aber musikalich unbrauchbar finde ich, wer benutzt den so sounds in seiner musik, eher was für filme oder einfach nur so...