Warum Kompressoren immer als Insert-, aber nicht als Send-Plugins?

[Mick Rütter]

Moin,

Holger Steinbrink sagt in einem seiner Lehrvideos über Kompression, Kompressoren gehörten immer in den Insert-Kanal. Er begründet das aber leider nicht.

Kann mir hier jemand erklären, warum ich Kompressoren nicht auch als Send-Effekt (sondern gemäß Holger Steinbrink nur als Insert-Plugin) benutzen kann bzw. sollte? Warum lege ich nicht einen Effekt-Kanal an, in welchem der Kompressor einer meiner Send-Plugins ist, so, wie es z. B. auch mit Hall oder Delay geht?

Gruß
Mick

 

[Novik]

Die Aussage, dass Kompressoren nur im Insert benutzt werden stimmt so nicht

Denk mal an Parallel-Kompression. Da wird genau das gemacht, was du beschrieben hast.

Man benutzt ihn dann als Insert, wenn man die Spur komplett komprimieren will. Bei der Parallel-Kompression wird über einen Send Weg die Spur gedoppelt und durch den Effektkanal mit dem Kompressor gejagt. Die Ursprungsspur wird also nicht angerührt.

 

[Deltafox]

die klassische Anwendung des Kompressors ist ja, die Dynamik des eingehenden Signals zu reduzieren. Dazu wird der Kompressor klassisch so eingesetzt, dass vom eigentlichen Signal nichts mehr am Ausgang ankommt, also nurnoch das komprimierte Signal zu hören ist --> deshalb als Insert

Inzwischen wird aber tatsächlich auch oft die parallele Kompression eingesetzt, bei der der Kompressor auf einem Send liegt
Hier wird im Kompressor der Sound stark komprimiert, so dass die Dynamik stark eingeschränkt wird, gleichzeitig bleibt aber das Originalsignal mit viel Dynamik zu hören, so dass insgesamt durch die Mischung aus beiden Signalen ein immernoch lebendiges, aber gleichzeitig "fettes" Signal aus den Boxen kommt --> in dem Fall als Send

Es hängt aber stark vom Anwendungsfall ab. Wenn du den Kompressor z.B. nur nutzen willst, um generelle Lautstärkeunterschiede in einer Spur einzudämmen (um dir also bspw. Automation zwischen Vers und Refrain zu ersparen oder so) dann solltest du den Kompressor als Insert einsetzen - wenn du ihn als Effekt einsetzt, bspw. für Drums oder generelle perkussive Instrumente (auch A-Gitarre mit starkem Anschlagsgeräusch) kannst du ihn auch als Send verwenden. Ist aber eine eher jüngere Erscheinung, deshalb wird oft noch der Einsatz als reiner Insert empfohlen.

 

[Preci55ion]

Mittlerweile haben gute Kompressoren auch einen WET/DRY Regler, was in meinen Augen die New York Compression ersetzt. Solche Kompressoren kann man immer als Insert verwenden.

 

[Telefunky]

... Inzwischen wird aber tatsächlich auch oft die parallele Kompression eingesetzt, bei der der Kompressor auf einem Send liegt
Hier wird im Kompressor der Sound stark komprimiert, so dass die Dynamik stark eingeschränkt wird, gleichzeitig bleibt aber das Originalsignal mit viel Dynamik zu hören, so dass insgesamt durch die Mischung aus beiden Signalen ein immernoch lebendiges, aber gleichzeitig "fettes" Signal aus den Boxen kommt ...

nun... 'inzwischen' ?
bekannt geworden ist die Methode vermutlich durch Motown Produktionen der 60er Jahre
die Vocals wurden oft in einem parallelen Weg hochpass-gefiltert, richtig stark komprimiert und dieser 'Höhen-Akzent' der Originalspur zugemischt.
erlaubt ist natürlich was gefällt, aber Sinn macht die parallele (Dynamik) Verarbeitung vor allem dann, wenn irgendetwas 'anderes' mit dem abgezweigten Signal passiert (wie in dem Beispiel).

