Matt Barber wrote:
Date: Sat, 12 Jul 2008 13:56:54 +0200 From: Damian Stewart damian@frey.co.nz Subject: [PD] how to avoid (most/many/some) readsf~ dropouts To: PD-List pd-list@iem.at Message-ID: 48789C06.4030401@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
Matt and Damian,
In working on a recent piece for marimba and 8-channel computer (24bit/88.2kHz), I consistently experienced intermittent clicks and audio dropouts -- even on high-end hardware running GNU/Linux. Increasing the readsf buffer and the time between file load (open) and playback (readsf) helped some, but not enough. Since the premiere last month, I've been rebuilding the abstractions for better efficiency, but am still not happy with the results -- and before the soloist can safely tour the piece, I need to work out a more robust solution.
I've attached the latest version of my "basic" playback (w/fade) patch for suggestions/comments... Unfortunately, your ascii patch didn't line up, would you mind posting an example patch that shows your method?
Best, G