DSP56300 -> DSP-Emulator für Virus (Ostirus), Clavia Nord Lead (Nodal Red), Waldorf Microwave XT (Xenia), MicroQ (Vavra) …

[swissdoc]

Hier nun Factory Demos ohne Fehler:

Chapeau!

 

[lilak]

ich steh auch voll hinter dem herrn schneider und seiner emu klitsche. hab gerade einen track damit produziert und das obwohl ich sowohl virus B als auch microq habe. nichts wummst mehr wie eine dramatische virus sequenz!

sobald der virus TI damit funzt baue ich mir mit einem raspberry 4 auf linux basis einen hardware emu virus ti mit allen schikanen. der herr kemper hat selbst schuld wenn er den virus nicht mehr weiterbaut.

https://audius.co/Dreipolar/liszt

 

[Der Fab]

Geht das überhaupt? Also Latenzmäßig?

Von der Leistung mal abgesehen ... So´n Teil mit 8 Stimmen wären auch schon geil

 

[subsoniq]

Also aufm ryzen6 3600 verbrät der emu zwischen 20 und 30% laut maschine cpu meter bei latenzoption 1
Könnte gehen...
Edit: ok, habs grad nochmal gelesen, es geht ja um den ti...meine angaben waren für virus c : also keine ahnung

 

[lilak]

ich hab einen altersschwachen viercore I5. unter linux manjaro läuft die emu problemlos wenn du genügend buffer gibst. 8 stimmen brauchen kaum mehr cpu als eine glaube ich weil das meiste in der emu verbraten wird. die rechenleistung für die tatsächliche dsp ist vermutlich vergleichsweise gering.

der TI hat im vergleich zum B zwei dsp chips also könnted sein dass das dann die doppelte leistung braucht? das ist alles eine frage wie elegant die emu ist und da sind die ja noch am anfang. mein I5 macht gemessene 280 mips, ein raspberry 4 fast das 5 fache. also irgendein ARM basierter desktop ist vermutlich ideal.

 

[JayBee]

raspi geht nicht, zu langsam. hatte ich einige seiten vorher gefragt

 

[lilak]

Ich portiere den Recompiler gerade auf ARMv8, dann läuft er sogar auf einem Raspberry Pi 3/4 und dem Apple M1. Ein Virus TI3 wäre machbar ohne den Code neuschreiben zu müssen.

danke für den hinweis. hab gerade nochmal nachgelesen, das ist vom 3. august. also wenn er inzwischen seine meinung nicht geändert hat sollte das mit einem raspi machbar sein. wenn nicht findet garantiert irgend jemand eine lösung weil das einfach naheliegend ist. an der rechenleistung kann es nicht liegen.

ich finde das projekt auch theoretisch interessant weil es eben grundsätzlich was anderes ist als ein virus soundalike plugin - ein hardware virus emu clone wäre ein perfektes multiple weil eben der orginale access code läuft - nur übersetzt. der begriff des multiple ist in den 70gern von beuys geprägt worden als antwort auf die kritik dass seine filz/fett skulpuren jeder nachbauen könnte weil da kein künstlerisches "können" dahinter ist. also hat er alle seine studenten filzanzüge machen lassen und das "multiple" genannt.

eine kopie eines orginals ist keine abwertung des orginals sondern eine aufwertung. heute nachdem jeder weiss was ein MEME ist und die ganze netzkultur auf ideenkopieren und fakes beruht ist das klar aber in den 70gern war das radikal.

ich finde jeder hier der wirklich damit was macht sollte den herren dsp56300 mal eine paypal spende machen. ich natürlich auch.

 

[Feel Inc.]

Ich finde das Projekt ebenfalls den absoluten Hammer. Ich habe hier allerdings immer noch Probleme mit Knacksern, trotz M1Pro Mac mit 32GB RAM. Nach ca. einer Minute geht die CPU-Auslastung beim spielen komplett in die höhe und es kommen Knackser ohne Ende. Ich hab etwas mit der Latency Block Einstellung gespielt, erst bei 4 scheint das Knacksfrei zu funktionieren. Laut testprogramm komme ich auf über 400MIPS bei mir, damit mehr als ausreichend für Virus C. Audiointerface ist bei mir ein UMC1820 mit 128 Samples Puffer unter Ableton 11 (alles nativ, kein Rosetta). Das Problem tritt sowohl als AU als auch als VST2 auf. DSP-Emulator version ist die aktuellste (1.2.19), das Problem habe ich sowohl mit Virus C ROM als auch Virus B ROM. Übersehe ich etwas oder gehört das so?

 

