[PD] how to avoid (most/many/some) readsf~ dropouts

[Matt Barber]

> Date: Sat, 12 Jul 2008 13:56:54 +0200
> From: Damian Stewart <damian at frey.co.nz>
> Subject: [PD] how to avoid (most/many/some) readsf~ dropouts
> To: PD-List <pd-list at iem.at>
> Message-ID: <48789C06.4030401 at frey.co.nz>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> hey,
>
> one thing i've noticed with readsf~ using it in my own live-performance
> sets is that doing this
>
> [symbol blahblahblah.aif]
> |
> [open $1, bang(
> |
> [readsf~]
>
> sometimes causes dropouts. but if you go
>
> [symbol blahblahblah.aif]
> |
> [t b a]
> |      \____
> |           \
> [del 50]    [open $1(
> | __________/
> |/
> [readsf~]
>
> then you remove (all/many/some) of the dropouts. i haven't extensively
> tested this, but anecdotal evidence seems to suggest that it works.
>


I think this is because the former method may not let the buffer fill
before you start playing.  I usually don't like the second method,
either, because of the 50 ms delay (which isn't much, but I'm finicky
about that kind of thing).  Depending on the setup, I usually prefer
something like the following:

                  [loadbang]
                   |
                   | [r open]
                   | /
                  [open  file.ext (
[0 (     [1 (    |
 |          \__   |
[t b f ]_____\ |
 |               [readsf~ ]
[s open]                |
                           [s open]


I hope things line up okay there... at any rate, you load the buffer
at the beginning, or if your piece/performance has a master clock, a
couple of seconds before you need it.  Then for rehearsal, if you need
to stop the file you can use a trigger to reload it immediately.
Also, if you need to play the file again, you can send the "open"
message when the file is done playing.  This makes the whole process a
little more "front-loaded," so that the soundfile is always "open" no
matter what.  My intuition is that it's more robust than other schemes
I've tried.  I haven't tested it very hard, though, as I've only ever
needed up to 9-10 simultaneous 96k files... maybe it would be neat to
find some old, slow hardware to see how far different methods can be
pushed.  =o)

More advanced for stopping would be something that fades out the sound
with a [line~] over 20 ms or so, and then sends the stop message to
[readsf~] after a comparable delay -- that way you won't get an
annoying transient upon stop -- same deal with a fade in if you are
starting in the middle of the soundfile, but without the delay.  I
usually wrap the whole thing in an abstraction -- I keep three or four
different ones lying around with different properties for different
situations, and I'm happy to share with anyone who might find them
useful.


Thanks,


Matt