Algorithmus für einen digitalen Kompressor

[Rubbl]

Ich hab das als Verzögerung der Attack verstanden

Danke!
...aber könnte ich da nicht einfach den Attack hochdrehen.

 

[Telefunky]

Das stimmt schon, allerdings bin ich von der Behandlung der Einzelwerte wie von Laguna gepostet nicht überzeugt.

deswegen hatte ich die auch als 'workaround' tituliert
du gibst ja mit dem 'Rauschen' gutes Beispiel für eine strategische Lösung

cheers, Tom

 

[Banjo]

...aber könnte ich da nicht einfach den Attack hochdrehen.

Dann würde die Attack ja trotzdem in die Transiente reinregeln, wenn auch nicht so stark. Wenn man die Attack wirklich komplett verzögert, bleibt die Transiente 100% ungeschoren und danach kann man trotzdem mit einer kurzen Attack eingreifen.

Banjo

 

[strogon14]

Mich würde am Ende einfach mal der Code interessieren.

Kleiner Tipp am Rande. Viele Linux-Audioplugins sind Open Source und deren Source Code kann daher auf Github und ähnlichen Plattformen eingesehen werden. Diese sind zwar meist im LADSPA oder LV2-Format statt VST, aber die eigentlichen DSP-Routinen sind ja meist unabhängig vom Plugin-Format.

Hier sind z.B. die Kompressoren aus dem Calf-Pluginpaket:

https://github.com/calf-studio-gear/calf/blob/master/src/modules_comp.cpp

 

[Banjo]

Auf die Gefahr hin, dass sich einige bei diesen technischen Ausführungen langweilen

Jetzt hab ich das ausprobiert in Sachen Denormalized Float. ich lasse den folgenden Code auf einem Kanal laufen, ein simples Tiefpassfilter erster Ordnung:

#define LAGUNA  // activate denormalization fix
#define FACTOR  0.1f
#define DENORM    1e-12f

float ProcessLowpass(float in)
{
    static float old = 0.0f; // Für das Beispiel static, eigentlich eine Membervariable,
                             // wenns mehr als ein Kanal sein soll

    old *= (1.0f - FACTOR); // hier kann es passieren, dass der Wert zu klein wird
#ifdef LAGUNA
    old += DENORM;
    old -= DENORM;
#endif
    float out = FACTOR * in + old;
    old = out;
    return out;
}

Ohne das #define LAGUNA springt die VST-Leistungsanzeige meines Hosts (Audiomulch) schlagartig von ca. 3% (wohl der Overhead des Hosts selber, das Filter verbraucht sicher keine 3%) auf über 20%, sobald nur noch Nullen ins Plugin gefüttert werden und vorher schon mal Signal drauf war. Mit dem define bleibt alles cool.

Fazit: Deine Methode funktioniert einwandfrei. Men lernt nie aus...

Grüße
Banjo

 

[Novik]

Dann würde die Attack ja trotzdem in die Transiente reinregeln, wenn auch nicht so stark. Wenn man die Attack wirklich komplett verzögert, bleibt die Transiente 100% ungeschoren und danach kann man trotzdem mit einer kurzen Attack eingreifen.

Banjo

Witzigerweise hatte ich vor etlichen Monaten mal einen Test mit verschiedenen Kompressoren gemacht. Hier zeigte sich, das jeder Hersteller sehr unterschiedliche Ansätze für den Attack Parameter verfolgte.
Mal wurde durch den Attack nur der Slope bis Erreichen des eingestellten Kompressionsverhältnis verändert (verlängert oder verkürzt)
Ein anderer Kompressor hat beim Attackparameter einfach nur den Zeitpunkt verschoben, wärend der slope des Einschwingverhaltens unverändert blieb. Und manche Kompressoren hatten eine Mischform aus Beidem.


