[chuck-users] Question about Gain and instantiating objects

[Mike McGonagle]

On 1/14/06, Graham Percival <gpermus at gmail.com> wrote:
>
> 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 at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>


--
Help the Environment, Plant a Bush back in Texas!