Frage an Mathematiker etc

[4t6ßweuglerjhbrd]

für die das von mir vorgeschlagene neue Synthesekonzept

https://www.sequencer.de/synthesizer/threads/super-synthese.162324/

Text dazu

wäre es sinnvoll, sich auf einen Zufallsgenerator zu einigen so daß man Seeds tasuchen kann.

Dieser sollte:
- auf allen Plattformen implementierbar sien
- mit den wenigesten und schnellesten Rechenoperationen auskommen
- möglichst viele geeignete Spektren abbilden (auf einer Länge von ca 500 Werten, Fluktuationen / Formanten vor allem im Frequenzbereich 100 bis ca 2500 - 5000 Hz)

Was ist am geeignesten?

LFSR? und wenn diese dann bräuchte man eine genaue Refernzimplementierung

 

[Turing]

Wenn das Ganze eh als Open-Source-Projekt gedacht ist, könntest Du die GNU Scientific Library (GSL) verwenden.
Die GSL ist plattformunabhängig* verfügbar und enthält diverse hochwertige Pseudo-Zufallszahlen-Generatoren.
Da sparst Du Dir eine eigene Referenzimplementierung.
Auch bietet sie FFT und anderes, was vielleicht nützlich ist.
*Ich hatte die GSL auch in Visual Studio unter Windows schon mal erfolgreich eingebunden.

Wenn ich das richtig verstanden habe, benötigst Du den Pseudo-Zufallszahlengenerator zur Realisierung eines stochastischen Suchverfahrens.
D.h. es geht darum, die Koeffizienten der Impulsantwort so zu belegen, dass eine Gütefunktion maximiert wird.
Diese Gütefunktion bewertet die Übereinstimmung des aus der Impulsantwort ermittelten Synthese-Ergebnisses mit einem Referenz-Sample.
Soweit korrekt?
Wenn das so ist, dann ist das "Durchprobieren" einer großen Zahl zufällig gewählter Koeffizienten-Vektoren zwar ein mögliches Vorgehen.
Aber besonders effektiv ist es vermutlich nicht, es kann lange dauern, bis man eine gute Übereinstimmung erreicht hat.
Auf mich wirkt es so, als könnte man da auch sehr gut genetische Algorithmen anwenden (d.h. man hat einen Pool mit den aktuell besten Kandidaten und erzeugt daraus neue durch abschnittsweise Rekombination oder durch Mutation (Änderung einzelner Koeffizienten).

 

[4t6ßweuglerjhbrd]

Danke

Ich werd mir das mal anschauen.

Ich muss es allerdingsglaub nochmal erklären denn es geht nicht um das Suchverfahren - das soll im Synth gar nicht eingebaut sein.

Es geht nur um den Synthese Teil.

Der Synth nutzt dabei kurze Random Sequenzen ähnlich wie pitchlose Wavetables, dh es wird einfach die Sequenz wiederholt abgespielt
(anti aliast mit linearer Interpolation) und dann gefiltert (gefaltet mit einerm dreieckigem Kernel).

Nach passenden Sequenzen bzw Startwerten dafür wird offline gesucht
und da kann jeder den Prozess wählen den er für geeignet hält.


Dar Anspruch an den Random Generator ist in erster Linie daß er wirklich auf jeder Plattform geht, sozusagen zeitlos und techniklos ist
und dabei so einfach wie möglich ausfällt.

Der zweite Anspruch ist, und da weiß ich nicht ob sich das überhaupt so beantworten lässt, daß eben in dem Rauschen
Abweichung möglichst so auftreten daß man Abschnitten finden kann in denen man dann Spektren finden kann
die "natürlichen" bzw deren Ablöeitungen nahekommen.

Genauer gesagt soagr nicht nur Spektren sondern idealerweise Impulse Responses, die eher minimum Phase sind,
während die Sequenzen eher maximum Length sind glaube ich.

Ich bilde mir ein daß das für den Höreindruck eine Rolle spielt, und es hat auch praktische Vorteile weil dann
die Hauptenergie am Anfang ist und auch mehr bzw die komplette Information am Anfang vorkommt.
(im Gegenstz zb zu einer genau umgekerten Funktion, die dann am Anfang kaum Information wenig Energie und nur tiefe Freuquenzen enthält)

Ich weiß nicht ob der dafür besonders gut oder besonders schlecht sein muss... oder was dann überhaupt ein Kriterium für die
Zielsetzung wäre.

Oder ob mans einfach ausprobieren muss.

Ich finde es halt super cool wenn man eine Refernzimplementation hat, und dann auch in 40 Jahren Seed
-10936782549

auf jeder Implementation des Synth nutzen kann und sie klingt immer wie erwartet.

Man kann dann Spectren diskutieren wie Wein.... oder das in Partituren angeben.


Genetische Algorithmen - wäre sehr interessant

Man könnte die Parameter des Generators mit einbeziehen, und zB 3 Zahlen suchen die verrechnet werden.

Und dann zB genetisch nach dem besten Parameterset/Algorithmus für einen Sound suchen.


Auch da wäre allerdings zuerst zu klären welchen Grund-Algorithmus man wählt.

 

[einseinsnull]

das war zwar nicht deine frage, aber compiled code schafft dependencies und das ist immer schlecht. *)