Es scheint also keine definierte Heransgehensweise zu geben, was der Hauptgrund für die Unterschiede im Klang von Kompressoren sein dürfte.
Das Lagunas Kompressor sozusagen beides getrennt regeln kann, macht ihn dadurch sehr flexibel.

 

[Laguna]

Wow, da schaut man mal einen halben Tag nicht rein und schon ist hier gleich volles Haus. Freut mich ungemein!

Mal grade noch ne Idee:
...
Vielleicht ist das ja was für die Version 2.1 ;-)

Prinzipiell finde ich die Idee witzig, hab aber noch keine Ahnung, wie ich das umsetzen könnte.
Zwar gibt es die Möglichkeit, direkt OpenGL Calls zum Zeichnen zu verwenden, direkt habe ich mit OpenGL aber noch nie verwendet. Das wäre für mich Neuland, auf dem ich mich erstmal zurecht finden muss.

Prinzipiell zeigen die meisten Kompressoren, so auch der von dir gezeigte Ausschnitt des Pro-C die statische Kompressionscharakteristik. (statisch hier im zeitlichen Sinne) Das ist auch in Ordnung, da das einen erheblichen Teil der relevanten Infos zeigt. Attack und Release sind (zeitlich) dynamische Parameter, die mit der Kurve ja erstmal garnichts zu tun haben. Ein Problem das ich hier sehe ist, dass sehr kurze Attackzeiten (die ja auch im Bereiche um 1ms liegen können) in der von dir dargestellten Variante nicht hinreichend berücksichtigt werden können. Gängie Monitore zeichnet mit 60Hz, weswegen eine Zeitkonstante von 1ms (entsprecht 1000Hz) einfach nur als "Sprung" von Wert A auf Wer B gezeichnet würde.

Cool aussehen würde es aber allemal.

Interessanterweise zeigt dir der Pro-C Attack und Release aber schon an, nämlich in der Lautstärke Darstellung. Das ist ein sehr praktisches Feature, weil du hier eben genau siehst, wie schnell oder langsam der Kompressor zupackt oder loslässt.

Hallo Laguna,

welchen Warning-Level verwendest Du denn? Ich arbeite bei Visual Studio prinzipiell mit Warning Level 4 und mit Warning=Error.

eine der Geschichten, für die man C früher schätzte
das 'gemeingefährlich' würde ich eher auf Entwickler beziehen, die so etwas nicht im Griff haben
nicht dass ich das jetzt Laguna anlasten würde...

Da hast du schon recht mit gemeingefährlich. So kleine Schusseligkeiten sind in C++ tatsächlich tödlich. Wenn ich für die Uni programmiere, wandert als erstes ein -Wall und -Wextra ins Makefile. Mein Fehler, dass ich dem von IPlug erstellten Projekt getraut habe

ich bin definitiv kein DSP Codierer, aber bei Dynamikfunktionen wüsste ich nichts, was auch nur ansatzweise Fliesskommazahlen erfordert
ergo codiert man so etwas besser nicht... nur weil's vermeintlich bequem wirkt
cheers, Tom

Wenn ich mal Zeit habe, bastel ich mal einen EQ, der mit arbitrary precision Datentypen rechnet. Dann kann sich auch niemand mehr wegen "digitaler Kälte" beschweren.

Mich würde am Ende einfach mal der Code interessieren. Also wie das alles aufgebaut ist, hinter welchem Knopf und Regler welche Funktionen stehen und so. Könnte man auch bei Lust und Laune als Workshop aufziehen.
Wieviel Zeit investierst du da täglich, @Laguna ?

Täglich ist das schwer zu sagen. Über die Feiertage hatte ich Zeit und Lust, also hab ich mich mal rangesetzt. Stunden gezählt habe ich nicht, da mir das ja Spass macht. Viel Zeit ist natürlich auch für GUI draufgegangen.
Wenn größeres Interesse besteht, kann ich da gerne was aufziehen. Das würde ich aber, aufgrund der Komplexität erstmal im Backstage-Test-Pool auf eine kleine Gruppe Leute loslassen.
Da ich nach wie vor plane, das Plugin zu verkaufen, kann ich den Sourcecode nicht veröffentlichen.
Wenn du konkrete Fragen hast, werde ich mich natürlich bemühen, die weitestgehend zu beantworten.