In der DAW dürfte sich eher ein Effekt durch unterschiedliche Laufzeiten ergeben (wenn das Signal sonst nicht verändert wurde)

cheers, Tom

 

[Mick Rütter]

Nun ja, ein schlagendes Argument für "parallele" Kompression, also via "Effect-Send" dürfte doch, so wie es auch bei anderen Send-Plugins der Fall ist, das Sparen von Rechnerleistung sein. Und wenn man den Effekt so einsetzen kann, daß die Ergebnisse, wenn man es denn so will, genauso klingen wie bei einem via Insert-Slot eingesetzten Compressor, dann hätte das Send-Compressing (im Vergleich zum Einsatz im Insert-Kanal) imho alle Argumente auf seiner Seite. Oder sehe ich das falsch?

Ach ja, noch ein weiterer Punkt in diesem Zusammenhang: wie ist es bei Sidechain-Compression? Funktioniert die auch als Send-Effect (aus dem SendFX-Bus)?

Schon mal vielen Dank für die Antworten.

 

[Deltafox]

kann man aber nicht, es wird unterschiedlich klingen. Außerdem wird auch bei der parallelen Kompression nur ein Kanal (oder eine Subgruppe, z.B. Drums oder nur Bassdrum+Snare) auf den Send geschickt

du kannst also nicht Kompressoren sparen, indem du einen Send erstellst und da alles drauf schickst, was du komprimieren möchtest, das wird grundlegend anders klingen, als wenn du einen Insertkompressor auf jeder Spur hast.

 

[Mick Rütter]

kann man aber nicht, es wird unterschiedlich klingen.

Meinst Du jetzt die "konventionelle" oder die Sidechain-Compression? (Ich hatte ja in einem zweiten Teil meines letzten Artikels nach Sidechain gefragt.)

 

[Navar]

Naja, Sidechain Kompression ist meiner Ansicht nach eigentlich eine andere Baustelle, weil es darum geht die Kompression über ein fremdes Signal zu steuern, dabei ist es dem Sidechain - Signal erstmal egal wo der Kompressor liegt. Mir fällt jetzt auch kein Anwendungsfall ein, bei dem ich auf die Idee kommen würde mehrere Spuren (zum Beispiel auf einer Gruppe zusammengefasst) mit dem gleichen Kompressor, gesteuert von einem Sidechain Signal, zu komprimieren. Schon gar nicht aus dem Grund, um Prozessorleistung zu sparen. Dafür finde ich auch Attack/Release je nach Material zu individuell. Und bei einer Buskompression möchte ich in der Regel ja eben genau das Gesamtsignal komprimieren.

Parallelkompression ist, wie schon angesprochen wurde, ja eine gängige Technik, wobei man da auch durch den Eingangspegel in den Send auch noch das Regelverhalten des Kompressors beeinflussen kann. Wobei ich persönlich da lieber Pre-Fader Signale benutze und den Eingangspegel dann vor dem parallelen Kompressor nochmal nachregel. Liegt aber auch daran, dass ich da noch nicht so tief in der Materie drin bin und ein Post-Fader-Parallel-Kompressor meiner Meinung nach schwieriger zu kontrollieren ist und öfters nachgeregelt werden muss.

 

[Deltafox]

sowohl die konventionelle als auch Sidechain-Kompression wird über Send anders klingen.

Also nochmal kurz zusammengefasst:
Die parallele Kompression ist zwar möglich, aber eben klanglich unterschiedlich zur "herkömmlichen" bzw. klassischen Insert-Kompression.
Dabei wird der Kompressor aber nicht als herkömmlicher Send-Effekt eingesetzt wie bspw. ein Hall, sondern dennoch nur mit einzelnen Spuren/Subgruppen beschickt, also im Prinzip so als wäre es ein Insert, dem man noch das unbearbeitete Signal zumischt (was, wie oben geschrieben, manche Kompressoren mittlerweile auch direkt mittels Dry/Wet-Regler anbieten - diese werden dann wieder als reiner Insert genutzt)

