Organischer 3D Oszillator

[Turing]

Der andere Grund warum ich gegen FM getauscht habe ist dass die Diskontinuität bei Stimmenklau einen Spike im Differentiator des DC Removers macht,
mit dem der Pickup nicht zurecht kam.

An dem Punkt könntest Du ja mal ansetzen und die Realisierung des Stimmenklaus verbessern.
Variante a), legato-artige Umsetzung, Du behälst bei Stimmenklau einfach die momentane Phase aller Teiloszillationen (in allen Rotationsdimensionen) bei und änderst nur ab diesem Punkt die Frequenzen und Hüllkurve. Das sollte Sprünge verhindern (wenn Du auch gleitend zwischen den Hüllkurven übergehst).
Variante b), die geklaute Stimme erhält ein quick release (z.B. 6 ms).
Diesen Abschnitt kann man entweder im Voraus in einen für den Zweck geschaffenen Buffer rendern.
Oder aber man vergrößert die Zahl der Stimmen z.B. auf das Doppelte und erlaubt dann nur bei der ursprünglichen "echten" Stimmenzahl das volle Release, alle überzähligen Stimmen sind entweder off oder in einer Quick Release-Phase (und daher nach einigen Millisekunden auch off), der rechnerische Overhead für diesen Ansatz ist auch nicht sehr hoch.
Ein klick-freies Voice-Stealing kriegst Du nicht geschenkt und es würde nicht nur Dein DC-Removal-Problem lösen, sondern den Prototyp überhaupt verbessern.
Ich kann aber nicht beurteilen, wie schwer einem Faust diese Dinge macht. In einer General-Purpose-Programmiersprache sind die erwähnten Standard-Ansätze mit nicht sehr hohem Aufwand umzusetzen.

 

[einseinsnull]

@einseinsnull
Nun gibt es ja auch von mir eine mathematische Herleitung und einen PD Patch. Unabhängig von der Diskussionsdynamik hier könnte man ja Mal versuchen das nachzuvollziehen, oder?

diese meta ebene (oder besser gesagt: metaphorische ebene?) ist mir zu wichtig, als dass es mir langen würde nur für lesbaren code dafür zu sehen.

es würde mich zunächst einmal schon wirklich interessieren, was sich jemand dabei ursprünglich gedacht hat, und wenn ich dabei an einen punkt komme wo ich mich verarscht fühle sinkt dieses interesse dann eben wieder.

spätestens bei "physical modelling" stellt sich halt schon die frage, was denn da modelliert wird.

einfach nur irgendein verfahren rauszuklauben habe ich weder nötig noch wäre das ihm und seiner idee gegenüber besonders respektvoll.

das DC offset beträgt übrigens genau +√2 wenn ich mich nicht irre und mit * 2√2 kommt man ziemlich genau wieder auf eine normalisierte amplitude. das mit hochpassfiltern zu korrigieren ist für einen generator keine so tolle idee (falls die einer von euch hatte)

 

[mooncast]

Den Gleichspannungsanteil hab ich erst entdeckt, als ich das Soundfile in Audacity geladen habe Da ließ er sich ohne Nebengeräusche mit einem 20 Hertz / 12 dB Hochpass entfernen, das sollte also auch in PD gehen.

Ja das geht schon. Ich muss es aber pro Stimme machen. Der Hochpass macht aber in jedem Fall wenn der Offset sich sprunghaft ändeet einen Spike mit Tail der dann je nach Cuoff ausfällt. In der Summe hört man das nicht, im Pickup hatte mans gehört.
Der ist aber inzwischen auch umgebaut.

Hm, da scheint PD doch recht performant zu sein.

Es ist auf dem Tablet, in einer VM, im Browser.. Standalone für Android exportiert läuft es schon besser. Ich kann oder mag aber nicht dauernd Tests kompilieren lassen.

Die feinabstimmung verschlingt Monate.

Ja.

Das Problem liegt IMHO eher darin, daraus ein universell anwendbares Instrument zu machen, das Musiker wirklich anspricht.

Ja. Wobei es zwar mein Ziel ist es so universell wie möglich werden zu lassen, aber man kann auch fragen ob das sein muss, wenn man Sounds rauskriegt die "sich lohnen".
Für ein kommerzielles Produkt müsste es wohl schon mehr als einen Trick können, aber das wird es eh eher nicht werden.

kann aber nicht beurteilen, wie schwer einem Faust diese Dinge macht. In einer General-Purpose-Programmiersprache sind die erwähnten Standard-Ansätze mit nicht sehr hohem Aufwand umzusetzen.

