Turing's Slow Progress: Auf dem Weg zum eigenen Softsynth

[sdvkaeälkjb848]

Ist echt viel Stoff. Ich hatte ja den Synth mit Portaudio und Qt für die GUI gemacht und viele Sachen sind mir erst während des Machens aufgefallen, wie z.B. dass man nicht einfach 0-100% von einem Knob auf Parameter mappen sollte, da dies oft unmusikalisch usw. Oder wie man mit Polyphonie arbeitet, wann werden Noten gestohlen usw. Alles Sachen an die ich vorher gar nicht gedacht habe.

Waren echt viele Aha Effekte dabei. Ich denke, da werden dann noch ne Menge Sachen dazukommen. Ich hatte aufgehört als es dann mit Presetspeicherung usw. losging. Die Modmatrix war so das letzte was ich an dem Synth gemacht hatte. Naja und geklungen hat mein Synth halt auch nicht wirklich gut. Ab da an wusste ich aber auch so einige Pluginherrsteller zu schätzen und habe begriffen was für Arbeit dahintersteckt.

Bei DSP, inbesondere Filter, habe ich auch noch einiges nachzuholen. Selbst Filter Koeffizienten erstellen usw. wäre sicher auch mal lehrreich. Ist aber dann nochmal ein Thema für sich. Bis jetzt habe ich nur fertige Filter verwendet, schame on me.

Seit neustem habe ich für mich auch die ADC(Audio Developer Conference) entdeckt, besonders spannend finde ich ja die "neue" Art von Schaltungssimulation. Aber um da was zu machen braucht man sicher die Kennlienen der alten Bauteile und zwar nicht die aus dem Datenblatt, sondern dann real gemessen, damit man auch die ganzen Eigenheiten mit drin hat. Das ist dann natürlich eine Hausnummer zu hoch für mich und eher was für die Profis von Softube, u-he usw.

Auch sehr spannend dürfte Maschine Learning werden, nicht um Musik zu komponieren, sondern z.B. zur Synthese usw. oder vielleicht auch Filterdesign, so unter dem Motto: Hier hast du Impulse Responses vom Filter eines Vintage Gerätes, bau mir ein Modell was genauso klingt. Da sind sicher auch noch ganz andere verrückte Sachen mit ML drin an die man noch gar nicht denkt. Vielleicht neue Syntheseformen. Ach, die Zukunft ist sooo spannend.

https://www.youtube.com/@audiodevcon

Auf jeden Fall ein spannendes Thema seinen eigenen Synth zu bauen, auch wenn ich da bis jetzt nur an der Oberfläche gekratzt habe.

 

[einseinsnull]

mappen sollte, da dies oft unmusikalisch usw. Oder wie man mit Polyphonie arbeitet, wann werden Noten gestohlen usw. Alles Sachen an die ich vorher gar nicht gedacht habe.

ich sag da mal ganz frech, arithmetik und logik sind die absoluten grundlagen, solche dinge wie range mapping und -disrtortion z.b. braucht man ständig.
aber es ist auch klar, dass man nicht als dr. prof. dipl. sonstwas auf die welt kommt, irgendwann macht man alles zum ersten mal. manche sachen lernt man in 5 minuten, bei anderen hängt man wochenlang fest und gibt sie irgendwann auf.

Waren echt viele Aha Effekte dabei.

die VST SDK beispiele u.ä. waren, was diese dinge angeht, niemals besonders hilfreich.

Bei DSP, inbesondere Filter, habe ich auch noch einiges nachzuholen. Selbst Filter Koeffizienten erstellen usw. wäre sicher auch mal lehrreich.

kann man notfalls alles irgendwo abschreiben. wenn man das denn will, denn das gibt es alles auch fix und fertig, für juce eh, aber auch für c++ oder die einschlägigen audio umgebungen.

die eigentliche kunst ist nachher vor allem herauszufinden, ob du die filter in signal rate oder in gröberen schritten berechnen willst, wann du upsampling brauchst, wie du sie miteinander kombinierst, wie du sie geräusch- und explosionsfrei ein und ausschalten kannst und all der scheiß.

im kern sind poles and zero filter und auch ladder filter letztlich "nur" ein bischen mathematik.

Ist aber dann nochmal ein Thema für sich. Bis jetzt habe ich nur fertige Filter verwendet, schame on me.

das macht die hälfte der kommenrziellen anbieter von software genauso.

schämen müsstest du dich nur, wenn deswegen küken geschreddert werden müssen.

Seit neustem habe ich für mich auch die ADC(Audio Developer Conference) entdeckt

die apple support mailinglisten sind mir ein bischen zu low noise und geheimniskrämerisch. im öffentlichen forum ist es umgekehrt, da labern dann hinz und kunz mit und fragen sich gegenseitig wie man ein USB platte an einen imac anschließt.

besonders spannend finde ich ja die "neue" Art von Schaltungssimulation.

um gottes willen, dann muste ja auch noch eletrokrotechnik profi sein.


wir können das beenden oder auslagern falls turing das hier sonst nervt.

 

[sdvkaeälkjb848]

Danke für deine kompetenten Antworten, ich möchte den Thread hier auch nicht kapern. Ich kenne bis jetzt auch nur das KVR-Forum wie man recht viel über das Thema lesen kann. So in deutsch ist mir leider nichts bekannt. Ich weiß nicht ob auch andere Pluginentwickler hier unterwegs sind und sich dann vielleicht sogar ein kleiner Bereich hier lohnen würde.

 

[Turing]

Ist soweit OK, aber auf Dauer wäre ein gesonderter Thread für diese Fragen sicher besser. Da würde ich mich dann auch einbringen.

