[PD] help making sense of [readsf~]

[Alexandre Torres Porres]

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 at 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 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/0da400a4/attachment.htm>