Ansonsten gibt es die schon angesprochenen open source Plugins, sowie auf der in meinem letzten Post verlinkten Website, auf der es Matlab und c Sourcecodes gibt.

Ich hab das als Verzögerung der Attack verstanden.
Aber genau wissen tut das nur Laguna
Banjo

Genau. Meine Implementierung von Pre-Attack ignoriert alle Werte über dem Threshold, solange sie nicht mindestens Pre-Attack +1 Samples lang über dem Threshold liegen.

Den Attack nach oben zu drehen ist ein anderer Effekt. Wenn das noch nicht verstanden ist, frag einfach nochmal kurz nach.

Auf die Gefahr hin, dass sich einige bei diesen technischen Ausführungen langweilen

Keineswegs. Immer her mit so Versuchen! Nur so lernt man dazu!

--- Beiträge wurden zusammengefasst ---

Es scheint also keine definierte Heransgehensweise zu geben, was der Hauptgrund für die Unterschiede im Klang von Kompressoren sein dürfte.

Wenn es nur Attack und Release wären....
Es gibt dann ja noch die unterschiedlichste Implementierungen was den Aufbau des Kompressors angeht. es gibt bei vielen noch einen Hold-Regler, Feed Forward oder Feed Back Kompressoren unterscheiden sich auch grundsätzlich, oft gibt es nachgebildete Eingsangs- und Ausgangs-Trafos die den sound nochmal verändern, Soft- und Hard-Knee, ... Die Liste ist sehr lang.

So Far...
Laguna (sorry für Doppelpost)

 

[Banjo]

Mich würde ja interessieren, ob mit meinem Beispielcode von oben unter IPlug auch der Leistungsabfall bei Null-Input, wenn vorher schon mal Signal da war, auftritt oder ob IPlug da tatsächlich Nullen am Eingang vermeidet, wie Du mal geschrieben hast. Wobei das auch nur bedingt hilft. Wenn Du z.B. im Plugin einen Inputgain-Regler hast, den du ganz abdrehen kannst, hilft es auch nix, wenn IPlug keine Nullen sendet, nach einem abgedrehten Inputregler sind es auf jeden Fall Nullen

Kannst Du das testhalber mal einbauen auf dem ersten Kanal und probieren?

Banjo

 

[strogon14]

Der Host kann Denormals nur bedingt verhindern. Bei internem Feedback, wie bei deinem Testcode kann er auch nicht viel machen. Man kann Denormals auch durch entsprechende Kompiler-Optionen (-ffast-math -msse -mfpmath=sse) verhindern, zumindest bei modernen Prozessoren. Hier ist hat jemand entsprechende Tests dazu gemacht. Das ist zwar schon älter, zeigt aber, dass auf heutigen Prozessoren das Problem gut umgangen werden kann:

http://carlh.net/plugins/denormals.php

 

[Banjo]

Ich hab auch inzwischen festgestellt, dass meine Plugins keine Exception auslösen, wenn Denormalizeds auftreten, der Performanceverlust kommt einfach daher, dass der Code immer weiter mit den denormalisierten Zahlen rechnet, dass kann die FPU, aber es ist ar...lahm. Deshalb hilft auch der Code von Laguna, der den Wert auf 0 runterbringt, damit geht das Rechnen dann wieder fix.

Banjo

 

[strogon14]

Performanceverlust kommt einfach daher, dass der Code immer weiter mit den denormalisierten Zahlen rechnet, dass kann die FPU, aber es ist ar...lahm

Genau das ist das Problem mit Denormals.