Das Thema Filter-Design hatte ich oben bei den JUCE-Features ganz vergessen, weil ich es für mein Projekt dann doch nicht gebraucht habe.
Ist aber auch in JUCE sehr bequem nutzbar. Man kann einfach sagen, ich hätte gern ein IIR- oder FIR-Filter mit einer bestimmten Charakteristik (wie Butterworth-Tiefpass), einer bestimmten Breite des Übergangsbereichs und einer bestimmten Welligkeit im Passband und im Stopband, und es werden die passenden Koeffizienten für die benötigten Filterstufen ausgespuckt. Den Amplituden- und Phasengang kann man sich auch dazu ausgeben lassen.

Für das Plugin spielt das im Moment keine Rolle, weil es im Prinzip eine große "Fourier-Maschine" ist und jede Stimme live aus den Fourier-Koeffizienten der Wavetables (und weiteren Größen) synthetisiert. Da kann der Effekt des Filters auch gleich durch Anpassen der Koeffizienten oder der Synthese selbst realisiert werden.

Der Punkt, der mir am meisten Schwierigkeiten macht, ist das Modulationssystem.
Deshalb fehlt es auch noch komplett.
In JUCE gibt es leider keine Vorstrukturierung oder Referenzlösung, an der ich mich orientieren könnte, und die JUCE-Tutorials sind in dieser Hinsicht nicht ergiebig.

Für das Modulationssystem sind verschiedene Herangehensweisen möglich.

• Aktualisierung in einem festen Zeitraster (z.B. 600 Hz / alle x Samples).
  Das Modulations-Zeitraster passt dann aber nicht unbedingt zur Blockeinteilung für das Audio-Rendering und zu den Note-One-Events (falls mit dem Note-On z.B. auch eine Hüllkurve oder ein LFO starten soll).
  
  
• Event-basierte Umsetzung ("aktualisiere diesen Wert nach y Samples", "beende diese Ramp nach y Samples und ermittlte dann den Zielwert für die nächste Ramp").
  Es gibt dann also ein flexibles Raster, und die Events, die an bestimmten Zeitpunkten hängen, betreffen jeweils nur bestimmte Parameter, bei denen neue Vorgabewerte zu setzen sind.
  Man braucht dann eine Engine zur Abarbeitung der Events, die bei jedem Sample weiß, welche Parameter an dieser Stelle zu modifizieren sind.
  (Ohne durch alle iterieren zu müssen).

Hat jemand Erfahrung, welche anderen Möglichkeiten es noch gibt und wie man das Ganze am besten aufsetzt?
Ziel ist eine allgemeine Modulations-Matrix, in der man am besten alles mit allem verknüpfen kann.

Weitere Schwierigkeiten mit dem Modulationssystem, wenn wir schon dabei sind:

• Wie ist mit Zyklen in der Modulationsmatrix umzugehen? (Wenn die Abhängigkeiten der Parameter eine geschlossene Kette ergeben).
  Soll man das vorab erkennen (DFS-Algorithmus) und die Eingabe von zyklischen Modulationen verbieten, oder erlaubt man es einfach und die Umsetzung der Modulation muss es robust handlen?
  
  
• Neben Voice-basierten LFOs hat man vielleicht auch gerne globale (z.B. freilaufende) LFOs.
  Wenn ein globaler LFO nun einen Voice-Parameter moduliert, ist das ja einfach umzusetzen.
  Wie ist es aber umgekehrt? Theoretisch könnte ich in der Modulationsmatrix einen Eintrag machen, bei dem irgendein Voice-bezogener Parameter (wie Velocity) auf einen globalen LFO wirkt (z.B. Geschwindigkeit des LFOs).
  Verbietet man solche Voice-Ebene→Global-Modulationen oder lässt man sie zu? Falls man sie zulässt, wie kann man sie sinnvoll abarbeiten (es gibt ja potenziell mehrere Stimmen, deren Velocity dann im Beispiel auf die Geschwindigkeit des globalen LFOs wirken würde).
  
  
• Wie gehe ich mit Plugin-Nap um (d.h. wie aktualisiere ich den Stand des Modulationssystems, wenn die DAW auf die Idee kommt, das Plugin für n Samples schlafen zu lassen)?

Falls hier jemand Rat hat und aus Erfahrung ein paar Tipps geben kann, würde mir das sehr helfen.

 

[sdvkaeälkjb848]

Das Thema Filter-Design hatte ich oben bei den JUCE-Features ganz vergessen, weil ich es für mein Projekt dann doch nicht gebraucht habe.
Ist aber auch in JUCE sehr bequem nutzbar. Man kann einfach sagen, ich hätte gern ein IIR- oder FIR-Filter mit einer bestimmten Charakteristik (wie Butterworth-Tiefpass), einer bestimmten Breite des Übergangsbereichs und einer bestimmten Welligkeit im Passband und im Stopband, und es werden die passenden Koeffizienten für die benötigten Filterstufen ausgespuckt. Den Amplituden- und Phasengang kann man sich auch dazu ausgeben lassen.

Cool, das klingt ja spannend.

Der Punkt, der mir am meisten Schwierigkeiten macht, ist das Modulationssystem.
Deshalb fehlt es auch noch komplett.
In JUCE gibt es leider keine Vorstrukturierung oder Referenzlösung, an der ich mich orientieren könnte, und die JUCE-Tutorials sind in dieser Hinsicht nicht ergiebig.

Für das Modulationssystem sind verschiedene Herangehensweisen möglich.

• Aktualisierung in einem festen Zeitraster (z.B. 600 Hz / alle x Samples).
  Das Modulations-Zeitraster passt dann aber nicht unbedingt zur Blockeinteilung für das Audio-Rendering und zu den Note-One-Events (falls mit dem Note-On z.B. auch eine Hüllkurve oder ein LFO starten soll).
  
  
• Event-basierte Umsetzung ("aktualisiere diesen Wert nach y Samples", "beende diese Ramp nach y Samples und ermittlte dann den Zielwert für die nächste Ramp").
  Man braucht dann eine Engine zur Abarbeitung der Events, die bei jedem Sample weiß, welche Parameter an dieser Stelle zu modifizieren sind.
  (Ohne durch alle iterieren zu müssen).

