sfread

[Winfried Ritsch]

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