[Feel Inc.]

Kleines Update: Ich hab jetzt nochmal die System CPU-Anzeige mit eingeblendet und dabei ist mir was aufgefallen:
Während der DSP-Emu läuft (AutoBendBC-Patch, Latency (Blocks) default 1), sieht es in Ableton wie folgt aus:


Die System-CPU Anzeige sieht allerdings wie folgt aus:


Ich habe während des Tests so einiges im Hintergrund geöffnet, d.h. die ersten beiden Cores sind auch vorher schon einigermaßen ausgelastet. Es scheint aber so zu sein, dass der DSP auf genau einem (oder beiden) dieser Cores läuft, obwohl die anderen 8 sich komplett langweilen und mehr als genug Leistung bereit halten. Ich bin mir jetzt zum einen nicht sicher, ob das ein Problem von Ableton ist oder vom Plugin, einer von beiden scheint aber die Cores nicht korrekt zu nutzen. Lässt sich dieses Verhalten ändern (seis im Plugin oder in Ableton)?

 

[lilak]

wenn du das auf deinem M1 nicht hinbekommst würde ich mal zu einem betriebssystem wechseln das nicht die hälfte deiner cpu frisst wie gesagt mit meinem alten i5 unter linux majaro läuft das ohne probleme. ja die emu läuft auf nur einem core genauso wie das orginal - aber 400 mips sollten mehr als genug sein. eigentlich brauchts sowas wie 220 mips mindestens.

lies mal im blog den letzten eintrag da steht was dazu:

The Usual Suspects - DSP56300 Emulation

Digitally Preserving Classic Synthesizers through Emulation

dsp56300.wordpress.com

 

[Feel Inc.]

wenn du das auf deinem M1 nicht hinbekommst würde ich mal zu einem betriebssystem wechseln das nicht die hälfte deiner cpu frisst

Ja, habe ich vor Jahren schon gemacht, bin von Windows weg, aber das läuft ohnehin nicht auf nem M1... Wenn Du Dir meinen letzten Beitrag genau durchliest, dann wirst Du auch feststellen, dass hier das OS sicherlich nicht die hälfte wegfrisst... wie ich geschrieben habe, habe ich während dessen so einiges im Hintergrund offen (Outlook, Slack, Browser, div. andere Programme) und die Kiste langweilt sich insgesamt.

was du machen kannst ist im plugin interface rechte maustaste -> latency (blocks) -> 2 oder mehr.

Hatte ich ja geschrieben, dass es mit 4 oder mehr ohne Knackser geht. Ich kann mir nur nicht vorstellen, dass bei einem System, dass über 400MIPS machen kann, das notwendig sein soll.

ja die emu läuft auf nur einem core genauso wie das orginal - aber 400 mips sollten mehr als genug sein. eigentlich brauchts sowas wie 220 mips mindestens.

Ich weiss, dass die Emu nur auf einem Core läuft und das Prinzipbedingt auch nicht auf mehrere aufteilbar ist... und mehr als 220 MIPS bringt mein System ja (zumindest gehe ich davon aus, dass 400 mehr als 220 ist ).

Ich habe das gleiche Spiel jetzt übrigens auch mal in Reaper probiert, gleiches Problem, Knackser nach kurzer Zeit, sobald latency (blocks) unter 4 ist. Somit geht die Vermutung weiter in die Richtung, dass das Plugin sich immer den ersten Core, anstatt den mit der geringsten Auslastung krallt. @dsp56300 ist meine Vermutung richtig, gibt es ggf. schon eine Möglichkeit, dass man das (per Option?) ändern kann oder müsstet ihr da genauer reinschauen?

 

[lowcust]

danke für den hinweis. hab gerade nochmal nachgelesen, das ist vom 3. august. also wenn er inzwischen seine meinung nicht geändert hat sollte das mit einem raspi machbar sein. wenn nicht findet garantiert irgend jemand eine lösung weil das einfach naheliegend ist. an der rechenleistung kann es nicht liegen.

ich finde das projekt auch theoretisch interessant weil es eben grundsätzlich was anderes ist als ein virus soundalike plugin - ein hardware virus emu clone wäre ein perfektes multiple weil eben der orginale access code läuft - nur übersetzt. der begriff des multiple ist in den 70gern von beuys geprägt worden als antwort auf die kritik dass seine filz/fett skulpuren jeder nachbauen könnte weil da kein künstlerisches "können" dahinter ist. also hat er alle seine studenten filzanzüge machen lassen und das "multiple" genannt.

