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
