New subject: how to avoid (most/many/some) readsf~ dropouts

14 Jul 2008


      Damian Stewart wrote:
...
Dr. Greg Wilder wrote:
...
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?
first thing i notice when i open it up is this:
on the left hand side, you've got a 'random 50' and a '+ 6', going into 
the delay. this means the minimum delay will be 6ms, which i doubt is 
long enough.
why the random? why not just hardcode 50ms in there? or at least go 
'random 30' and '+ 40' or something.
hth,
d
Indeed.  Sorry about that -- I pulled the example from a larger 
abstraction which added another 2000 to the delay amount, but the +2000 
didn't get copied.
At any rate, the "randomized" load time is there to prevent the patch 
triggering multiple files at exactly the "same" moment.  My 
understanding is that PD's execution order doesn't allow simultaneous 
events to collide, however I have found I get better results when I 
leave a few extra milliseconds between "simultaneous" triggers.  Perhaps 
it would be smarter to use a hard coded [t b b b]?
Also, I should point out that the dropouts I experienced happened at 
different points during playback.  Sometimes near the beginning, other 
times 50 seconds in...
G

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