Greg, you may like to experiment with tweaking the disk caches. For linux see here:
http://www.linuxdevcenter.com/pub/a/linux/2000/06/29/hdparm.html On Mon, 14 Jul 2008 17:11:02 -0400 "Dr. Greg Wilder" <[EMAIL PROTECTED]> wrote: > 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 > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list -- Use the source _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
