das wird mit sehr hoher sicherheit folgendes sein:
- beim einspielen kann eine daw die latenzen gar nicht ausgleichen. wenn du also durch drei plugins spielst, das eine hat ne latenz von 4ms, das nächste von 12, das nächste von 23, dann wird das schön breit
- beim abspielen werden sie dann ausgeglichen
- insbesondere weil "selbes signal durch 3 amps" eigentlich eine vorprogrammierte phasensauerei ist, fällt jetzt die schöne "räumlichkeit" (die in wahrheit nichts weiter als ein übergeordneter slapback delay ist) in sich zusammen und wird "eng". wenn jetzt noch das problem dazu kommt, dass vielleicht eines der plugins seine latenz falsch an cubase reportet (da sind viele leider schlampig, sowas muss samplegenau sein), wirds obendrein noch phasiger als es sowieso schon durch das setup "ein signal durch 3 gepannte ampsimulationen" gerne ist
- daws die "dieses problem nicht haben", haben einfach keinen sauber funktionierenden latenzausgleich. das würde zum verstaubten samplitude gut passen, und würde auch erklären warum das aktueller gepflegte S1 "das problem auch hat".
- die lösung ist natürlich einfach, manuell eine verzögerung einzustellen. durch den latenz-readout kannst du dir sogar die werte abschauen
- noch besser: wenns breit sein soll, gitarre richtig doubletracken. viel besser als son plumper delay-offset, und gibt keine kammfilter-effekte wenn mans mono abhört
woran es definitiv *nicht* liegt, ist das "cubase ein problem damit hat, spuren so wiederzugeben wie aufgenommen". selbstverständlich ist in jeder daw seit über 2 jahrzehnten das aufgenommene signal mit dem input des wandlers bit-identisch. und wenn man da viele im internet findet, die "auch schon das problem hatten", dann gabs halt viele leute die die materie nur so mittel verstehen. eine daw, die aktiv klangunterschiede zwischen live und aufnahme verursachen würde, würde im heutigen foren-netz sofort von tausenden usern in die luft gesprengt
und das gilt übrigens natürlich erst recht für die export-funktion. das ist auch ein thema, "das immer wieder auftaucht", und seit über 20 jahren enden diese stories immer damit, dass man einen nulltest macht, der entweder sich komplett auslöscht, oder man stellt ein routing oder leveling problem beim user fest (der control room ist hier als fehlerquelle besonders beliebt), oder der nulltest "scheitert" weil effekte mit ungesyncten LFOs wie chorus oder randomisierung wie reverb mit im paket waren, und der user begreift nicht, dass das deswegen dann noch lange kein nulltest ist, der "nicht funktioniert hat".