eine kopie eines orginals ist keine abwertung des orginals sondern eine aufwertung. heute nachdem jeder weiss was ein MEME ist und die ganze netzkultur auf ideenkopieren und fakes beruht ist das klar aber in den 70gern war das radikal.

ich finde jeder hier der wirklich damit was macht sollte den herren dsp56300 mal eine paypal spende machen. ich natürlich auch.

Muss ich doch mal probieren, hatte meine Viren immer ganz gerne. Ist mir dann auch gerne eine Donation Wert.

 

[Sektor]

Es wäre glaube ich ganz hilfreich wenn man die Polyphonie in der Emu irgendwie begrenzen könnte, so ab 8 Stimmen ungefähr meine ich schnellt der CPU Verbrauch bei mir hoch. Geht im original Virus zwar auch nicht, entweder Mono oder volle Polyphonie dynamisch mit bis zu 80 Stimmen (beim TI2), aber vielleicht könnte man das in der Emu irgendwie realisieren. Wäre schon echt gut wenn man da wählen könnte, 4, 8, 16 usw. Stimmen.

Ansonsten tolles Projekt, ich warte sehnsüchtig auf den microKORG/MS2000.

 

[Audiohead]

Ansonsten tolles Projekt, ich warte sehnsüchtig auf den microKORG/MS2000.

yep, ich auch

 

[dsp56300]

Also, der DSP läuft in einem separaten Thread. Aber auf welchem Core dieser Thread läuft ist Sache des Betriebssystems, das lege ich nicht explizit fest, weil es für jedes Betriebsystem und auch je nach CPU andere sinnvolle Methoden der Verteilung gibt.
Wenn der DSP auf den selben Core geschoben wird, auf dem bereits andere Dinge laufen, meint das Betriebssystem offenbar, dass das reichen sollte. Weniger Cores zu nutzen ist energieeffizienter.

Eine Sache dir mir da aber gerade einfällt: Was für Mac und Linux noch fehlt ist, den DSP Thread auf eine hohe Priorität zu setzen, das dürfte Abhilfe schaffen, baue ich in die nächste Version ein. Bisher ist das nur für Windows drin.

 

[dsp56300]

Ansonsten tolles Projekt, ich warte sehnsüchtig auf den microKORG/MS2000.

Haben wir auf dem Schirm, ist ein potenzieller nächster Kandidat, aber noch nicht angefangen. Aktuell liegt der Focus auf dem Waldorf microQ und ich hab noch ein paar Ideen was Performance angeht, die ich demnächst angehen möchte.

 

[Summa]

Es wäre glaube ich ganz hilfreich wenn man die Polyphonie in der Emu irgendwie begrenzen könnte, so ab 8 Stimmen ungefähr meine ich schnellt der CPU Verbrauch bei mir hoch. Geht im original Virus zwar auch nicht, entweder Mono oder volle Polyphonie dynamisch mit bis zu 80 Stimmen (beim TI2), aber vielleicht könnte man das in der Emu irgendwie realisieren. Wäre schon echt gut wenn man da wählen könnte, 4, 8, 16 usw. Stimmen.

Ich würde mir eher wünschen dass man das Ti ROM (gibts das schon, hab' ja hier 'nen TI1, beobachte den Thread nur) so weit hacken könnte, dass man bei den neuen Synthese Funktionen nicht so schnell an die Grenzen kommt, mehr DSP Power zur Verfügung steht.

 

[lilak]

@ dsp56300: den virus TI released ihr nicht weil der noch gebaut wird hab ich gelesen. was aber nicht heisst das ein TI OS nicht mit dem plugin irgendwann funktioniert? hab ich das richtig verstanden?
.
gebaut wird der TI aber nicht mehr supportet was ich nicht ganz verstehen kann. für mich ist die virus line teil der techno/trance geschichte und als soche offen für alle möglichen hacks. ich glaube der herr kemper sieht das ähnlich weil der ja selbst einer der besten deutschen dsp coder ist und versteht dass alle digitalen "produkte" sich von selbst weiterentwickeln, auch ohne "erfinder".

nur meine meinung ... ich persönlich finde auch dass der microQ besser klingt aber der virus ist für VA legendär so ähnlich wie der minimoog für analoge monosynths. ich kenne in berlin hier auch einige produzenten die noch heute einen TI regelmässig im studio nutzen - was man von microQ nicht sagen kann.

 

[dsp56300]

@ dsp56300: den virus TI released ihr nicht weil der noch gebaut wird hab ich gelesen. was aber nicht heisst das ein TI OS nicht mit dem plugin irgendwann funktioniert? hab ich das richtig verstanden?