Wenn du alle möglichen Spuren auf einen Send-Kompressor schickst, wird es sehr schwer werden, diesen einzustellen, da die Spuren ja sehr unterschiedliche Signale liefern und der Kompressor immer nur auf den Eingangspegel achtet - wenn also 5 Spuren gleichzeitig reingehen (deren Pegel sich addiert), komprimiert das Ding total stark, während wenn dann an einer Stelle des Songs nur noch eine Spur reinkommt, wird das komplette Regelverhältnis verändert, u.U. greift er dann gar nicht mehr.

Es ist also etwas völlig anderes, als wenn man den Kompressor als Insert-Effekt nutzt.

 

[Dummer Sack]

ein trick der sog. "new york compression": man kann da noch so manch anderes anstellen. so etwa irgendwelche verzerrer zusätlich einschleifen, was in einem seriellen routing oftmals zuviel des guten wäre.
ich hab das kürzlich mal versucht (anm.: ich bin ein lausiger mixer, probiere aber dennoch vieles einfach mal aus), da habe ich mir einfach einen "dreckbus" erzeugt. darauf lagen dann ein compressor, ein zerrer und ein eq. der sound des busses per se war eher dünnlich, stark komprimierend, mehr oder minder digital zerrend usw. also definitiv nix für einen seriellen insert. aber dezent einigen signalen zugemischt (eben per send), war das schon ganz geil. für mich eher sowas wie "lass' mal versuchen, den braven digitalen charakter zu verscheuchen". da kann man dann auch jedes signal hinsenden, welches etwas mehr dreck braucht.
ist mixtechnisch vermutlich nicht wirklich ganz ohne stress zu handhaben, aber ich fand's zumindest sehr interessant.

- der sack

 

[cadusadimpressum]

Angenommen du schickst das Signal Pre-Fader auf den Kompressor und mutest dann deine Spur per Fader, dann würde sich dieses Konstrukt verhalten wie ein Insert. Es wär nur viel umständlicher und daher sinnlos. Angenommen du spielst mit beiden Fadern rum, dann hast du einen Wet-Dry Regler für den Kompressor...ob das sinnvoll ist, ist wohl von deinem Kompressor abhängig. Mehrere Spuren auf einen Kompressor zu schalten führt in den meißten Fällen wohl zu keinem so berauschenden Ergebnis, deswegen kann man das auch sein lassen.

Es gibt natürlich keine Verbote in der Musik, alles kann als kreative Möglichkeit verstanden werden, deine DAW gibt dir nicht umsonst die Möglichkeit dazu. Allerdings haben sich bestimmte Regeln durchgesetzt, weil sie eben oft auch Sinn ergeben. Ich zumindest stell meinen Kompressor immer so niedrig ein, daß ich dem Track keine unkomprimierte Spur beimischen muß, um die Dynamik zu erhalten und daher läuft der Kompressor bei mir immer als Insert.

 

[Telefunky]

den meisten Anwendern, die auf das Stichwort 'Parallelkompression' anspringen, geht es gar nicht um Dynamik.
Sie suchen nach irgendwas, das den Track 'fetter' macht (was immer man darunter versteht...)
ich nehme mal an, dass das häufig sogar gelingt - aber nicht wegen der Dynamik-Bearbeitung
die Wege dürften in vielen Fällen nicht phasensynchron laufen und das kann schon mal dick auftragen...

cheers, Tom

 

[Dummer Sack]

die Wege dürften in vielen Fällen nicht phasensynchron laufen und das kann schon mal dick auftragen...

Na ja. Das mag bis vor einiger Zeit so gewesen sein. Aber bei einem "in the box" Mix (sprich: komplett im Rechner, also so, wie derzeit durchaus nicht unüblich...) sollte das so ganz nicht mehr stimmen. Da bleibt eigentlich alles immer phasensynchron, da etwaige Latenzen von Plugins kompensiert werden.

- Der Sack

 

[Gast 3541]

Das ist auch immer noch so
Auch wenn die delaykompensation schon sehr clever gelöst ist hab ich bei ganz bestimmten plugins immer ne minimale aber dramatische Verschiebung.
Dafür gibts denn ja wiederum Latency delays

Gruß

 

[Telefunky]