Deine Erklärung mit den Exceptions ist m.E. nicht korrekt. Was du vielleicht meintest, ist, dass die CPU, um die kleinen Floatwerte zu verarbeiten, in einen andern Modus switchen muss. Dies verursacht die hohe Last.

 

[Banjo]

Yep, das hab ich inzwischen auch gemerkt und wollte ich mit meinem Vorpost zum Ausdruck bringen

Es gibt unter Windows zwar eine Floating Point Underflow und eine Floating Point Denormal Operand exception, aber ich hab's noch nicht geschafft so eine auszulösen, obwohl ich in Visual Studio Floating Point-Eceptions als Compileroption enabled habe.

Es liegt einfach an der miesen Performance der FPU, wenn die Zahlen nicht normalisiert sind. Mit SSE sieht es wohl wieder anders aus.

Banjo

 

[Laguna]

Der Test hat (mit meinem denormalized code) keinen Anstieg in der Performance bewirkt.

@strogon14 : Danke für den Link, sehr interessant!

So Far...
Laguna

 

[Laguna]

Ich habe hier noch eine sehr gute Präsentation zu dem Thema gefunden. Da ich im Grunde auch nicht mehr/besser erzählen kann, wie Kompressoren funktionieren, werde ich wohl dazu keine Zusammenfassung schreiben.

So Far...
Laguna

 

[Laguna]

Das Kind hat jetzt auch einen Namen. Gemäß einem möglichen Einsatzzweck heisst es jetzt "Punchliner"

Ebenfalls sind nochmals Änderungen an der GUI hinzu gekommen. Das Grau-in-Grau, dass das Windows-95 Design abgelöst hatte, hat mich zunehmend gelangweilt. Dafür ist jetzt ein kräftiges Orange hinzugekommen.

Währenddessen habe ich noch einige Probleme behoben. Beispielsweise ist die Verzerrung jetzt (noch) intelligenter geworden und passt sich vom Frequenzbereich her dem gewählten Grad der Verzerrung an, sodass die Sättigung subtiler wirkt.

So Far...
Laguna

 

[Deltafox]

schön schön, ich glaube du könntest es moderner bekommen, wenn nicht diese extrem verrundeten & schattierten Kanten da wären, die wirken irgendwie automatisch outdated

 

[.s]

Machs einfach flach mit Pastelltönen. Keine 2000er Style rundgelutschten Boxen sondern klare Kästen, also einfach nur Rahmen. Gute Kontraste und wenig Klimbim überzeugen mich zumindest immer. Prinzipiell kann man immer gut bei Apple schauen, was die so machen. Hier mal nur als Beispiele. Schlicht und absolut gut.

 

[Deltafox]

jap, mein Eindruck ist auch, dass "dünne Linien, dezente Farbgebung und, wo nicht dringend erforderlich, auch nur geringer Kontrast" gerade modern ist

 

[Laguna]

Danke @.s und @Detafox für das Feedback.

Die GUI ist wie gesagt auch mein großes Sorgenkind. Zumal ich graphisch nicht wirklich begabt bin. Ich murks mich halt durch.

Den EQ finde ich gut, so lässt sich mein PunchLiner aber leider nicht umsetzen, da ich einfach ein paar Controls brauche. Den Flanger finde ich schlicht aber auch ziemlich langweilig. Der Comp gefällt mir gut.

Na mal schauen, wie sich das noch weiterentwickelt. Irgendwann muss ich mal ne photostrecke der GUI machen, die hat jetzt ja schon einige Iterationen hinter sich (wobei hier nur ca jede zweite zu sehen war)

So Far...
Laguna

 

[.s]

Geringer Kontrast ist halt relativ. Er muss da sein, wo er wichtig ist und nicht überall. Wenn ich mir Apples Design-Unfälle bei Softwareinstrumenten von älteren Logics ansehe, wird mir ganz schlecht. Nur mal so als OT / Negativ-Beispiel.




edit: Hier gibts doch sicherlich ein paar User, die dich da unterstützen würden.