ok, I'm working a bit more on it and will take your suggestion, which is " "You should wait a few milliseconds between "open" and "start" to ensure that the buffer is filled in time, otherwise you may get a dropout."" or something like that...
Em qui., 7 de mar. de 2024 às 00:27, Christof Ressi info@christofressi.com escreveu:
On 07.03.2024 04:05, Alexandre Torres Porres wrote:
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)
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).
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?
Yes, very likely.
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.) Christof
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