Matt Barber wrote:
Date: Sat, 12 Jul 2008 13:56:54 +0200
From: Damian Stewart <[EMAIL PROTECTED]>
Subject: [PD] how to avoid (most/many/some) readsf~ dropouts
To: PD-List <[email protected]>
Message-ID: <[EMAIL PROTECTED]>
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
--
http://www.orpheusmediaresearch.com/
http://www.gregwilder.com/
+1 215-764-6057 (office)
+1 215-205-2893 (cell)
#N canvas 65 224 902 519 10;
#X msg 86 198 1;
#X msg 129 198 0;
#X obj 175 128 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1
-1;
#X obj 129 178 r stop;
#X obj 86 105 + 6;
#X floatatom 86 125 5 0 0 0 - - -;
#X obj 175 373 *~;
#X obj 383 147 loadbang;
#X obj 441 147 r reset_vol;
#X text 401 127 master volume;
#X obj 86 84 random 50;
#X obj 243 373 *~;
#X obj 174 395 throw~ ch1;
#X obj 242 395 throw~ ch2;
#X obj 312 373 *~;
#X obj 380 373 *~;
#X obj 311 395 throw~ ch3;
#X obj 379 395 throw~ ch4;
#X obj 574 145 delay 500;
#X msg 383 168 100;
#X msg 441 168 100;
#X obj 667 241 \$1;
#X obj 395 351 vline~;
#X obj 328 351 vline~;
#X obj 258 351 vline~;
#X obj 191 351 vline~;
#X obj 86 143 delay;
#X obj 448 373 *~;
#X obj 516 373 *~;
#X obj 584 373 *~;
#X obj 574 224 dbtorms;
#X floatatom 574 185 5 0 0 0 - - -;
#X obj 574 203 * 1;
#X obj 652 373 *~;
#X obj 667 351 vline~;
#X obj 600 351 vline~;
#X obj 531 351 vline~;
#X obj 464 351 vline~;
#X text 599 204 (vol%);
#X obj 447 395 throw~ ch5;
#X obj 515 395 throw~ ch6;
#X obj 583 395 throw~ ch7;
#X obj 651 395 throw~ ch8;
#X msg 175 151 open 8ch_acheron_blasts.wav;
#X msg 574 165 0;
#X msg 667 262 \$1 3500;
#X obj 667 283 unpack f f;
#X obj 724 304 + 1025;
#X text 719 262 fade time in ms;
#X floatatom 724 325 5 0 0 0 - - -;
#X obj 441 189 delay;
#X obj 441 209 bng 15 250 50 0 empty empty empty 0 -6 0 10 -262144
-1 -1;
#X obj 175 67 r acheron_play;
#X obj 574 124 r acheron_fade;
#X obj 175 215 readsf~ 8 1e+06;
#X connect 0 0 54 0;
#X connect 1 0 54 0;
#X connect 2 0 43 0;
#X connect 2 0 26 0;
#X connect 3 0 1 0;
#X connect 4 0 5 0;
#X connect 5 0 26 0;
#X connect 6 0 12 0;
#X connect 7 0 19 0;
#X connect 8 0 20 0;
#X connect 10 0 4 0;
#X connect 11 0 13 0;
#X connect 14 0 16 0;
#X connect 15 0 17 0;
#X connect 18 0 44 0;
#X connect 19 0 31 0;
#X connect 20 0 31 0;
#X connect 21 0 45 0;
#X connect 22 0 15 1;
#X connect 23 0 14 1;
#X connect 24 0 11 1;
#X connect 25 0 6 1;
#X connect 26 0 0 0;
#X connect 27 0 39 0;
#X connect 28 0 40 0;
#X connect 29 0 41 0;
#X connect 30 0 21 0;
#X connect 31 0 32 0;
#X connect 32 0 30 0;
#X connect 33 0 42 0;
#X connect 34 0 33 1;
#X connect 35 0 29 1;
#X connect 36 0 28 1;
#X connect 37 0 27 1;
#X connect 43 0 54 0;
#X connect 44 0 31 0;
#X connect 45 0 22 0;
#X connect 45 0 23 0;
#X connect 45 0 24 0;
#X connect 45 0 25 0;
#X connect 45 0 37 0;
#X connect 45 0 36 0;
#X connect 45 0 35 0;
#X connect 45 0 34 0;
#X connect 45 0 46 0;
#X connect 46 1 47 0;
#X connect 47 0 49 0;
#X connect 49 0 50 1;
#X connect 50 0 20 0;
#X connect 50 0 51 0;
#X connect 51 0 1 0;
#X connect 52 0 10 0;
#X connect 52 0 2 0;
#X connect 53 0 18 0;
#X connect 53 0 50 0;
#X connect 54 0 6 0;
#X connect 54 1 11 0;
#X connect 54 2 14 0;
#X connect 54 3 15 0;
#X connect 54 4 27 0;
#X connect 54 5 28 0;
#X connect 54 6 29 0;
#X connect 54 7 33 0;
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