solange ein isoliertes Signal mal 3-8 Samples 'rutscht' fällt das meist gar nicht bis kaum auf.
Bei einer parallelen Signalführung ist es aber alles andere als vernachlässigbar.

Im Detail lässt sich das in der 'engine' einer DAW kaum kontrollieren. Und in der CPU erst recht nicht...
Ich kann aber mit absoluter Sicherheit sagen, dass alles, was ich auf DSP Hardware mache, transparenter und präziser klingt als wenn eine native DAW den Job übernimmt.

Letztens hatte ich sogar mal den Eindruck, das dasselbe Plugin im schlichten 'VST-Host' anders reagierte, als in der Spur der DAW.
Den 'Host' nehme ich öfter zum live-daddeln, da fand ich den Valhalla Room auf einmal erstaunlich 'muddy'.
(ich hab mich sogar gefragt, warum ich das eigentlich gekauft habe...)
Etwas später wirkte das Plugin in einer Sequencer Spur merkwürdigerweise viel klarer.
Kann natürlich an der Tagesform gelegen haben, aber so selten habe ich diese 'was'n hier los ???' Erlebnisse nicht.

auf der DSP Hardware lässt sich das problemlos an jeder Stelle des Signalwegs kontrollieren
... und selbst diese (gegenüber einer CPU viel überschaubarere Architektur) hat da mal 1-3 Samples 'Fehler'.
da möchte ich gar nicht wissen, was innerhalb eines Cubase Kanalzugs so alles passieren kann...

cheers, Tom

 

[Gast 3541]

In Cubase passiert genauso viel oder wenig wie in Nuendo, dort hast du (nur) Probleme mit irgendwelchen Hardcore Emulationen (am besten noch Filter) in parallekette.
Bei TDM &Co hab ich meist das Gefühl, dass alles zwar Zeitnah zusammenhängt - trotzdem ensteht auf dublizierten Spuren manchmal dieser OOP-Brei.
Das man jetzt in irgend einem System verstärkt bei jedem plugin drauf achten muss ist IMHO nicht der Fall, mal passiert es halt, dann korrigiert man die nötigen Spuren und fertig. Das ist ne Sache von einer Sekunde Nur dass man keine Latenzprobleme wegen Kompensation mehr hat - das stimmt nicht.

 

[Dummer Sack]

Das ist auch immer noch so
Auch wenn die delaykompensation schon sehr clever gelöst ist hab ich bei ganz bestimmten plugins immer ne minimale aber dramatische Verschiebung.

Wenn der Host funktioniert, dann gibt es die beim Abspielen nicht.

Dafür gibts denn ja wiederum Latency delays

Was soll das sein?

Im Detail lässt sich das in der 'engine' einer DAW kaum kontrollieren. Und in der CPU erst recht nicht...

Wieso sollte sich das in der "Engine" einer DAW nicht kontrollieren lassen? Genau das ist das Prinzip des Latenzausgleichs. Wenn ein Plugin korrekt programmiert ist, meldet es dem Host, wieviel Latenz es erzeugt. Und diese wird dann beim Abspielen kompensiert. Das klappt auch ganz ausgezeichnet, wie etliche "Nulltests" beweisen.
Die CPU hat damit an sich gar nichts zu tun, die kann bestenfalls mal aussteigen, wenn es zu schnell geht (sprich, zu viel zu berechnen ist). Aber bis zu diesem Zeitpunkt ist sie, einen nicht fehlerhaft programmierten Host vorausgesetzt, so genau wie eine Atomuhr. 1+1 ist da eben 2 und nicht 2,00000000000004.

Ich kann aber mit absoluter Sicherheit sagen, dass alles, was ich auf DSP Hardware mache, transparenter und präziser klingt als wenn eine native DAW den Job übernimmt.

Das ist kein wirklich gültiger Vergleich, da du nicht dieselben Plugins und dgl. benutzt.

Letztens hatte ich sogar mal den Eindruck, das dasselbe Plugin im schlichten 'VST-Host' anders reagierte, als in der Spur der DAW.