Hat jemand Erfahrung, welche anderen Möglichkeiten es noch gibt und wie man das Ganze am besten aufsetzt?
Ziel ist eine allgemeine Modulations-Matrix, in der man am besten alles mit allem verknüpfen kann.

Meine Implementierung war Audioratebasis also samplegenau, was aber auch ganz schön Rechenzeit frisst. Der Synth war ja völlig nur zum Testen, habe dafür ja auch kein VST-SDK oder so was genutzt, sondern nur Portaudio um einen Audiobuffer zu haben, den ich füllen kann, und dann eben Qt, damit ich eine GUI zur Steuerung habe. Rest war alles handgemacht.

meine Renderloop hier mal, aber wie gesagt, das ist alles Testcode, nix effektives

 

[Turing]

Danke für das Beispiel.

Eine sample-genaue Umsetzung mit Audio-Rate finde ich auch am besten nachvollziehbar.
Leider ist das vom Rechenzeitbedarf her wohl bei meinem Plugin nicht machbar.

Wenn man nun ein festes Zeitraster hat - oder ein flexibles bei Events - dann hat man quasi Abtastwerte der Modulationsgrößen und es würde sich ein treppenförmiger Verlauf ergeben.
Den man natürlich so nicht haben möchte.
Also muss man dann glätten.
Eine lineare Rampe, die den Zielwert erst nach einer gewissen Anpassungszeit t erreicht, führt aber effektiv zu einer Latenz des Modulationssystems.
Wäre es da nicht besser, den voraussichtlich zum Zeitpunkt t zu erwartenden Zielwert zu ermitteln und die Rampe zu diesem hin laufen zu lassen?

Ich weiß nicht, ob das praktikabel ist und ob irgendjemand das tatsächlich so macht.

Außerdem mache ich mir Gedanken um folgendes:

Bei einer festen Frequenz des Modulationssystems von z.B. 600 Hz gibt es Aliasing, wenn die abgetasteten Werte Änderungen mit mehr als der Nyquist-Frequenz (hier dann 300 Hz) enthalten.
Bei einer zackigen Envelope oder einem Sägezahn- oder Rechteck-LFO sind solche schnellen Änderungen aber zu erwarten.
Dem könnte ich durch Glättung der LFO-Wellenformen und (ziemlich sicher unerwünscht!) des Envelope-Verlaufs begegnen.
Macht so etwas irgendjemand? Oder bleiben die Aliasing-Artefakte des Modulationssystems unhörbar, weil sie nur sehr indirekt auf das klangliche Ergebnis wirken, und können daher ignoriert werden?
Oder sie sind zwar irgendwie hörbar, aber man nimmt sie in Kauf, weil z.B. eine langsame Envelope deutlich störender wäre?

 

[sdvkaeälkjb848]

Wäre echt mal schön zu erfahren wie Profis so eine Modmatrix umsetzen.

 

[Turing]

Hier nochmal eine Demo mit dem aktuellen Verfahren:

Anhang anzeigen 199015

(eine mit dem Joué improvisierte Spur, Synth-Plugin, Hall aus Seventh Heaven Professional).

Falls jemand wissen möchte, wie der Joué Controller mit dem Scaler-Modul für diese und die anderen Demos konfiguriert wurde, hier ein paar Screenshots aus dem Joué-Editor, die die verwendeten Einstellungen zeigen:



Glissando, Aftertouch und MPE sind grundsätzlich aktiviert, Advanced Settings stehen auf den Defaults.
Im "Midi Mapping"-Bereich ist eine diatonische Belegung (Ionian Major mit First Note 48 - C2) ausgewählt.
Velocity-Bereich ist 50..127.
Y Control ist aktiv, geht an MPE Slide (CC 74), hat die natürliche Richtung und ganz wichtig: nutzt den Absolute-Mode (d.h. das initiale MPE-Timbre entspricht bereits der Anschlagsposition auf der Taste).

Der linke Button wirkt als Sustain-Pedal:



Der rechte Button kann genutzt werden, um die Steuerung von Slide/CC74 über die Y-Position ein- oder auszuschalten
(im Off-Modus wird fest der mittlere Wert 64 genutzt):



Der Strip fungiert als Modwheel (das wurde in den Demos aber bisher nicht genutzt):



Die Absolute-Y-Einstellung funktioniert aktuell nur in Ableton Live 11, in meiner eigentlich präferierten DAW Studio One leider nicht.
(Ich habe vor längerer Zeit dort ein Ticket eröffnet, die PreSonus Support-Leute haben sich damit auch beschäftigt und verschiedene Informationen erfragt, um das Problem reproduzieren zu können. Leider wurde es seitdem in Studio One noch nicht gefixt).
So bin ich jetzt seit einiger Zeit gezwungen, Ableton Live zu verwenden.
Dort ist die folgende Anpassung erforderlich, um einen guten Kompromiss zwischen Intonation und Bending-/Vibrato-Möglichkeiten zu erhalten:



Die Pitch-Bend-Range wird auf 3 Halbtöne nach unten und 3 Halbtöne nach oben eingeschränkt.

Auf dem Scaler wird ein Glissando bzw. Pitchbend so gespielt, dass man den Finger, der die zu bendende Note drückt, ganz einfach zur Seite über die anderen Tasten zieht. (Der Joué ist clever genug, dass man in dieser Bewegung auch andere gerade gedrückte Tasten "kreuzen" kann, ohne dass das Glissando der gezogenen Note dadurch abreißt und ohne dass die anderen klingenden Noten durch diese Überkreuzung gestört werden).

