Hi, have been using WvIn for some while as a workaround to read a data file into chuck (this was suggested by someone in an earlier post), e.g. WvIn w => blackhole; "data.wav" => w.path; float n; repeat(20) { 1::samp => now; w.last() => n; <<< n >>>; } This works fine on my mac. However, when I try to do this in linux, it fails, sort of. The first value is the same as on os x, but then they deviate, not completely, but significantly (more than 10%), so it can't be a simple rounding error. I'm relatively sure that the values on the mac are correct because I write the data to the wav file myself. It's not obvious to me why the reading of any .wav file (using last()) should produce different values on different operating systems, but they do on my computers! Does anyone know what could be going on here? thanks, jo
Jo;
This works fine on my mac. However, when I try to do this in linux, it fails, sort of. The first value is the same as on os x, but then they deviate, not completely, but significantly (more than 10%), so it can't be a simple rounding error.
Could it be that the wav is 44.1 KHz (probably the Mac default), that your Linux install uses 48KHz (default on Linux, I think) and that ChucK is attempting to compensate for the playback speed and interpolate? That would muck up your data quite a bit, I imagine. I suggest forcing the sample rate on Linux to be 44.1KHz and trying again. Yours, Kas.
Kassen, that's exactly what's happening, it works fine if I force the sampling rate to 44.1kHz! Thanks a lot! jo Am 06.05.2009 um 15:09 schrieb Kassen:
Jo;
This works fine on my mac. However, when I try to do this in linux, it fails, sort of. The first value is the same as on os x, but then they deviate, not completely, but significantly (more than 10%), so it can't be a simple rounding error.
Could it be that the wav is 44.1 KHz (probably the Mac default), that your Linux install uses 48KHz (default on Linux, I think) and that ChucK is attempting to compensate for the playback speed and interpolate? That would muck up your data quite a bit, I imagine.
I suggest forcing the sample rate on Linux to be 44.1KHz and trying again.
Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Jo;
that's exactly what's happening, it works fine if I force the sampling rate to 44.1kHz!
You might also want to have a look at using SndBuf and it's .valueAt( int index ) function. I'm not sure what kind of data you are using and for what purpose but I think that in many cases such a index will be more useful than playing back the file. Yours, Kas.
Chuck in CVS has crude file IO... I've been making use of it over
here. Especially if all you're trying to do is read numbers in, there
are methods for parsing ints and floats from text files. very handy.
-Mike
On Wed, May 6, 2009 at 10:11 AM, Kassen
Jo;
that's exactly what's happening, it works fine if I force the sampling rate to 44.1kHz!
You might also want to have a look at using SndBuf and it's .valueAt( int index ) function.
I'm not sure what kind of data you are using and for what purpose but I think that in many cases such a index will be more useful than playing back the file.
Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
So basically I would like to feed in floats (results from physics simulations, e.g. position of a particle at some point) which are stored in an array in chuck and then apply them to some parameter of a sound (e.g. pitch, gain). Using a wav file turned out to work well for me (writing the header and then the float data as 16bit integers in matlab and getting floats from -1. to 1. in chuck). Actually, thinking about it now it would possibly be even easier to use OSC and send the data using python, but I'll also look at using SndBuf... jo Am 06.05.2009 um 16:11 schrieb Kassen:
Jo;
that's exactly what's happening, it works fine if I force the sampling rate to 44.1kHz!
You might also want to have a look at using SndBuf and it's .valueAt( int index ) function.
I'm not sure what kind of data you are using and for what purpose but I think that in many cases such a index will be more useful than playing back the file.
Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Jo;
So basically I would like to feed in floats (results from physics simulations, e.g. position of a particle at some point) which are stored in an array in chuck and then apply them to some parameter of a sound (e.g. pitch, gain). Using a wav file turned out to work well for me (writing the header and then the float data as 16bit integers in matlab and getting floats from -1. to 1. in chuck).
Yes, that makes perfect sense. I think I would considder increasing the bit-depth of the wave file in this case, depending on how much resolution you need. For gain 16 bit would likely do but when you are modulating pitch I think it might make sense to increase the resolution. 16 bit is a popular format and all soundcards will be able to play it but here we aren't all that interested in actually playing the file as audio so I don't think there is anything keeping you from using -say- a 32 bit wave file.
Actually, thinking about it now it would possibly be even easier to use OSC and send the data using python, but I'll also look at using SndBuf...
I'm not sure; Python would mean involving a third system (matlab, Python and ChucK). I think either the file-IO from CVS (I haven't actually looked at that myself though) or your wave file method combined with SndBuf would be faster and more efficient. Wave files do seem like a very natural way to store tables to me, especially for continuous data like particle locations. Interpolation might make sense for that type of data as well. You may also want to poke around multi-channel wav files to see whether those would be useful for you. Yours, Kas.
Mike, thanks, I'll look into it! Kassen,
don't think there is anything keeping you from using -say- a 32 bit wave file. you're right, of course, I should do that and I could also interpolate, but so far I had no problems, updating the parameters every, say, 20ms, although it's very likely not to be the most efficient solution...
Python would mean involving a third system (matlab, Python and ChucK).
it would complicate things (matlab is also just out of convenience, could use python as well there), but I'd love to hook up an arduino to the whole thing (eventually I want to build an interactive sound installation, although the whole idea is only in its infancy) and arduino => python => chuck seems easiest to me as long as there is no serial support in chuck. All the best, jo Am 06.05.2009 um 20:28 schrieb Kassen:
Jo;
So basically I would like to feed in floats (results from physics simulations, e.g. position of a particle at some point) which are stored in an array in chuck and then apply them to some parameter of a sound (e.g. pitch, gain). Using a wav file turned out to work well for me (writing the header and then the float data as 16bit integers in matlab and getting floats from -1. to 1. in chuck).
Yes, that makes perfect sense. I think I would considder increasing the bit-depth of the wave file in this case, depending on how much resolution you need. For gain 16 bit would likely do but when you are modulating pitch I think it might make sense to increase the resolution.
16 bit is a popular format and all soundcards will be able to play it but here we aren't all that interested in actually playing the file as audio so I don't think there is anything keeping you from using -say- a 32 bit wave file.
Actually, thinking about it now it would possibly be even easier to use OSC and send the data using python, but I'll also look at using SndBuf...
I'm not sure; Python would mean involving a third system (matlab, Python and ChucK). I think either the file-IO from CVS (I haven't actually looked at that myself though) or your wave file method combined with SndBuf would be faster and more efficient. Wave files do seem like a very natural way to store tables to me, especially for continuous data like particle locations. Interpolation might make sense for that type of data as well. You may also want to poke around multi-channel wav files to see whether those would be useful for you.
Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Jo,
Arduino => Python => ChucK is my mainstay, actually. ;-) works like a charm.
PySerial is a great lib, as you likely already know
(http://pyserial.wiki.sourceforge.net/pySerial). Also, I have had
more success with PyLiblo than with Simple OSC because it's much
faster, although you can easily flood ChucK with OSC with either
implementation. If you decide to go the PyLiblo route, however, and
you're using a Mac, you should be aware that there is a slightly weird
issue compiling it due to the place that the library hides on Mac OS.
See this post: http://michaelclemow.com/?p=556 if you're getting
errors. Simple OSC is much easier to install:
http://ixi-software.net/content/backyard.html
That being said, Serial support in ChucK would so, so, so badass...
imagine a million hardware hackers making insanely cool interfaces to
their digital instruments. Look out, NIME!
_mc
On Wed, May 6, 2009 at 6:52 PM, jo
Mike, thanks, I'll look into it! Kassen,
don't think there is anything keeping you from using -say- a 32 bit wave file.
you're right, of course, I should do that and I could also interpolate, but so far I had no problems, updating the parameters every, say, 20ms, although it's very likely not to be the most efficient solution...
Python would mean involving a third system (matlab, Python and ChucK).
it would complicate things (matlab is also just out of convenience, could use python as well there), but I'd love to hook up an arduino to the whole thing (eventually I want to build an interactive sound installation, although the whole idea is only in its infancy) and arduino => python => chuck seems easiest to me as long as there is no serial support in chuck.
All the best, jo
Am 06.05.2009 um 20:28 schrieb Kassen:
Jo;
So basically I would like to feed in floats (results from physics simulations, e.g. position of a particle at some point) which are stored in an array in chuck and then apply them to some parameter of a sound (e.g. pitch, gain). Using a wav file turned out to work well for me (writing the header and then the float data as 16bit integers in matlab and getting floats from -1. to 1. in chuck).
Yes, that makes perfect sense. I think I would considder increasing the bit-depth of the wave file in this case, depending on how much resolution you need. For gain 16 bit would likely do but when you are modulating pitch I think it might make sense to increase the resolution.
16 bit is a popular format and all soundcards will be able to play it but here we aren't all that interested in actually playing the file as audio so I don't think there is anything keeping you from using -say- a 32 bit wave file.
Actually, thinking about it now it would possibly be even easier to use OSC and send the data using python, but I'll also look at using SndBuf...
I'm not sure; Python would mean involving a third system (matlab, Python and ChucK). I think either the file-IO from CVS (I haven't actually looked at that myself though) or your wave file method combined with SndBuf would be faster and more efficient. Wave files do seem like a very natural way to store tables to me, especially for continuous data like particle locations. Interpolation might make sense for that type of data as well. You may also want to poke around multi-channel wav files to see whether those would be useful for you.
Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
participants (3)
-
jo -
Kassen -
mike clemow