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

Roman Haefeli reduzierer at yahoo.de
Tue Jul 15 19:48:39 CEST 2008

On Tue, 2008-07-15 at 19:09 +0200, Frank Barknecht wrote:
> Hallo,
> Damian Stewart hat gesagt: // Damian Stewart wrote:
> > Dr. Greg Wilder wrote:
> > > Matt Barber wrote:
> > >> Hey Greg,
> > >>
> > >> I wonder what would happen
> > >> if you split your 8-channel files and played them simultaneously as
> > >> 4-channel soundfiles...  
> > 
> > how long are the files? if they're not so long, and you've got a computer 
> > with a lot of memory, you might be able to load them all to RAM. if 
> > they're, say, 10 minutes each, and you have 8, then thats 10*60*44100*8 
> > channels * 4 bytes (32 bit sample data) = 810MB of data. hrm. perhaps not..
> And as Greg uses 88200 kHz samplerate, it's twice as much. ;)

there were several discussions on this list about the precision problem
when using [tabread*] with big tables (above 16777216 samples not every
sample can be accessed anymore). 
i wonder now, wether this applies as well to [tabplay~], or is this one
not using some kind of indexing, but just plays samples consecutively? 

as an alternative: 
assuming the files were in 16 bit, wouldn't it make more sense to create
a ramdisk and store all wav-files there in order to read them with
[readsf~]? this way you would save half of the amount, because they are
stored as 16 bit instead of 32 bit then.


Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de

More information about the Pd-list mailing list