On 07.03.2024 04:05, Alexandre Torres Porres wrote:
I definitely did get dropouts. Maybe you just never noticed it :-D Or macOS has just faster file I/O than Windows (which I believe is indeed the case).thing is I can never hear dropouts, don't think I've ever had problems, then it seemed that the issue might be first accessing an uncached file, which kinda made sense why I never faced this.... I also have an abstraction that is a wrap around readsf~ that doesn't care about this and I use it many times to randomly play samples from sample banks, never found anything funny (ok, my performances are usually loud and noisy anyway, haha)
Yes, very likely.
And for testing now, I just recorded a new file (ok it was in Pd), then renamed it and moved it elsewhere, no dropouts either, did my system cash this somehow and kept track of it?
Anyway, I really like how Dan put it... which is you "may" get dropouts... "if you do" then you should do this... because putting this as something thas *has* to be done everytime doesn't seem right... :)
I don't agree. The problem with "if you do" is that it isn't
portable. If you don't care about writing portable patches, that's
probably fine, but I think we should really teach users the
correct and portable way. The very idea of [readsf~] is that you
don't open the file on the audio thread, but when you do [open
<f>, start( you indirectly block the audio thread. Just
don't do it!
I've already mentioned this, but if you do [open <f>, start( it can become quite awkward to change later. Better do the right thing from the beginning.
(BTW, the equivalent SuperCollider object would be DiskIn UGen +
Buffer.cueSoundFile; there you don't even have the chance to skip
the buffering step.)
Em qua., 6 de mar. de 2024 às 23:33, Christof Ressi <info@christofressi.com> escreveu:
On 07.03.2024 02:38, Alexandre Torres Porres wrote:
> on first accessing a file
I think this would cause more confusion than it would help. (What does
"first accessing" actually mean?)
I wrote about the case where the file is not yet cached by the OS, but
IMO that is too specific for a help patch. Also, it isn't the *only*
case that can cause a dropout. In general, file I/O is non-deterministic
and you are at the mercy of your OS.
I think it's enough to tell users that the buffer needs to be filled in
time.
Christof