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 <[email protected]> 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 < > [email protected]> 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 >> >>
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