du willst nicht wirklich für 5 sprachen auf 2 betriebssystemen irgendwas dauerhaft supporten.

weswegen so zeugs auch allzuoft schon nach wenigen jahren nicht mehr verfügbar oder mit dem nächsten update inkompatibel ist und dritte dann schauen müssen wo sie es herbekommen.


wenn du richtung LSFR/XORshift denkst, dann hoffentlich nicht nur wegen dem CPU verbrauch? der dürfte nicht wirklich ins gewicht fallen. aber klar, für musik krempel genügen solche dinge, die man in der kryptographie ja eher weniger benutzen möchte.


*) ist schon klar: dein problem ist eher, dass du von den hardware dependencies von random() weg willst.

 

[Turing]

OK wenn es nicht für ein Suchverfahren ist, dann vergiss die Bemerkung zu den genetischen Algorithmen.
Von den Pseudo-Zufallszahlen-Generatoren hatte ich mal den gsl_rng_ranlxd2 genutzt.
Das wäre eine mögliche Wahl. Wie rechenintensiv dann die Erzeugung einer Pseudozufalls-Zahl ist, kann ich nicht sagen, weil es für meine Anwendung keine Rolle gespielt hatte. (Da wurde extrem hochwertiges weißes/rosa/rotes Rauschen zu Messzwecken vorgeneriert).
Die GSL ist eine wissenschaftliche Bibliothek, die seit Jahrzehnten aufgebaut und erweitert wird.
"Supported" wird die nicht, aber gepflegt und lauffähig wird sie sicher noch lange bleiben.
Nachteil bei der Benutzung ist natürlich der Overhead, man würde sich eine dicke Library reinziehen, von der nur ein Bruchteil gebraucht wird.
Und man hätte in der Tat eine Abhängigkeit (auch wenn die GSL im Source Code vorliegt und überall lokal gebaut werden kann).

 

[Turing]

Anderer Ansatz:
In welchem Framework möchtest Du das Plugin, das am Ende herauskommen soll, denn realisieren?
Du musst ja MIDI-Events handeln, eine GUI präsentieren, auf Controller reagieren, Patches speichern/laden können, Audio-Buffer befüllen usw.
Das kann man als Einzelperson kaum selbst programmieren, aber es gibt ja Frameworks, die das alles schon können.
Ich hatte selbst mal vor, einen Softsynth mit ein paar Spezialitäten zu programmieren, und da hatte ich mich für JUCE als Rahmenwerk entschieden. Unter anderem bringt JUCE auch schon seine eigene Random-Klasse mit.
=> die Wahl eines Frameworks für die Realisierung Deines Plugins könnte das Zufallszahlengenerator-Problem gleich mit lösen.
Ob die Random-Implementierung von JUCE plattform-übergreifend garantiert immer dieselbe ist, kann man Dir sicher im JUCE-Forum beantworten.

 

[4t6ßweuglerjhbrd]

JUCE haben mir schon einige empfohlen.

Ich werde aber eben aus den Gründen die Du nennst selbst kein VST machen,
das übersteigt meine Leistungsfähigkeit und meine Interessen liegen auch
zu sehr woanders als daß ich das Durchhaltevermögen dafür hätte.

Ich hatte schlicht an Pure Data gedacht (das ich auch erst lernen müsste) weil es offen, Plattform- und Compilerunabhänig ist.

Hat jetzt nicht die luxriösen Features was Patch Speicherung an geht, aber der Synth hat nur 16 Parameter.

Ist natürlich auch sehr Nische, hat aber den Vorteil daß man Details als Illustration zeigen kann.

Ansonsten würde es mir reichen ne Reaktor Version zu veröffentlichen, mich stört daran
daß es nicht offen und frei ist, und herstellerabhängig womit ich schlechte Erfahrungen gemacht habe.

wenn du richtung LSFR/XORshift denkst, dann hoffentlich nicht nur wegen dem CPU verbrauch? der dürfte nicht wirklich ins gewicht fallen. aber klar, für musik krempel genügen solche dinge, die man in der kryptographie ja eher weniger benutzen möchte.


*) ist schon klar: dein problem ist eher, dass du von den hardware dependencies von random() weg willst.

beides - es soll so effetiv wie möglich sein, und portierbarm und evtl auch einfach in Hardware ausführbar oder auf einem FPGA.

Vielleicht muss ich aber auch gar nichts machen, das will ich eigentlich hauptsächlich um zu ermöglichen und zu fördern daß Seeds immer austauschbar sind.
Das wäre ein super starkes Ding.