Ja, genau richtig. Um genauer zu sein, der TI funktioniert bereits als Plugin, aber es fehlt noch fast die komplette GUI und die Stabilität muss besser werden, stürzt noch recht schnell ab.

.
gebaut wird der TI aber nicht mehr supportet was ich nicht ganz verstehen kann. für mich ist die virus line teil der techno/trance geschichte und als soche offen für alle möglichen hacks. ich glaube der herr kemper sieht das ähnlich weil der ja selbst einer der besten deutschen dsp coder ist und versteht dass alle "produkte" sich von selbst weiterentwickeln, auch ohne "erfinder".

nur meine meinung ...

Da haben wir inzwischen Informationen aus erster Hand, laut Chris Kemper ist der Virus "a living product", er sieht den Virus also in der Tat nicht als Legacy-Produkt.

 

[lilak]

laut Chris Kemper ist der Virus "a living product

stimmt, was man ja schon am hohen interesse an eurer virus emu sieht. dann kommt vermutlich irgendwann ein neuer virus von access was ich klasse finde. sagen wir einfach "der virus der 2000er ist legende aber der virus lebt!"

Ich habe das gleiche Spiel jetzt übrigens auch mal in Reaper probiert, gleiches Problem, Knackser nach kurzer Zeit, sobald latency (blocks) unter 4 ist.

die frage ist wieviele samples das sind aber für mich klingt das extrem wenig. dann hast du eventuell einfach global zu wenig audio buffer und das hat nichts mit der emu zu tun? weder linux noch mac sind für echtzeit audio gebaut - obwohl es das unter linux auch gibt. apple ist ja unter der haube auch linux inzwischen aber der overhead ist im vergleich zu manjaro/XFCE bei mir gewaltig.

 

[Feel Inc.]

die frage ist wieviele samples das sind aber für mich klingt das extrem wenig. dann hast du eventuell einfach global zu wenig audio buffer und das hat nichts mit der emu zu tun?

Wie viele Samples das im Plugin sind, keine Ahnung, global habe ich 128 Samples (bei 48kHz, falls relevant) buffer und kann da ansonsten an Plugins und Processing soviel reinhauen, wie ich will bislang (max. war irgendwas um 20 Spuren, alles mit diversen FX und Plugins dichgekleistert) ohne einen Aussetzer.

apple ist ja unter der haube auch linux inzwischen aber der overhead ist im vergleich zu manjaro/XFCE bei mir gewaltig.

Nein, apple war noch nie linux im Unterbau oder sonstwo... Darwin (Unterbau von OSX) basiert auf BSD und die BSD-Bestandteile verschwinden auch immer mehr bzw. werden durch apple-eigene Versionen ersetzt. Aber eine OS-Diskussion ist hier ohnehin eher Offtopic.

Also, der DSP läuft in einem separaten Thread. Aber auf welchem Core dieser Thread läuft ist Sache des Betriebssystems, das lege ich nicht explizit fest, weil es für jedes Betriebsystem und auch je nach CPU andere sinnvolle Methoden der Verteilung gibt.
Wenn der DSP auf den selben Core geschoben wird, auf dem bereits andere Dinge laufen, meint das Betriebssystem offenbar, dass das reichen sollte. Weniger Cores zu nutzen ist energieeffizienter.

Klingt sehr nachvollziehbar und gerade in Bezug auf den M1 logisch, da hier zugunsten Energieeffizienz recht aggressiv nicht benötigte Cores schlafen gelegt werden.

Eine Sache dir mir da aber gerade einfällt: Was für Mac und Linux noch fehlt ist, den DSP Thread auf eine hohe Priorität zu setzen, das dürfte Abhilfe schaffen, baue ich in die nächste Version ein. Bisher ist das nur für Windows drin.

Das könnte in der Tat helfen. Ich denke unter Linux tut man sich da so schon leichter zur Not mittels nice die Priorität anzuheben, unter Mac sehe ich zumindest mit Boardmitteln (Aktivitätsanzeige, top) keine einzelnen Threads, die ich mittels nice re-priorisieren kann

 

[lilak]

