Ableton 10 - Buffersize & Send-Effekte

[Turing]

Habe es noch mal nachgelesen, unter bestimmten Umständen kompensiert Ableton nicht.
Wenn man von einer Returnspur auf eine Audiospur zurück routed, dann müssen für diese Audiospur Sends ganz deaktiviert werden, wenn man eine Latenzkompensation haben möchte.
Deaktiviert man die Sends nicht, dann gibt es für diese Spur keine Latenzkompensation.
(Das ist aber eine etwas verzwicktere Situation als in Deinem Beispiel).
Ich hatte damals viel mit Aufzweigungen/Zusammenführen von Audio experimentiert und da habe ich das als Einschränkung empfunden.

 

[schnuffke2]

Das ist ein gut bekanntes Problem in Ableton - eher seltsam, dass Du das erst jetzt entdeckst. Steht auch im Handbuch beschrieben und es gibt viele Diskussionen darüber im Netz. Ob das in der 11er jetzt normal funktioniert, weiß ich aber nicht.

 

[Turing]

Für meinen Teil habe ich es vor ein paar Jahren entdeckt und aus diesem und anderen Gründen (damals keine MPE-Unterstützung) dann Ableton verworfen.
Mir ist unverständlich, warum man keine vollständige Latenzkompensation realisiert.
Sofern der Routing-Graph azyklisch ist, was er ja vernünftigerweise immer sein sollte, kann man die Latenzen an jedem Knoten leicht ausrechnen.
Das ist keine Raketenwissenschaft.

 

[einseinsnull]

für mich ergeben weder die frage noch die bisherigen lösungsansätze so besonders viel sinn.

es würde mich aber nicht wundern, wenn es mal wieder an live liegt.

 

[schnuffke2]

Für meinen Teil habe ich es vor ein paar Jahren entdeckt

Ich meinte olutian ... sorry, falls das anders rüberkam.

@einseinsnull Es geht, denke ich, einfach um fehlende oder fehlerhafte Latenzkompensation in AL, besonders die Returnspuren betreffend.

 

[einseinsnull]

Ich meinte olutian ... sorry, falls das anders rüberkam.

@einseinsnull Es geht, denke ich, einfach um fehlende oder fehlerhafte Latenzkompensation in AL, besonders die Returnspuren betreffend.

...die ihm bei 32 nicht aufgefallen ist, ich verstehe.

 

[Knastkaffee_309]

wenn ich nun bei einem die phase drehe, ist der hall hörbar. obwohl es sich komplett auslöschen müsste.

Hall ist meist moduliert, der wird sich nie 100 auslöschen. Wieso nimmst du üverhaupt noch nen Hall? Nimm nen neutrales Delay!

 

[olutian]

hmmm, ich habe jetzt mal zwei loops mit der selben buffer size (256) erzeugt, übereinander gelegt und phase gedreht.

löschen sich auch nicht aus. also ist das wie devilfish im zweiten beitrag zum moog bass schon sagte, dass der niemals gleich klingt.

analog emulation und so... bei reverbs voll peinlich. @Knastkaffee_309 & @devilfish hatten recht.

SORRY

 

[schnuffke2]

Timingprobleme und Send-Effekte klingt halt so vertraut, dass ich es auf die bekannten (und inzwischen vllt. gelösten) Probleme mit der Latenzkompensation geschoben habe.

 

[olutian]

Habe mich jetzt bei Ableton für den Vorwurf entschuldigt.

Und den Thredtitel entschärft.

 

[Turing]

hmmm, ich habe jetzt mal zwei loops mit der selben buffer size (256) erzeugt, übereinander gelegt und phase gedreht.
löschen sich auch nicht aus. [...]
analog emulation und so... bei reverbs voll peinlich. @Knastkaffee_309 & @devilfish hatten recht.

Du könntest es aber durchaus mal mit einem simplen Delay statt Reverb neu versuchen (so wie Knastkaffee das schon vorgeschlagen hatte). Dann wüsste man zur Ausgangsfrage mehr.

 

[olutian]

es gibt eine verzögerung bei hoher latenz. aber das ist kein problem. 1024 samples buffer entspricht hier einer latenz von ca. 90 ms.

so rendert man ja auch nicht. einfach eine niedrige latenz wählen und fertig.

 

[einseinsnull]

der punkt ist eher der, dass die IO vectorsize generell nichts mit prozessen zu tun haben sollte.

alle "einzelteile" innerhalb eines solchen programms, so z.b. das VST hosting der send effects, verarbeiten samplewerte mit der gleichen breite von 64 samples (bei vernünftigen programmen: 32) und das erzeugt dann genau 0 samples latenz im vergleich zum weglassen dieses einzelteils. erst plug-ins können dann wieder verzögerungen erzeugen.

 

[verstaerker]

ich hab irgendwie immer die selbe Latenz eingestellt .. 128 sampels und fertig ist

 

[schnuffke2]

Jetzt bin ich verwirrt ... gibt es bei höher eingestellter Latenz nun eine Verzögerung der Returnspuren relativ zu den originalen oder nicht?

Beim Rendern ist doch die eingestellte Buffergröße sowieso egal, wenn sie nicht unübliche Nebeneffekte hervorruft, bzw. sollte mWn egal sein.

Edit: Die Buffergröße betrifft doch nur die Kommunikation zwischen Ableton und Soundkarte - die hat beim Rendern keinen Effekt.

 

[einseinsnull]

wenn in einem programm der in/out buffer - also der, der man selbst einstellen kann - einen effekt auf die funktionsweise des mischers hat, dann wäre das nicht nur ein designfehler sondern geradezu unerklärlich.

einen unterschied zwischen livebetrieb und rendering sollte ein audioprogramm eigentlich auch nicht haben.

rendern benutzt einfach nur eine art virtuellen treiber, dessen samplingrate dynamisch ist, ansonsten macht das programm genau das gleiche wie sonst auch.

 

[olutian]

also ich bekam gerade die antwort vom ableton support. kurz gesagt, es spielen hier viele faktoren eine rolle,

so dass ich sie hier nicht kompakt beschreiben kann. hab auch links zum nachlesen bekommen, was latenzen angeht.

werde es mitm kollegen versuchen zu ordnen und gebe dann nochmal hier eine antwort.

es ist aber alles so wie es sein soll! in diesem fall hier ist es ein anwendugnsfehler von mir.

neben der globalen latenz gibt es z.b. noch Driver Error Compensation und Reduced Latency when Monitoring (und das ist noch nicht alles)

 

[einseinsnull]

es ist aber alles so wie es sein soll! in diesem fall hier ist es ein anwendugnsfehler von mir.

das ist das ergebnis, was man sich immer wünschen sollte, denn daran kann man leichter etwas ändern als an einem fehlerhaften programm.