Hello, Just started with chuck 1.1.4.6, cygwin/win2000 and also MacOSX. I get sound fine from synth generators (larry.ck, moe.ck examples) but not from sndbuf (sndbuf.ck example). The file appears to get read, I just don't hear any output. I'm using 16/44.1 stereo wav samples from ampfea.org, e.g.
sndbuf.ck --- sndbuf buf => dac; "snare.wav" => buf.read; while( true ) { 0 => buf.pos; 100::ms => now; } michael
Hmm. I'd noted something going on last night myself. the sndfile library we're using might be finicky about sound file formats Does this problem occur on both platforms, or with other formats ( aiff ? au? ) Phil On Thursday, September 2, 2004, at 07:22 PM, Michael Heuer wrote:
Hello,
Just started with chuck 1.1.4.6, cygwin/win2000 and also MacOSX. I get sound fine from synth generators (larry.ck, moe.ck examples) but not from sndbuf (sndbuf.ck example). The file appears to get read, I just don't hear any output.
I'm using 16/44.1 stereo wav samples from ampfea.org, e.g.
sndbuf.ck --- sndbuf buf => dac; "snare.wav" => buf.read;
while( true ) { 0 => buf.pos; 100::ms => now; }
michael
_______________________________________________ chuck mailing list chuck@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck
On Thu, 2 Sep 2004, Philip Davidson wrote:
Hmm. I'd noted something going on last night myself. the sndfile library we're using might be finicky about sound file formats
Does this problem occur on both platforms, or with other formats ( aiff ? au? )
Also occurs with AIFF on cygwin/win2000, will have to wait until tomorrow to check with MacOSX. michael
Phil
On Thursday, September 2, 2004, at 07:22 PM, Michael Heuer wrote:
Hello,
Just started with chuck 1.1.4.6, cygwin/win2000 and also MacOSX. I get sound fine from synth generators (larry.ck, moe.ck examples) but not from sndbuf (sndbuf.ck example). The file appears to get read, I just don't hear any output.
I'm using 16/44.1 stereo wav samples from ampfea.org, e.g.
sndbuf.ck --- sndbuf buf => dac; "snare.wav" => buf.read;
while( true ) { 0 => buf.pos; 100::ms => now; }
michael
_______________________________________________ chuck mailing list chuck@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck
_______________________________________________ chuck mailing list chuck@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck
there's a bug in that example. sndbuf needs to have a non-zero rate specified before it starts to play. 1.0 => buf.rate; will do the trick .rate controls the playback speed, relative to the 'proper' speed of the file and it's set to 0 by default the example has been updated in cvs. that bug aside, i've noticed some issues with sndfile that i'm hoping to track down, so let me know if you find more errors thank you! *Phil
Shouldn't the default be a rate of 1.0?? PRC On Thu, 2 Sep 2004, Philip Davidson wrote:
there's a bug in that example.
sndbuf needs to have a non-zero rate specified before it starts to play.
1.0 => buf.rate; will do the trick
.rate controls the playback speed, relative to the 'proper' speed of the file and it's set to 0 by default
the example has been updated in cvs.
that bug aside, i've noticed some issues with sndfile that i'm hoping to track down, so let me know if you find more errors
thank you!
*Phil
_______________________________________________ chuck mailing list chuck@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck
if default were 1.0, it would automatically start to play the moment that .read finishes, which isn't always what we want. --now-- sndbuf buf => dac; "snare.wav" => buf.read; 1.0 => buf.rate; while( true ) { 0 => buf.pos; 100::ms => now; } ----- what we need is .play, and .stop which set/unset a flag, independent of playback speed. i'll add those tonight, and then a default of 1.0 is proper. --soon-- sndbuf buf => dac; "snare.wav" => buf.read; 500::ms => now; buf.play; while( true ) { 100::ms => now; 0 => buf.pos; } Phil On Thursday, September 2, 2004, at 08:06 PM, Perry R Cook wrote:
Shouldn't the default be a rate of 1.0??
PRC
On Thu, 2 Sep 2004, Philip Davidson wrote:
there's a bug in that example.
sndbuf needs to have a non-zero rate specified before it starts to play.
1.0 => buf.rate; will do the trick
.rate controls the playback speed, relative to the 'proper' speed of the file and it's set to 0 by default
the example has been updated in cvs.
that bug aside, i've noticed some issues with sndfile that i'm hoping to track down, so let me know if you find more errors
thank you!
*Phil
_______________________________________________ chuck mailing list chuck@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck
_______________________________________________ chuck mailing list chuck@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck
Hello, Is there built-in support for time signatures, or should I just be doing something like 400::ms => dur q; 4::q => dur w; 2::w => now; while (true) { q => now; ... } It would be nice to be able to write a file or shred using time-signature based durations and be able to change the values of those durations from somewhere else, effectively changing the BPM of everything you may have running simultaneously. michael
Gary and I have talked about this. Actually coming up with a semantic to assign new types relative to others, and having them automatically update when the root types are changed. Something like: 100 ms => dur quarter; 4*quarter => dur =whole; // some semantic i forgot now 50 ms => quarter; would automatically cause =whole to change. PRC On Tue, 7 Sep 2004, Michael Heuer wrote:
Hello,
Is there built-in support for time signatures, or should I just be doing something like
400::ms => dur q; 4::q => dur w;
2::w => now; while (true) { q => now; ... }
It would be nice to be able to write a file or shred using time-signature based durations and be able to change the values of those durations from somewhere else, effectively changing the BPM of everything you may have running simultaneously.
michael
_______________________________________________ chuck mailing list chuck@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck
That would be quite helpful. Is it possible to share data across shreds? With this I could fully implement what I had in mind, say create several shreds for various `instruments' and then having a controller shred that could vary the BPM of what all of the instrument shreds were doing. michael On Tue, 7 Sep 2004, Perry R Cook wrote:
Gary and I have talked about this. Actually coming up with a semantic to assign new types relative to others, and having them automatically update when the root types are changed. Something like:
100 ms => dur quarter; 4*quarter => dur =whole; // some semantic i forgot now
50 ms => quarter;
would automatically cause =whole to change.
PRC
On Tue, 7 Sep 2004, Michael Heuer wrote:
Hello,
Is there built-in support for time signatures, or should I just be doing something like
400::ms => dur q; 4::q => dur w;
2::w => now; while (true) { q => now; ... }
It would be nice to be able to write a file or shred using time-signature based durations and be able to change the values of those durations from somewhere else, effectively changing the BPM of everything you may have running simultaneously.
michael
_______________________________________________ chuck mailing list chuck@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck
_______________________________________________ chuck mailing list chuck@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck
You can spork new shred with a function call, which will launch a function of your choice. spork ~ myfunction ( args, args, args ); Any globals declared before that function is defined are available to subsequently sporked shreds - check out powerup.ck , or spork.ck, in examples spork away! On Tuesday, September 7, 2004, at 09:07 PM, Michael Heuer wrote:
That would be quite helpful.
Is it possible to share data across shreds? With this I could fully implement what I had in mind, say create several shreds for various `instruments' and then having a controller shred that could vary the BPM of what all of the instrument shreds were doing.
michael
On Tue, 7 Sep 2004, Perry R Cook wrote:
Gary and I have talked about this. Actually coming up with a semantic to assign new types relative to others, and having them automatically update when the root types are changed. Something like:
100 ms => dur quarter; 4*quarter => dur =whole; // some semantic i forgot now
50 ms => quarter;
would automatically cause =whole to change.
PRC
On Tue, 7 Sep 2004, Michael Heuer wrote:
Hello,
Is there built-in support for time signatures, or should I just be doing something like
400::ms => dur q; 4::q => dur w;
2::w => now; while (true) { q => now; ... }
It would be nice to be able to write a file or shred using time-signature based durations and be able to change the values of those durations from somewhere else, effectively changing the BPM of everything you may have running simultaneously.
michael
_______________________________________________ chuck mailing list chuck@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck
_______________________________________________ chuck mailing list chuck@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck
_______________________________________________ chuck mailing list chuck@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck
On Sep 7, 2004, at 9:07 PM, Michael Heuer wrote:
That would be quite helpful.
I think Perry and I came up with the syntax of: 100::ms => dur quarter; 4::<quarter> => dur whole; changing quarter would also affect whole. This is currently not implemented. It is (now) a high priority.
Is it possible to share data across shreds?
So far, it is possible only for shreds in the same source file to share global data. (see examples/wind2, mand-o-matic, moogie, or grep for 'spork') Soon (in the next major release), there will much more freedom in sharing data, using both global value maps, as well as static data of classes/namespaces/shreds. This is a very high priority. Most of this should be available later this month. Best, Ge!
On Tue, 7 Sep 2004, Perry R Cook wrote:
Gary and I have talked about this. Actually coming up with a semantic to assign new types relative to others, and having them automatically update when the root types are changed. Something like:
100 ms => dur quarter; 4*quarter => dur =whole; // some semantic i forgot now
50 ms => quarter;
would automatically cause =whole to change.
PRC
On Tue, 7 Sep 2004, Michael Heuer wrote:
Hello,
Is there built-in support for time signatures, or should I just be doing something like
400::ms => dur q; 4::q => dur w;
2::w => now; while (true) { q => now; ... }
It would be nice to be able to write a file or shred using time-signature based durations and be able to change the values of those durations from somewhere else, effectively changing the BPM of everything you may have running simultaneously.
michael
_______________________________________________ chuck mailing list chuck@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck
_______________________________________________ chuck mailing list chuck@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck
_______________________________________________ chuck mailing list chuck@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck
On Thu, 2 Sep 2004, Philip Davidson wrote:
there's a bug in that example.
sndbuf needs to have a non-zero rate specified before it starts to play.
1.0 => buf.rate; will do the trick
.rate controls the playback speed, relative to the 'proper' speed of the file and it's set to 0 by default
Thank you, that did the trick.
the example has been updated in cvs.
Great.
that bug aside, i've noticed some issues with sndfile that i'm hoping to track down, so let me know if you find more errors
Will do, thanks for the quick response. michael
participants (4)
-
Ge Wang -
Michael Heuer -
Perry R Cook -
Philip Davidson