keine Ahnung, global habe ich 128 Samples (bei 48kHz,

und was passiert wenn du das global auf 256 setzt? oder andersrum, was spricht dagegen? bei mir läuft pipe wire auf 1024, mit einer internen RME audio karte und alles ist gut ... super schneller prozessor heisst ja noch nicht dass der audio output super schnell sein muss.

 

[Feel Inc.]

und was passiert wenn du das global auf 256 setzt? oder andersrum, was spricht dagegen? bei mir läuft pipe wire auf 1024, mit einer internen RME audio karte und alles ist gut ... super schneller prozessor heisst ja noch nicht dass der audio output super schnell sein muss.

Wenn ich global auf 256 stelle, erhöht sich natürlich die globale Latenz auch... da ich hier externe Synths mit dran habe, ein No-Go, da dann alles auseinander läuft. Mit 256 global buffer knackst der DSP auch auf latency (blocks) 0 nicht... hilft hier in dem Fall aber eben nicht. Ich denke, wenn in der nächsten Version von @dsp56300 die Priorität des threads hochgesetzt wird, dann kann sich das schon erledigt haben, werde testen und berichten.

 

[lilak]

ich hab x verschiedene hardware dran, alle mit unterschiedlichen latenzen. digitale sachen aus den 80gern haben intern schon oft 40 ms latenz. das problem hast du mit 128 samples auch nur etwas weniger. da musst du nur in ableton oder was auch immer alles etwas verzögern und so einstellen dass alle auf einer linie landen. das ist ein einfaches arithmetisches problem

das nur als tip. ich programmiere meine sequenzer selbst in pure data da ist das natürlich einfach zu machen aber jede daw kann eigentlich tracks verzögern.

 

[Der Fab]

Anständiger gehts ja kaum.

Alles andere als Apple hat anarchische Züge

 

[Feel Inc.]

kauf dir mal was anständiges

Das hat doch mal Potential zum Tipp des Monats...
Auch wenn diese ganzen Plattformdiskussionen hier Offtopic sind: Ich habe in den letzten 30 Jahren so ziemlich alle Plattformen durch, sowohl auf Desktop als auch auf Server... Für den Desktop will ich nichts anderes mehr als ARM-Architektur und Mac OS... Ich genieße die Ruhe auch bei hoher Last und mit dem Betriebssystem will ich mich auch seit gut 10 Jahren nicht mehr beschäftigen müssen. Wer andere Prioritäten hat, soll sich das hinstellen, was ihm am besten gefällt.

 

[Feel Inc.]

ich hab x verschiedene hardware dran, alle mit unterschiedlichen latenzen. digitale sachen aus den 80gern haben intern schon oft 40 ms latenz. das problem hast du mit 128 samples auch nur etwas weniger. da musst du nur in ableton oder was auch immer alles etwas verzögern und so einstellen dass alle auf einer linie landen. das ist ein einfaches arithmetisches problem

das nur als tip. ich programmiere meine sequenzer selbst in pure data da ist das natürlich einfach zu machen aber jede daw kann eigentlich tracks verzögern.

Ich moduliere gerne ich Echtzeit und das letzte mal wo ich mit höherer Latenz versucht habe zu arbeiten, ging das gar nicht für mich. Aber vielleicht sollte ich mich nochmal intensiver damit auseinander setzen. Danke für den Tipp.

 

[lilak]

kauf dir mal was anständiges

der M1 ist wie alles auf ARM basis erste sahne - nur apple os würde ich auslassen weil ich gerne die komplette kontrolle über alles habe und apple da was dagegen hat. so wies aussieht läuft meine linux version auch bald auf dem m1 dann ist mein nächste dsp cruncher ein m1 mini oder ähnliches.

Ich moduliere gerne ich Echtzeit

eben dazu ist das genau gut. wenn du millisekundengenaues timing unter deinen fingern hast dann kannst du im track manche sachen vor und nacheinder kommen lassen usw. zb hier der track war mal ein showcase dafür da wandern die 3 elemente auf sinuskurven bis zu 40ms hin und her, schieben an, bremsen ab, swing kommt und geht usw. das ist jetzt OFFtopic aber mein spezialgebiet

das ist alles hardware, also kawai drum machine aus den 80ßgern, casio cz synth, minimoog, alle auf eigenen clocks und unterschiedlich verzögert.


https://soundcloud.com/lilakmonoke/yamaneko

 

[eeeeeeeeeeeeeeee]

so wies aussieht läuft meine linux version auch bald auf dem m1

Das wird nichts werden. Auch nicht in Zukunft.

 

[kybernaut_01]

dann kommt vermutlich irgendwann ein neuer virus von access was ich klasse finde. sagen wir einfach "der virus der 2000er ist legende aber der virus lebt!"

Man munkelt, der neue Virus wird dann nur noch aus einem Raspberry Pie mit DSP-Emu bestehen…