16-10-10 03.14
Appoggio Barbetta e poi è da sempre risaputo, un VST a modelli fisici si installa con pochi, pochissimi mega, (il VB3 arriva a 1,5-1,6 Mb) e tutto il lavoro lo fà in diretta la CPU, mentre leggere campioni, anche a suon di Giga x volta, per le moderne CPU è un passeggiata, devono solo stare a guardare il flusso proveniente dal buffer.16-10-10 13.31
prova a far girare ivory o un altro vst di piano con un disco a 5400 te lo sputano fuori schifati
16-10-10 14.28
nulla, sono d'accordo, ma il disco a 5400 giri va benone lo stesso. vuol dire che faremo la prova anche con i vst. siete duri di comprendonio.
16-10-10 15.15
detto fatto; non ho ivory, e nemmeno plugins pesanti installati sul disco interno (per motivi di spazio, non per altro), ma omnisphere sì.
16-10-10 15.22
16-10-10 15.42
per qualsiasi tipo di evento audio è previsto un buffer in RAM. nell'audio vero è proprio c'è un preload che è fissato di default in 2 secondi. 2 sec=88.000 campioni x 16 bit = 1.400.000 bit = 1,5 Mb circa x 164 tracce = 246Mb di ram impegnata. vuol dire che in ram vengono caricati 2 secondi per ogni traccia e ogni 2 sec il buffer viene ririempito: l'hard disk a 5400 giri ce la fa più che tranquillamente a seguire una cosa del genere.16-10-10 15.42
16-10-10 16.01
16-10-10 16.01
dovrebbe esistere anche il modo di determinare la quantità di preload. nelle faq c'è scritto che per ovviare all'inconveniente slow disk è possibile aumentare la quantità di preload e/o ridurre la polifonia dello strumento. comunque sia, per il funzionamento ottimale hai ragione tu, evidentemente.