[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.


roman


	
		
___________________________________________________________ 
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