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)
I've been working with loading files into arrays in the meantime, and have
a question. When I read a sound file into an array, the length is sent to the stdout window. I would like to use that value in pd. Is it accessible somehow? I'm getting clicks at the start and finish of playing the content of the arrays, so if I could find out the length of the sound file, I could mute the output to the dac~ at the appropriate times. Any ideas?
I'm a bit confused as to the difference between a graph and array. It
seems that I should make a graph, and then create an array in it?
Michael Lechasseur
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
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
Ah, I see. Thanks for the info.
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.
It's sounds *really* great, but I'm doing my DSP in linux.
I think to use the sfplay as plain straightforward 16bit audiofileplayer (with offset funcion and byte swap option) and hopefully readsf~ as sophisticated one.
Let me know when it's written.. hehe..
I'm going to try to compile Guenter's version for linux and see what I can
do with it. I found the compile instructions from the list archive..
Michael Lechasseur
Here is the sfplay prerelease of sfplay:
ftp://iem.mhsg.ac.at/pd/Externs/sfplay/
mfg winfried
Michael Lechasseur writes:
Let me know when it's written.. hehe..
I'm going to try to compile Guenter's version for linux and see what I can do with it. I found the compile instructions from the list archive..
Michael Lechasseur
Actually a "make" by itself should do for Linux. You'll get a library ggext.pd_linux, which you just have to load with "-lib ggext". And, .. everything there is experimental :)
I have uploaded a new test version to
ftp://gige.epy.co.at/pub/pd/linux/pd-0.25TEST5linux.tar.gz
This version features an improved table object (table has an inlet which accepts messages read16, resize ...). It is not possible anymore to put objects into the table canvas directly, because they will not be saved. Using tables with abstractions is save now.
Look for the example in "3.reference/table.pd". It shows an example of a sample player without any variables (global) symbols declared explicitely.
Have fun
Guenter
This version features an improved table object (table has an inlet...
Look for the example in "3.reference/table.pd".
I get a:
Segmentation fault (core dumped)
pd_gui: pd process exited
When I try to load "3.reference/table.pd" or use the new table object.
RedHat 5.2, Kernel 2.1.130, es1370.c driver
Actually a "make" by itself should do for Linux. You'll get a library ggext.pd_linux, which you just have to load with "-lib ggext". And, .. everything there is experimental :)
Hmm.. I couldn't get this to work. When you say that a regular "make" will
compile them, you mean that if I take the 0.25TEST4 package, and do a regular compile, the objects in the /src/ext will get compiled? This seems to be the case, as I get *.pd_linux files in that folder.
I did not see a ggext.pd_linux though? Which version of pd should have
this? Should I move the file anywhere in particular, or will pd know where to find it if I did an install with no modifications?
Is it possible to load the sfread.pd_linux file as a library? I tried
without success.
Thanks,
Michael Lechasseur
Michael Lechasseur writes:
This version features an improved table object (table has an inlet...
Look for the example in "3.reference/table.pd".
I get a:
Segmentation fault (core dumped) pd_gui: pd process exited
When I try to load "3.reference/table.pd" or use the new table object.
RedHat 5.2, Kernel 2.1.130, es1370.c driver
Ooops .. thanks, I didn't test it on Intel. I did put a new version on the server, which works on my Intel machine.
Actually a "make" by itself should do for Linux. You'll get a library ggext.pd_linux, which you just have to load with "-lib ggext". And, .. everything there is experimental :)
Hmm.. I couldn't get this to work. When you say that a regular "make" will compile them, you mean that if I take the 0.25TEST4 package, and do a
Ah, I understand. I started packaging my externals into ggext and applied a version number, so that people testing it can relate to it. I thought you where using that version.
http://gige.epy.co.at/pd/pdlib/externals http://wonk.epy.co.at/pdlib/externals
Guenter