not necessarily as a "always delay before playing" sort of thing but
more a short description of how it works,
I agree! It's always better when the user actually understands *why*
they need to do something.
In general, though, I would advice everyone to consider a delay between
"open" and
As Christof says, fine tuning the reader buffer size could be thought
of as fine tuning the audio buffer length, ie. a 64 block size is
faster but has less space/time if your patch does some really CPU
intensive stuff. If you don't need super responsively, you can
increase the block size.
*This* is a good point and worth noting, not necessarily as a "always delay
before playing" sort of thing but more a short description of how it works,
then a note like "if you experience occasional dropouts on first accessing a
file, consider adding a small delay after opening but *before*
To echo Christof, each object has a parallel worker thread as the file I/O
could block Pd's audio thread. It takes time to read the beginning of the file
(or from the start point) before it can be played back.
IMO the warning / concern in the help file is really from a time of *much*
slower
Actually, I forgot something important:
Of course, the worker thread must also *open* the file! If the file is
not yet cached by the OS, this can indeed take a few milliseconds.If you
don't add some delay between "open" and "start", you might notice that
you get a dropout the very first time,
