
siebenachtel
||||||||||
ebenja, ich weiß, bei single core prozessen ist die speicherbandbreite natürlich entsprehend kleiner.
das weiss ich nicht.aber doch immer noch viel mehr als du brauchst.
Für mich siehts anders aus.
Ne Bestätigung dass das was ich denke auch richtig ist habe ich aber nicht. (Wie bereits erwähnt)
Aber es ist -für mich- die einzig mögliche logische Erklärung.
"ich denke" das ist bei meinem Prozess haargenau der Fall.es ist ja jetzt nicht so, .............., dass die einzeln prozessed und zwischendurch wieder wo hingeschrieben werden würden.

Deins ist da btw. auch wieder nur ne Vermutung

Delay -> audio wird in den Buffer geschrieben -> der buffer (gespeichertes audio)wird ausgelesen -> der Zeit parameter des delays wird manipuliert ( das delay steht dabei im kleinen ms bereich, inkl. aufgedrehtem FB)
-> dieses manipulierte audio geht ins nächste delay ( ähnliche Einstellungen). Wird also erneut in nen buffer geschrieben,....und wird erneut ausgelesen -> dieses Delay wird auch im Zeit parameter manipuliert, -ZEITGLEICH-,
-> dieses audio geht in noch ein delay, selbe Geschichte ! wird auch -ZEITGLEICH- manipuliert.
Weiss nicht bis wie weit ich das jeweils getrieben habe. 4 stück delays hintereinander ganz sicher. Hab aber ein delay verwendet gehabt das in sich selbst delays stacken kann........
also mehrfach seriell hintereinander, audio in buffer schreiben, dieser Inhalt des buffers wird manipuliert während es ausgelesen wird.
alles mehrfach hintereinander.
ALLE Delays werden zum gleichen zeitpunkt manipuliert !
D.h. es ist immer der inhalt des buffers der jetzt -als audio- manipuliert wird, und damit den sound ändert.
Das ist echtzeit sounddesign, FXing in serieller abfolge, während die manipulation auf allen verarbeitungsstufen nicht seriell, sondern parallel erfolgt.
Die delays stehen dabei nicht nur im kleinen ms bereich was den Zeitfaktor angeht. Die manipulation geschieht mit nem fader den man sehr schnell bewegt. ( Das sind alles Faktoren die hier mit rein spielen in Bezug zu, was geht und was nicht)
und jetzt sag du mir ob das Sinn macht zu denken dass ich "so" das ganze Ding am Datendurchsatz an die Grenze bringen kann ?
Dass das alles kein Problem wäre, wenn alles innerhalb eines einzigen plugins abliefe, das ist mir klar. Ich sehe es jedenfalls so.
Aber der ganze ablauf auf mehrere plugins verteilen ?
Scheint was zu ändern
Dann fängt das irgendwann an zu zicken.
Und ich behaupte jetzt, dass ein schnellerer Datendurchsatz da bei dem ganzen hilft.
Da ist ne Relation zu sehen.
Das behaupte ich so.

hab da ausführliche tests gemacht gehabt (auf dem M1)
Daraus leite ich im weiteren ab, das wenn du in ner DAW sehr viel automatisierst, dann zwar anders aufgebaut, aber allenfalls auf vielen Tracks gleichzeitg, dass du dort -wenn alles blöd geht- allenfalls auch ans limit des datendurchsatzes kommen kannst.
Der springende Punkt ist aus meiner Sicht definitv das Ding mit "audio in nen Buffer schreiben", ...wieder auslesen, wieder in nen buffer schreiben.
also delays + Reverbs sind hier die ersten kandidaten.
Weiss nicht. Ich würde bei nem "teureren" PC auf Nummer Sicher gehen wollen.
Der DAW hilfts aber dass die auf vielen Kernen arbeiten kann.
Drum hilfts umgekehrt auch mehr Kerne zu nehmen als man von der reinen CPU gesammtpower vielleicht brauchen würde.
Die DAW kann dann die Lasten einfacher verteilen.