Bei der obigen Einstellung in Ableton Live bewirkt eine Bewegung des Fingers um 7 Tasten des Scalers (entsprechend einer Oktave auf der Tastatur) dann einen Bend von einem Ganzton.
Das ist für mich eine ganz passende Range.
Außerdem ist die Intonation von Akkorden dann noch ausreichend genau und man kann sehr gut ein Vibrato realisieren (durch Hin- und Herbewegen des Fingers auf einer einzelnen Taste).
Bei noch größeren Bend Ranges klingen Akkorde tendenziell schon etwas schräg (weil man die Tasten nicht exakt genug trifft) und die Töne werden etwas jaulig.

Fast alle bisherigen Demos für das Plugin wurden mit dieser Einstellung auf dem Scaler eingespielt.

Ausnahmen sind "Extinction" (auf dem Joué Grand Clavier-Modul ohne MPE eingespielt) und die erste Demo hier im Startbeitrag des Threads (auf dem Grand Clavier mit MPE eingespielt, aber mit relative Y-Mode, weil das Grand Clavier-Pad den absoluten Modus nicht anbietet).

Der absolute Y-Modus (beim Scaler) ist für die Demos wichtig, weil MPE Slide / CC74 im Plugin bisher fest an die Wavetable-Position gekoppelt ist.
Wenn ich mir einmal einen Eindruck verschafft habe, wie die Wavetable an welchen Anschlagspositionen (Taste vorne - mittig - am oberen Rand) klingt, kann ich bei jeder gespielten Note entscheiden, wie sie klingen soll. Besonders nett ist das natürlich, wenn man mehrstimmig spielt. Da kann die eine Stimme dann mehr nach Cello oder Brass klingen und die andere z.B. mehr Melodica-artig, wie in der letzten Demo. Oder für die hohen Noten kann über die Anschlagsposition ein anderer Sound gewählt werden als für die mittleren Stimmen oder den Bass. In der letzten Demo wurde so auch das Überblasen (oder Überstreichen?) in die Oktave realisiert, das man am Anfang der Demo hört und das auch ganz am Ende für die abschließenden Akkorde genutzt wird.

 

[Turing]

Orgelt ihr gerne?

Wir verlassen mal die cinematische Ecke und damit meine spielerische Komfort-Zone für die Demos.
Im Laufe der Zeit sind hier bestimmt 30 Orgel-Patches aufgelaufen.
Für die Demo habe ich einfach den ersten herausgegriffen, den ich mit dem neuesten Multi-Unisono/Textur-Generierungs-Verfahren erstellt hatte, und ein bisschen herum improvisiert.
Ihr hört den Patch in zwei Varianten, die sich in der Interpolationsart unterscheiden: einmal monotone kubische Splines, einmal freie kubische Splines.
Die freien (d.h. nicht künstlich monoton gemachten) kubischen Splines klingen meist frischer und lebendiger, die monotonen Splines glatter, aber manchmal auch etwas leblos.
Was mögt ihr bei der Orgel lieber - oder hört es sich für Euch tendenziell gleich an?

Monotone Interpolation:
Anhang anzeigen 2023-12-30-Demo-Organ-Monotone.mp3

Freie Interpolation:
Anhang anzeigen 2023-12-30-Demo-Organ-FreeHiQ.mp3

 

[DanReed]

Vermutlich ist meine Zwischenfrage etwas ketzerisch, aber trotzdem:
Ist es eigentlich möglich, die Verzerrungen auszuschalten oder sind sie Teil der Synthese? (Feature?)

 

[Turing]

@DanReed
Der etwas schwurbelige Klang in der Orgel-Demo ist bewusst reingedreht und somit gleichzeitig ein Feature als auch abschaltbar.
In dem Patch fehlen auch noch ein paar Glättungen durch Parameter, die ich erst später eingeführt habe.
Dadurch könnten die einzelnen Voices Modulationsartefakte enthalten, die wie Verzerrungen klingen.
Aber ich habe auch das Gefühl, dass in der Aufnahme etwas nicht stimmt. Muss ich prüfen.
Vielleicht ein Problem an einer Systemgrenze oder der interne Clipper des Plugins.
Ich kann auch prüfen, ob es sich klarer anhört, wenn ich die erwähnten Glättungen (abweichend vom ursprünglichen Patch) aktiv schalte.
EDIT:
Ich hoffe, Du sprichst nur von dem letzten Beispiel mit den Orgel-Sounds?

 

[einseinsnull]

Für das Modulationssystem sind verschiedene Herangehensweisen möglich.