Da gibt es zwei Möglichkeiten: Entweder ist etwas falsch programmiert oder dein Höreindruck unterlag anderen Faktoren.

Das man jetzt in irgend einem System verstärkt bei jedem plugin drauf achten muss ist IMHO nicht der Fall, mal passiert es halt, dann korrigiert man die nötigen Spuren und fertig. Das ist ne Sache von einer Sekunde Nur dass man keine Latenzprobleme wegen Kompensation mehr hat - das stimmt nicht.

Wenn alles sauber programmiert ist, hat man beim Abspielen keinerlei Latenzprobleme. Wie gesagt, etliche Nulltests beweisen das sehr eindeutig.
Ich kann mich an Logic 5.x erinnern (vor der letzten PC Version, in der es dann behoben wurde), da gab's immer am Anfang irgendwelcher gebouncten Files Probleme mit Levels und Timing. Nun gut, das war eben eine kaputte Version (und ja, das gibt es in der Tat häufiger als man annehmen möchte).

Ein Rechner ist perfekt. Wenn er es nicht ist, dann ist irgendwas kaputt oder jemand hat nicht sauber programmiert. Andere Möglichkeiten gibt es da an sich nicht.

- Der Sack

 

[gincool]

zum thema exaktheit bei der berechnung muss ich da widersprechen

stichwort maschinengenauigkeit: gleitkommaarithmetik ist ein thema für sich als beispiel sei die addition verschiedengroßer zahlen genannt. bei einer mantissenlänge von 4 führt eine addition von zahlen die mehr als 10^4 auseinander sind immer zum ergebnis des größeren summanden. bei 32bit gleitkommaberechnungen heutiger daws fällt das aber nicht wirklich ins gewicht. zumal das ganze mit sampleversatz herzlich wenig zu tun hat


prinzipiell trifft das aber genauso auf dsps als auch native daws zu von daher ..

und ich stimme zu: wenn es zu sampleversatz kommt hat jmd scheisse beim programmieren gebaut .. egal ob auf nem dsp oder nativ ..

 

[Telefunky]

ich sehe das eher von der praktisch Seite - der konkreten Mathematik könnte ich eh nicht folgen
(aber imho verstehe ich was vom Kontext, in dem sie eingesetzt wird...)

Es gibt den Satz: a mixdown is an entirely serial process
(gefallen im Zusammenhang mit Optimierungsmöglichkeiten per Multicore etc bla bla...
spielt hier keine Rolle, aber der Urheber hat eine der ersten DAWs geschrieben - und dürfte damit wohl als qualifiziert gelten. 16 Spuren auf einem Pentium-133 gleichzeitig aufzunehmen ist auch nicht so ohne...)

im Prinzip macht man auf der DAW heute realtime Audio, aber das Ganze läuft wohl kaum (komplett) seriell ab
der Programmierer hat nicht wirklich Einfluss auf die Feinheiten des Compilers oder die Mechanismen, die zwecks 'Leistungsoptimierung' innerhalb der CPU zum Einsatz kommen.

ergo muss da eine Monitor-Differenz einkalkuliert werden
das wäre für mich zumindest ein plausibler Ansatz, das Gehörte nachzuvollziehen.
Der Unterschied ist zwar nicht unbedingt Tag und Nacht, aber er ist vorhanden.
Würden sich beide Hälften des Systems identisch verhalten, wäre mir das lieber - und der Signalweg egal.

Im allgemeinen ist es eine unbedeutende Abweichung, bei vielen 'zeitgeistigen' Sachen sogar völlig Banane.
(damit ist nicht nur top-40 gemeint, auch Dubstep oder Metal sind da eher unempfindlich)
Aber in kritischen Fällen kann es schon mal ein signifikanter Unterschied sein.
Die angesprochene Parallelverarbeitung auf Plugin-Ebene neigt da von Natur aus eher zur Auffälligkeit.
Von der Wertung her würde ich es wie die Gleichlaufschwankungen beim Band einstufen.
War doch auch kein Beinbruch...
aber: ein Rechner ist perfekt... und 'saubere' Programmierung... welches Jahrhundert, bitte ?

cheers, Tom