Michael Lechasseur writes:
Hi,
I've been doing a lot of experimenting with pd during the last couple of days, and I'm having a great time. I'm working with sound files, and thought that I might find some advice here.
I see that an sfread object is included in the externs directory, and I am wondering how I should go about compiling it? The files of code are there, but it doesn't seem available to me in pd, so I don't think that it got compiled on install? (version 0.25TEST4)
Now 0.25 is out and it is not in the dist, because
it works only on linux or machines which do mmap (made by guenther geiger)
there is mentioned in the todo-list readsf~, writesf~ the official
ones
I have done a sfplay as a state-machine distributing the load over some ticks..., it works for NT now, I can put it on the server if you want tommorow.
On a Pentium-II 350MHz and SCSI I did 32 soundfiles (SR=44100, channel=1) playing paralell under good conditions. I did once a version for another program with paralell (forked) opening loading, but there is not much performance hit (even vice versa because of paralell process) since files are buffered anyway by the OS and cached by modern hardisk in their RAM. The only thing is you cannot have too small audiobuffers especially the open function can do a long job (so I dont use search paths).
Only having heavy random access (jumping in a big file) own caching with look ahead strategy could be better.
I think to use the sfplay as plain straightforward 16bit audiofileplayer (with offset funcion and byte swap option) and hopefully readsf~ as sophisticated one.
One idea was also to split openening and playing in two objects, so you can open more files and play fewer, switching without break, with less power needed in sum. ?
What do you think about ?
mfg winfried