On 1/14/06, Graham Percival
On 13-Jan-06, at 11:33 AM, Mike McGonagle wrote:
chuck sinegrain sgtest1 rec-auto
I've found that recording things in chuck is quite expensive (computationally), so I would first try it without recording. And I certainly wouldn't have four different recordings going on at once; I've find some way to only have one thread recording everything.
While I am not really trying to get this to be a "real-time" program, everything seems to work as I expect when I changed from using an Object for this, and instead used a function, and "sporked" multiple instances of that function. I also tried doing this without recording, and the results sounded pretty much the same. I wonder if this has something to do with how Objects are implemented, but that is just a hunch... While I can understand why each of the Objects continued to generate a wave after it was supposed to be done, the gain issue still doesn't make any sense. I can upload the revised code that uses a function instead of an Object, if anyone is interested. Also, you mentioned something to the effect of "four different recordings going on at once". I know that I created four different threads (in one example) which "chuck" their output to the dac, but I assumed that the recording code takes its source from the dac, which I would assume would be a summed result from all the other objects sending their output to the dac. About the recording code from the ChucK examples, would I need to modify that code for it to write a stereo file? My code, when I listen to it directly, it is stereo, but the resulting audio file is only mono.
I did this in Pure Data, but I had to create it in such a way that there were already all the generators instantiated, so if there ever occured a moment where one more generator was needed that created, it would "steal" a generator. This occasionally produced some clicks in the resulting sound.
I did a similar thing (in chuck) using fifteen generators. In my case I had new generators wait until one was free, instead of stealing it... but you can avoid the clicks if you can give the generator a few ms notice before stealing it. When you notify a generator, have it do a fade-out, then start the new info.
And this seems to NOT be a problem when I spork a new function thread. As I pointed out earlier, I am not really concerned with it running in realtime, as I expect there to be hundreds of threads running at once (at least that is the extreme possibility). I also have several control threads that will be running (I think somewhere on the order of about 32-40 or so. These are used to control the parameters for masking objects, and for each mask, there will be at least 4 threads running.
Will I need to create an "array" of my objects, creating all the instances that I may need? Or should I be able to create an object, call its function, and call its function by sporking it, and then instatiate a new object using the same object reference?
sporking is relatively expensive. When I tried to do my project (with 1.2.0.2, I believe), I ran out of CPU when I have five generators going. With an array of objects (using whatever I wanted up to the array size), I could do something like fifteen or eighteen generators.
I am expecting to drop out of realtime on this, so this should not be a problem.
Since chuck is so new, it's not very optimized.
Yeah, I can tell that it is relatively new, at the same time, what is here is very impressive. I really like the idea of being able to "cascade" a bunch of functions together, it works really well for the masking code. I was working with these things in SAOL, and everything was kind off hard to follow after there were 4 or 5 functions that are used to modify parameters. It went from being... result = accum(offset(quantizer(mask(invert(sig_gen()))))); to... sig_gen() => invert.act => mask.act => quantizer.act => offset.act => accum.act => result; While there may be more characters that need to be typed, I think the maintainability of the "ChucK" code is far more understandable. Thanks, Mike McGonagle
Cheers, - Graham Percival
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- Help the Environment, Plant a Bush back in Texas!