Es hat aber schon jemand portiert: https://github.com/bsp2/stfx/blob/master/plugins/osc/gm_rng_convolve/gm_rng_convolve.cpp

Hats aber erst vor paar Minuten gepostet, bin da noch nciht durchgestiegen, aber mit einem super Soundbeispiel wieder.

 

[einseinsnull]

Es hat aber schon jemand portiert: https://github.com/bsp2/stfx/blob/master/plugins/osc/gm_rng_convolve/gm_rng_convolve.cpp

die eigentliche arbeit ist nachher das für max oder pd zu kompilieren.

und wie man das genau macht, welche entscheidungen man da trifft, das findet man am besten heraus wenn man es erst mal IN pd baut, i.e. nur mit den mitgelieferten binaries. braucht das zuviel CPU oder schafft abhängigkeiten, kann man dann teile davon immer noch zu externals machen.

aber ich kann natürlich derzeit noch garnicht beurteilen wie sinnvoll oder wie wichtig es ist, dass dieser teil des generators (oder der ganze generator) für alle plattformen wirklich gleich sein muss. ich hab einfach nur schon mal gequarkt.

wenn ich du wäre, würde ich jedenfalls streng trennen zwischen idee/konzept/verfahren und einen kommerziellen bzw. weit zu verbreitendem produkt. nur für letzteres brauchst du diese 30 jährige kompatibiltätsgarantie.

ich kann mir übrigens prima vorstellen für jede taste andere formanten zu benutzen oder mehrere übereinander zu layern; genau solche dinge mache ich mit fof/fob/paf auch. LFOs und envelopes gehören nicht zu einem generator, das macht dann der produktdesigner. es langt völlig, wenn das ding frei schwingt und/oder geresynct werden kann.

 

[Martin Kraken]

Kleiner Off-Topic-Einwurf, gibt es überhaupt Zufallsgeneratoren die zeitlos arbeiten? Mal abgesehen davon, dass ein Computer wahrscheinlich kein Zufall erzeugen kann, sind Zufallsgeneratoren doch alle abhängig von Zeit.

 

[Turing]

@Martin Kraken
Die Abfolge ist deterministisch (immer gleich), wenn gleich initialisiert wird. Oft ist die Seed zum Initialisieren eine einzelne Zahl, für die man dann gerne die aktuelle Zeit nimmt, eben damit Variation reinkommt. Es kann aber auch Absicht sein, immer eine feste Seed zu nehmen, damit die Ergebnisse reproduzierbar immer dieselben sind.

 

[Turing]

@NoMoreWords
Kennst Du das Syntheseverfahren aus dem Tone2 Rayblaster? Gibt es da Ähnlichkeiten? Es synthetisiert auch über Impulsantworten, wenn ich mich da richtig erinnere.

 

[4t6ßweuglerjhbrd]

@NoMoreWords
Kennst Du das Syntheseverfahren aus dem Tone2 Rayblaster? Gibt es da Ähnlichkeiten? Es synthetisiert auch über Impulsantworten, wenn ich mich da richtig erinnere.

Das wurde ich auch auf Gearspace gefragt.

Ich kenne das nicht, werde aus deren Marketing Blah auch nicht schlau, bin aber recht sicher daß es mit dem Verfahren hier nichts zu tun hat.

Zitat dorrt "It creates its distinctive sound by overlapping many short bursts of energy to form a complex sound.".

Was ich vermute ist, daß es sich bei deren Verfahren entweder schlicht um granulare Synthese handelt, oder daß sie tatsächlich Impulsetrains über Convolution filtern - beides ist allerdings equivalent.

Das Verfahren das ich beschreibe basiert aber zuerst mal auf dem Variophon, und einen Synth der darauf basiert würde man einfach ganz anders konzeptionieren - eher so wie meinen - als deren Konzept.

Die Stärken der Snythese bei mir ist zuerst mal die Funktion der veränderlichen Dreieckspulswelle.

 

[2bit]

Kleiner Off-Topic-Einwurf, gibt es überhaupt Zufallsgeneratoren die zeitlos arbeiten? Mal abgesehen davon, dass ein Computer wahrscheinlich kein Zufall erzeugen kann, sind Zufallsgeneratoren doch alle abhängig von Zeit.

Ein Sample von analog erzeugtem weißem Rauschen gibt dir ziemlich sicher ein Ergebnis, das sich algorithmisch nicht wirklich wiederholen lässt. Das sollte zudem für die allermeisten User dieses Forums hier sehr einfach herzustellen sein.

Aber jetzt nicht unbedingt immer das selbe Wav-File dafür benutzen...

Generating Random Numbers From White Noise

Even though rand() may be a good enough random number generator for making a video game, the patterns of random bits it spits out may not be sufficient for applications requiring truly random data.…

hackaday.com