• Aktualisierung in einem festen Zeitraster (z.B. 600 Hz / alle x Samples).
  
  
• Event-basierte Umsetzung ("aktualisiere diesen Wert nach y Samples", "beende diese Ramp nach y Samples und

Hat jemand Erfahrung, welche anderen Möglichkeiten es noch gibt und wie man das Ganze am besten aufsetzt?

die best practice ist deine best practice.

für synthesizer ist es vermutlich am besten sich gar nicht so sehr davon beeinflussen zu lassen, dass es eine subclass AudioParameterFloat für AudioProcessorParameter gibt und daneben und darunter noch 5 andere, sondern ich würde einfach immer überall die gleiche methode verwenden und der rest, interpolation usw., passiert dann in DSP (aka "schreibst du selbst")

in blöcken unabhängig von der vectorsize zu wandeln würde ich persönlich nicht und sehe auch keine anwendung dafür. samples, vektoren, oder "nur wenn sich was ändert" wären wohl die üblichsten raten.

wann es ausreicht nur zum ersten sample des nächsten vektors einen wert durchzulassen musst du ausprobieren.

für einen internen LFO auf die lautstärke macht das vermutlich eher wenig sinn. anders sieht das aus, wenn der user nachher mit einem schieberegler von 200 pixeln länge (und demzufolge niedriger auflösung) an einem biquad herumschraubt. da ist es meist ausreichend das in vektoren zu machen, so dass die mausbewegung eben in ein 0,7 millisekunden grid quantisiert wird.
was im übrigen ja nicht ausschließt, dass du das control signal hinterher sogar noch interpolierst, ggf. auch über mehr als den einen vektor.

also faustregel: wenn die werte nur sehr grob sind, kannst du auch auf die zeitgenauigkeit scheißen.

ich lebe natürlich in einer ganz anderen welt und kann dir nichts über juce oder C erzählen, aber ich habe früher bei plug-ins immer alle parameter grundsätzlich auf 0-1 normalisiert, das DSP so gebaut wie es eben war, und für die verlinkung dazwischen habe ich dann meine eigene lösung gebaut, die ich um die "übersetzung" der wertebereiche, MIDI I/O und diese dinge kümmert.
in meiner welt werden aber auch dinge wie "hidden" automatisch von der runtime erledigt und du musst dafür garnix selbst machen.

auf signal ebene selbst bleibe ich ansonsten natürlich auch so lange wie möglich im bereich von 0-1, was für deine anforderung "modulationsmatrix" unbestreitbare vorteile hat.
das führt leider dazu, dass man teure umformungen wie notenummer zu hertz oder decibel zu gain auf die signalebene verschieben muss, aber das muss es einem dann wert sein. (wirklich niemand will ein portamento in hertz bauen.)

 

[einseinsnull]

diese joue sind übrigens sehr hübsch, eines der besten aktuell erhältlichen radio batons.

nur schade, dass es die nicht in größer gibt und dass man sich keine matten nach eigenem bedarf anfertigen lassen kann. (ich hätte gerne ein ganz glattes, texturfreies)

 

[Cyclotron]

Eine sample-genaue Umsetzung mit Audio-Rate finde ich auch am besten nachvollziehbar.
Leider ist das vom Rechenzeitbedarf her wohl bei meinem Plugin nicht machbar.

Wenn man nun ein festes Zeitraster hat - oder ein flexibles bei Events - dann hat man quasi Abtastwerte der Modulationsgrößen und es würde sich ein treppenförmiger Verlauf ergeben.
Den man natürlich so nicht haben möchte.
Also muss man dann glätten.
Eine lineare Rampe, die den Zielwert erst nach einer gewissen Anpassungszeit t erreicht, führt aber effektiv zu einer Latenz des Modulationssystems.
Wäre es da nicht besser, den voraussichtlich zum Zeitpunkt t zu erwartenden Zielwert zu ermitteln und die Rampe zu diesem hin laufen zu lassen?

Ich weiß nicht, ob das praktikabel ist und ob irgendjemand das tatsächlich so macht.

Außerdem mache ich mir Gedanken um folgendes:

Bei einer festen Frequenz des Modulationssystems von z.B. 600 Hz gibt es Aliasing, wenn die abgetasteten Werte Änderungen mit mehr als der Nyquist-Frequenz (hier dann 300 Hz) enthalten.
Bei einer zackigen Envelope oder einem Sägezahn- oder Rechteck-LFO sind solche schnellen Änderungen aber zu erwarten.
Dem könnte ich durch Glättung der LFO-Wellenformen und (ziemlich sicher unerwünscht!) des Envelope-Verlaufs begegnen.
Macht so etwas irgendjemand? Oder bleiben die Aliasing-Artefakte des Modulationssystems unhörbar, weil sie nur sehr indirekt auf das klangliche Ergebnis wirken, und können daher ignoriert werden?
Oder sie sind zwar irgendwie hörbar, aber man nimmt sie in Kauf, weil z.B. eine langsame Envelope deutlich störender wäre?

Das (edit: Latenz) ist unvermeidlich, auch in der Natur. Jedes physikalische System reagiert mit einer gewissen Trägheit auf Änderungen seiner Parameter. In der digitalen Domäne kann man zwar Parameter samplegenau setzen, aber ungeglättet führt dass u.U. zu breitbandigen Artefakten. Daher muss man sich von "samplegenau" verabschieden, wenn man derartige Artefakte vermeiden will. Es ist der alte digitale Kompromiss zwischen Genauigkeit und Bandbreite.

Generell würde ich versuchen, eher Parameter als Modulationsignale zu glätten und letztere (Envelope, LFO etc.) mit hinreichend hoher Samplerate laufen zu lassen: Wenn Audiorate - Modulation gewollt ist, muss das Modulationssignal auch mindestens mit Audiorate laufen.

Irgendwelche Filter (Tiefpässe, Interpolatoren) als Ausgleich für eine zu niedrige Samplerate am Ausgang des Modulators sorgen nur dafür, dass die Modulationstiefe um so mehr abnimmt und verwischt, je näher Dein Modulationssignal sich der Grenzfrequenz des Filters nähert. Und die muss bei 600 Hz Updaterate ja zwangsläufig deutlich unter 300 Hz liegen, sonst ist sie dank Nyquist sinnlos.

Ob und wie sich Aliasing bemerkbar macht, hängt von der Quelle und dem Ziel ab. Eine Envelope, die die Amplitude moduliert, ist eher unkritisch.

Ein Gegenbeispiel wäre die Modulation der Pitch mittels zyklischem LFO: Da bekommt man sehr schnell hörbares Aliasing in Form von Stolpern und Wobbeln. Insbesondere, wenn man dann noch eine LFO Shape mit vielen Obertönen verwendet. Da ich bei meinem Synth auch arge Ressourcenprobleme hatte (15 Jahre alte CPU im Rechner), musste ich meine LFOs mit ~5 kHz berechnen und die Schwingung bandlimitiert generieren. Diese Bandlimitierung erfolgte abhängig von der Abtastrate der DAW und der aktuellen LFO Frequenz, so dass ein ein langsamer Square LFO -> Pitch immer noch einen definierten und exakten Tonhöhensprung erzeugt. Macht man das nicht dynamisch, hat man zwar kein Aliasing bei hoher LFO Rate, aber auch keine definierte Rechteckmodulation bei langsamen Geschwindigkeiten mehr. Das simple Glätten des LFO Ausgangs ist wie schon beschrieben keine Lösung, denn das Aliasing entsteht vor dem Filter im LFO selbst und pflanzt sich dann bis in das Audiosignal fort.

Eine Lösung bei knappen Ressourcen für die Matrix wären beispielsweise zwei Matrizen: Eine kleine, schnelle für Audiorateverknüpfungen und eine große, aber langsamere für Modulationen mit begrenzter Geschwindigkeit.


Sorry, wenn das alles etwas stückwerkhaft und in teilen repetitiv ist - bitte eher als Brainstorm verstehen denn als geschlossene Abhandlung.

 

[Turing]

@einseinsnull @Cyclotron
Danke für den Input zum Thema Modulationssystem.
Ich hoffe ja, das Thema im kommenden Jahr angehen zu können, dann werde ich das berücksichtigen.
Das Pitch-Modulations-Beispiel scheint ein kritischer Fall zu sein, der auf jeden Fall getestet werden muss.

 

[Turing]

diese joue sind übrigens sehr hübsch, eines der besten aktuell erhältlichen radio batons.
nur schade, dass es die nicht in größer gibt und dass man sich keine matten nach eigenem bedarf anfertigen lassen kann. (ich hätte gerne ein ganz glattes, texturfreies)

Ich bin auch etwas unglücklich mit der Ausrichtung von Joué.
Der neue Joué Play ist noch etwas leichter als der alte, die Matten werden nicht mehr magnetisch fixiert, für mich geht das in die falsche Richtung.
Ich weiß nicht, ob dieser Gedanke, dass mit einem Joué Controller wirklich jeder Musik machen kann, nicht eine fixe Idee von Joué ist.
Sprich man richtet sich mit einem billigeren Produkt an eine Käufermasse, die es so aber vielleicht gar nicht gibt.
Was ich mir wünschen würde, wäre auch eine etwas größere Version, die genauso hochwertig ist wie der klassische Joué (den ich bevorzugt spiele).
Die Rillen zwischen den Tasten finde ich beim Sliden auch störend und hätte das Pad auch lieber ganz glatt.
Der neue Joué (Joué Play) hat gefühlt noch etwas deutlichere Rillen und die Tasten wirken dicker und härter. Ich mag die Haptik nicht. Er ist nicht so feinfühlig spielbar.
Deshalb habe ich Restbestände der alten Pads aufgekauft, um noch sehr lange mit dem alten Joué spielen zu können, selbst wenn sich die Auflagen abnutzen sollten.
Leider gibt es kaum Alternativen. Ich liebäugele mit einem Haken Slim Continuum, aber der ist preislich schon eine Hausnummer.

 

[sdvkaeälkjb848]

Orgelt ihr gerne?

Wir verlassen mal die cinematische Ecke und damit meine spielerische Komfort-Zone für die Demos.
Im Laufe der Zeit sind hier bestimmt 30 Orgel-Patches aufgelaufen.
Für die Demo habe ich einfach den ersten herausgegriffen, den mit dem neuesten Multi-Unisono/Textur-Generierungs-Verfahren erstellt habe.
Ihr hört den Patch in zwei Varianten, die sich in der Interpolationsart unterscheiden:
einmal monotone kubische Splines, einmal freie kubische Splines.
Die freien (d.h. nicht künstlich monoton gemachten) kubischen Splines klingen meist frischer und lebendiger, die monotonen Splines glatter, aber manchmal auch etwas leblos.
Was mögt ihr bei der Orgel lieber - oder hört es sich für Euch tendenziell gleich an?

Monotone Interpolation:
Anhang anzeigen 199318

Freie Interpolation:
Anhang anzeigen 199319

Ich glaube, die "Freie Interpolation" hört sich "luftiger" an, ob ich das auch so in einem Blindtest hören würde, weiß ich allerdings nicht. Wenn man weiß was man hört, hat man ja eigentlich schon fast verloren. Die Psyche ist ja bei Details oft im Weg.

 

[Turing]

Danke fürs Feedback. Ich mache das beim nächsten mal als Blindtest.

 

[einseinsnull]

Eine Lösung bei knappen Ressourcen für die Matrix wären beispielsweise zwei Matrizen: Eine kleine, schnelle für Audiorateverknüpfungen und eine große, aber langsamere für Modulationen mit begrenzter Geschwindigkeit.

und bei ihm kommt dann ja auch noch pro-stimme vs. global dazu.


über wieviele parameter reden wir denn, dass das zu teuer wird?

 

[einseinsnull]

Leider gibt es kaum Alternativen. Ich liebäugele mit einem Haken Slim Continuum, aber der ist preislich schon eine Hausnummer.

mit dem seaboard hatte ich das gleiche problem. da ist etwas endlich mal frei programmierbar und kann quasi-kontinuierlich pitch ausgeben - und dann wird das zur berg- und talfahrt und man fängt unweigerlich an nur noch klavier darauf zu spielen.

das continuum ist um länger besser spielbar. aber vergiss das mini, schon wegen der geringen polyphonie.

was issn das joue fürn material? auch neopren? das könnte man sich ja vielleicht auch irgendwie selbst...

 

[Turing]

und bei ihm kommt dann ja auch noch pro-stimme vs. global dazu.
über wieviele parameter reden wir denn, dass das zu teuer wird?

Nicht alle Parameter sind live änderbar bzw. automatisierbar.
Bei den automatisierbaren Parametern soll man aber alles mit allem verknüpfen können, ich möchte kein Vorab-Limit auf die Zahl möglicher Modulationen.
Ich rechne mit etwa 50-100 automatisierbaren Parametern für einen Oszillator. Bei mehreren Oszillatoren pro Stimme würde das sich entsprechend vervielfachen.
Dazu kämen dann noch Parameter für Envelope Gates, LFOs, Operatoren, eventuell Filter und weitere Funktionalität.
Zu teuer wird die Audio-Rate-Verarbeitung aller Modulationen deshalb, weil das Plugin schon jetzt sehr leistungshungrig ist und ich nicht viele Reserven habe.
Da möchte ich die Rechenpower lieber für die eigentliche Synthese verbraten und nicht für die Modulation. Ist aber vielleicht eine falsche Sichtweise.
Ohne Modulationssystem ist das Plugin eben sehr eingeschränkt und eigentlich nur mit MPE-Controller sinnvoll nutzbar.

mit dem seaboard hatte ich das gleiche problem. da ist etwas endlich mal frei programmierbar und kann quasi-kontinuierlich pitch ausgeben - und dann wird das zur berg- und talfahrt und man fängt unweigerlich an nur noch klavier darauf zu spielen.
das continuum ist um länger besser spielbar. aber vergiss das mini, schon wegen der geringen polyphonie.
was issn das joue fürn material? auch neopren? das könnte man sich ja vielleicht auch irgendwie selbst...

Das Seaboard habe ich aus dem Grund auch für mich verworfen. Beim Continuum denke ich nicht an das "Mini", sondern an das "Slim" Continuum 46s8x, das bis zu 16 Finger simultan tracken kann und zumindest 4 Oktaven abdeckt:

Haken Audio Slim Continuum 46s8x


Leider nicht gerade etwas für den nächsten Spontankauf.

Die Pads beim Joué sind meines Wissens aus Silikon, die Unterseite fühlt sich Neopren-ähnlich an.
Leider kann man hier nicht kreativ werden, weil sich jedes Joué-Pad per RFID beim Controller identifiziert und weil dieser dann die entsprechende Geometrie auf die Eingaben aus dem Pad legt.
Man kann noch nicht mal die von mir bevorzugten "Classic" Pads des alten Controllers auf einen neuen Joué Play legen.
Beim Semsel Morph gab es (soweit ich mich erinnere) diese Möglichkeit, ein eigenes Blank Pad zu nehmen und selbst zu gestalten. Aber der Morph ist ja nicht mehr am Markt.

 

[einseinsnull]

ok, 50-100 pro stimme erklärt das problem bereits aureichend, ich war jetzt auf "12-15" gefasst.

es bliebe dir, die modulation eines parameters und/oder jede einzelne quelle/ziel node stets nur optional einzuschalten.

aka nur wenn eine zuordnung vorgenommen wird, wird das control signal über die matrix geschickt (wo es dann z.b. multiplikation und addition durchläuft), andernfalls wird die node nicht berechnet und das steuersignal ist statisch.

das signal e.g. vom LFO zu den ausgeschalteten nodes ist dadurch sozusagen auch "off".

 

[Turing]

Aus der Matrix müsste eine Art Abhängigkeitsgraph abgeleitet werden, der nur das beinhaltet, was relevant ist und tatsächlich moduliert wird.
Aus dem Abhängigkeitsgraph würde sich dann eine Abarbeitungsreihenfolge ergeben und benötigte Zwischenspeicher zum Aufsammeln von Teilergebnissen.
Das ist im Moment mein Grundansatz, wie ich das Ganze lösen möchte.
Auf dem Graphen würde dann auch die Prüfung auf Zyklen durchgeführt werden.
Im Moment würde ich dazu tendieren, Zyklen schon bei der Eingabe abzufangen.
Für die Einbindung eines "globalen" LFOs habe ich noch keine gute Lösung. Würde ich vielleicht erst einmal zurückstellen.
Oder dessen Parameter wären erst einmal nicht als Modulationsziel verfügbar, sondern nur als Modulationsquelle.

 

[DanReed]

Ich hoffe, Du sprichst nur von dem letzten Beispiel mit den Orgel-Sounds?

Ja. Was ich meine, klingt eher wie ein Overdrive-Effekt (für den manche extra ein PlugIn installieren würden).

 

[Turing]

Ich höre in der Orgel-Demo manchmal auch so etwas Röhrendes heraus.
Der Klang ist nicht insgesamt übersteuert (dann würden sich die Akkorde unsauberer anhören), sondern es ist eher so, dass einzelne Noten etwas verzerrtes an sich haben.
Es ist für mich gehörsmäßig schwer zu unterscheiden, ob das einfach ein Nebeneffekt eines übertriebenen "Geschwurbels" ist, das sich manchmal dann auch schlecht anhört (jede Note ist bei diesem Patch in sich ziemlich wild animiert, daher das Wabern), oder ob es einen Fehler darstellt.
Deshalb klappere ich die möglichen Fehlerursachen jetzt mal der Reihe nach ab.
Als erstes baue ich einen Clipping-Indikator im Plugin ein.
Zum Schutz des Gehörs vor explosiven Ereignissen in der Klangsynthese (manchmal verhaut man sich ja auch beim Programmieren, teilt durch 0 oder ähnliches, und Filter sind auch nicht immer stabil) enthält das Plugin einen Clipper. Wenn dort übergroße Samples, NaN (not a number) oder ±Infinity ankommen, schneidet der Clipper ab oder setzt auf Stille.
Bisher wird aber im Plugin nicht signalisiert, ob dieser Fall aufgetreten ist. Das realisiere ich jetzt mal als erstes.
Auch gibt es noch keinen Master-Volume-Regler im Plugin, um das Clipping - wenn es denn auftritt - durch Herunterregeln des Pegels vermeiden zu können.
Der soll jetzt auch kommen. Damit kann ich zumindest interne Verzerrungen im Plugin erkennen und in den Griff bekommen.

 

[einseinsnull]

Aus der Matrix müsste eine Art Abhängigkeitsgraph

viele hardwaresynthesizer haben solche völlig chaotischen architekturen, wo es lauter verschiedene klassen von funktionen gibt, die unterschiedliche eigenschaften haben, dann noch auf unterschiedlichen chips laufen usw.

in einer "vollständigen" mod matrix könntest du genau das vermeiden, und alles linear machen. die matrix ist dann zuerst da und der kern des ganzen.

an der stelle frage ich mich wie eigentlich die 100 modulationsquellen für deine 100 parameter aussehen?

sofern du subcircuits für alle modulationsquellen hast, die sich automatisch ein und ausschalten, könntest du ja durchaus 100 envelopes und 100 LFOs pro stimme zur verfügung stellen.

 

[Turing]

viele hardwaresynthesizer haben solche völlig chaotischen architekturen, wo es lauter verschiedene klassen von funktionen gibt, die unterschiedliche eigenschaften haben, dann noch auf unterschiedlichen chips laufen usw.
in einer "vollständigen" mod matrix könntest du genau das vermeiden, und alles linear machen. die matrix ist dann zuerst da und der kern des ganzen.

Darüber muss ich mal nachdenken. Einfach ein lineares Modell, Matrixmultiplikation, fertig. Meinetwegen noch eine sparse dargestellte Gewichtsmatrix, um die zahlreichen 0-Gewichtungen zu überspringen.
Vielleicht ist das mit dem Abhängigkeitsgraph unnötig kompliziert und ich hatte da Scheuklappen auf. Danke!

an der stelle frage ich mich wie eigentlich die 100 modulationsquellen für deine 100 parameter aussehen?

Es gibt zwar viele Parameter, aber wahrscheinlich deutlich weniger interne Modulationsquellen.
Ich denke da nur an das Übliche, ein paar EGs und ein paar LFOs pro Stimme (und evtl. eben auch global), ein paar Zufallswerte, Velocity, Pitch.
Dazu als externe Quelle die ganzen CCs.

 

[Turing]

Ich höre in der Orgel-Demo manchmal auch so etwas Röhrendes heraus.
Der Klang ist nicht insgesamt übersteuert (dann würden sich die Akkorde unsauberer anhören), sondern es ist eher so, dass einzelne Noten etwas verzerrtes an sich haben.
Es ist für mich gehörsmäßig schwer zu unterscheiden, ob das einfach ein Nebeneffekt eines übertriebenen "Geschwurbels" ist, das sich manchmal dann auch schlecht anhört (jede Note ist bei diesem Patch in sich ziemlich wild animiert, daher das Wabern), oder ob es einen Fehler darstellt.
Deshalb klappere ich die möglichen Fehlerursachen jetzt mal der Reihe nach ab.

Wie angekündigt hat das Plugin nun einen Patch-Level-Regler und einen Clipping-Indikator bekommen.
Damit konnte ich nachvollziehen, dass es in den Orgel-Beispielen nicht zu einer ungewollten Übersteuerung gekommen ist.
Tatsächlich ist ganz einfach der Sound selbst so schwurbelig-röhrend.

Damit man dies besser hören kann, hier das erste Orgel-Beispiel (monotone Interpolation) in einer Aufnahme komplett ohne Hall:
Anhang anzeigen 2023-12-30-Demo-Organ-Monotone-Dry.mp3

In der Dry-Version kann man gehörsmäßig besser nachvollziehen, wie die einzelnen Töne "wabern" und ihren spektralen Gehalt ständig ändern.
Grundwellenform ist hier eigentlich ein Sägezahn. Dessen "sägende" Anteile scheinen aber immer nur einmal periodisch kurz auf und verschwinden dann wieder.
Schwebungen und Änderungen des spektralen Gehalts (durch Intermodulation mehrere Töne) treten natürlich auch bei Verzerrung auf, so entsteht wahrscheinlich der klangliche Eindruck als "verzerrt" bei manchen der Noten in der Aufnahme.
Außerdem kann es bei der Animation der Klänge durch das Multi-Unisono-/Texturgenerierungs-Verfahren (nicht bei der eigentlichen spektralen Synthese) tatsächlich zu Intermodulations-Effekten kommen, wenn man (wie hier) eine sehr große Animationstiefe einstellt. Das dürfte zu dem stellenweise "röhrenden" Klang ebenfalls beitragen.

 

[Turing]

Da ich im Moment keine Zeit/Konzentration dafür habe, am Plugin weiter zu programmieren, habe ich einfach mal einige andere Orgel-Patches, die sich inzwischen angesammelt haben, mit den MIDI-Noten aus dem letzten Orgel-Beispiel angespielt und entsprechende Aufnahmen erstellt.
Dazu ist zu sagen, dass das Plugin natürlich kein Orgel-Spezialist wie z.B. Organteq ist und nicht dazu gemacht ist, authentische Orgel-Sounds zu erzeugen.
Trotzdem erinnert das klangliche Ergebnis bei manchen Parameter-Einstellungen doch ein wenig an eine Orgel - von einigermaßen natürlich bis stark verfremdet.
Ich habe die Aufnahmen der Patches grob sortiert nach den Kategorien: 1. Hell/Brillant klingende Orgeln, Kirchenorgel-ähnlich; 2. Weich/Sanft klingende Orgel-Sounds; 3. entfernt Orgel-ähnliche Sounds, die aber zumindest noch sinnvoll mit dem Notenbeispiel anspielbar sind; 4. Orgel-Mischformen, die auch etwas nach Harmonika klingen.
Alle Aufnahmen verwenden denselben (MPE) Input, den jeweiligen Patch, und dasselbe Hall-Preset aus 7th Heaven Professional.

1. Bright Organs

Bright, generisch:
Anhang anzeigen 01-Bright-Organ-Generic.mp3

(Eher) Bright mit sehr starker Animation und teilweise Flanging-ähnlichen Artefakten:
Anhang anzeigen 02-Bright-Organ-Flanging.mp3

Bright, schnell pulsierend:
Anhang anzeigen 03-Bright-Organ-Pulsating.mp3

 

[Turing]

2. Soft Organs

Soft, generisch:
Anhang anzeigen 04-Soft-Organ-Generic.mp3

Soft, mit deutlichen Tonhöhen-Schwankungen:
Anhang anzeigen 05-Soft-Organ-Wobbly.mp3

(Eher) Soft, schnell pulsierend:
Anhang anzeigen 06-Soft-Organ-Pulsating.mp3