[PD] help making sense of [readsf~]

[Christof Ressi]

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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20240307/e464029b/attachment-0001.htm>