Gute Ideen, die Phasen laufen auch schon frei weiter, das Stimmenhandling wird in Faust aber leider ausserhalb von Faust in der Umgebung in der der Audiocode nachher läuft gemanaged. Ich denke die werden automatisch reduziert und neu initilisiert, weiss es aber gar nicht genau.

 

[mooncast]

Bin jetzt wieder zurück zur 3D Version, klingt urgendwie besser.

Das mit dem DC hat sich auch gelöst, weiss aber n8cht warum.

Jedrnfalls, der Sound: fat.

Ich finde schon dass das Alleinstellungsmerkmal ist, hier mal 4 Voice single Osci:



Da schwächekt so manncger anakoge dagegen.

 

[mooncast]

das DC offset beträgt übrigens genau +√2 wenn ich mich nicht irre und mit * 2√2 kommt man ziemlich genau wieder auf eine normalisierte amplitud

das stimmt zwar nicht, aber man kann schon den mittleren Offset berechnen und abziehen.
Der Vektor ist erstmal sqrt2 wenn x und y in 90° Phase sind und gleichen Radius 1 haben.
Das ist erstmal beides nicht der Fall, da der Radius von x schneller abnimmt, mit z moduliert wird und beide noch detuned sein können.

Der mittlere Vektor ist aber sqrt( rx^2 +ry^2)/2 so dass man den abziehen und den Offset reduzieren könnte.
Das lohnt sich aber vom Rechenaufwand nicht so zumal man dennoch einen DC Filter braucht.

 

[mooncast]

Eigentlich müsste es auch gehen das Signal um 45° zu drehen.
Das würde auf eine Adfition bzw Subtraktion statt der sqrt rauslaufen.

Die Frage ist ob man das dann nicht für beide Achsen berechnet und dann zurückdreht
für stereo.
Im Grunde wär das dasselbe wie Mid Side Processing.
Das war eigentlich ähnlich mal der Plan aber das ist nicht monokompatibel.

 

[Area88]

Das war eigentlich ähnlich mal der Plan aber das ist nicht monokompatibel.

Absolute Monoinkompatibilität wäre doch nur dann gegeben, wenn die Wellenformen des linken und die des rechten Kanals erstens absolut identisch (auch im Ablauf einer zeitlichen Veränderung der Kurvengeometrie) und zweitens exakt um 180° Phasenverschoben wären (-> gegenphasige Interferenz mit dem Resultat der kompletten Auslöschung).

Willst Du letzteren Effekt vermeiden und dabei dennoch schwebungsartige Stereoeffekte erzielen, brauchst Du eigentlich nur die auf die zeitliche Varianz der Kurvengeometrie einflussnehmenden Teile des Synthesemodells der R+L-Kanäle gegenphasig mit einem niederfrequenten Sinus zu modulieren. Bei monauraler Zusammenfassung der so modulierten Einzelkanäle werden sich allenfalls Tremoloeffekte (=Amplituden"pumpen"™) einstellen, aber niemals eine konstante Auslöschung (=Addition zu Null).

[Das kommt mir deswegen in den Sinn, weil ich seinerzeit mal das Scannerphasenvibrato einer elektromagnetischen Hammond nachgebaut habe (Steinberg AVALON) und auf dem Weg dorthin den Generator der Hammond-BC (Vorläufer der B3) nachbaute. Bei den Synthese-Ergebnissen ist mir damals besagtes Amplituden"pumpen"™ im niederfrequenten Bereich aufgefallen, aber das nur am Rande...]

 

[mooncast]

Blöd wär halt wenns klanglich deutlich anders ist.
Man müsste es probieren, allerdings kämpf ich eh um die CPU, und für die Idee braucht man deutlich mehr CPU, was ich oben schrieb dass man dann die Wurzel umgehen kann war ein Denkfehler, tatsächlich muss man sie dann ja zweimal berechnen, erst dannach kann man das Signal drehen sonst ist es nicht dasselbe.

 

[mooncast]

Hba s jetzt mal auf dem RasPi getetstet. In Webassembly gehen 4 Stimmen.

Ich denke das nutzt nur 1 Core und dürfte auch n Tick langsamer sein als native,
aber ich denke die meisten Audioumgebungen werden nur 1 Core nutzen (?).

Ob die VM SIMD nutzt weiss ich auch nicht.

4 Stimmen ist bisschen wenig, grad so an der Grenze wo es noch Sinn macht.

Alleerdings läuft auch noch ein FDN Reverb, wobei ich schon gern ein Reverb drin hätte.