How do I obtain final gain level for output?

[Dr. Spankenstein]

Is there a method for returning the gain level of the output of ChucK corresponding to all the Ugens that are a connected to the dac?

For example if I were to have...

[Kassen]

That's a very good question.

First of all; the dac doesn't know about the gains of attached Ugens, it only knows about the values it receives and sums. Because on ChucK's side of the dac the values are double-floats (which can get very large indeed) but on the soundcard side they will eventually need to be normal 16 bit integers (asuming you are using CD quality sound) this process may lead to clipping.

There is good news though; the dac has a .gain function. Since there is only one dac for the whole system adjusting this in one shred will affect the whole system. This is nice, when I'm livecoding I'll often have one MiniAudicle screen open saying just

0.8 => dac.gain;

(of course with different values for .8 it could also be 1.2 or so)

Think of this as a master fader.

Not sure if that answers the question but at least it's a useful trick.

You could also make a shred that sends the dac's output to a envelope follower,

dac => my_ugen;

will work, you see. Based on that envelope follower's output you could also adjust the dac's gain. There's a example envelope-follower by Perry Cook in the examples dir, I think in /deep

[Dr. Spankenstein]

Thanks for the clear info.

I've been looking into perhaps limiting the output so that it doesnt clip.

I can see how this could be done with the Dyno Ugen with one shred running but what if I were to have say 3 shreds running at the same time?

Would I have to create some kind of Public Class Dyno Ugen to connect them all to (before the dac) using a similar approach as the "dinky try" code in the examples/class folder?

Or is there an alternative method that is best suited for this kind of problem?

Thanks

Rhys

[Dr. Spankenstein]

Here's a simple non-working summary of what I've been trying to do..

[Kassen]

I'm no Dyno-expert. To be honest I tend to either use multiple outputs then mix the analogue way (shock! :¬) ) or simply turn the gains down manually...

But when I look at your code I'm fairly certain " Limiter.limit(); " would like some sort of parameter?

A public Dyno sounds to me like a good solution to your issue though the strategy I outlined above with the envelope follower may also have some strengths. It'll be slower in response but could be added to any situation without code changes to the rest. If you don't try it I'll build it myself some time (just not now :¬) ).

[Dr. Spankenstein]

[moudi]

the handling with "public ugens" is a bit tricky at the moment.
if you want to use the same ugen from multiple shreds, you need to define a static ugen in your class.
so, declaring a static ugen is no problem in a class, but you can't instantiate it directly (a nice exception appears that this is not supported for now).
therefore you need to instantiate this public ugen within a shred.
this shred must be running the whole time you want to access this ugen, otherwise you'll get a null pointer exception.
(this means the instance of the public ugen gets disposed when the shred which has created the new instance is finished)

a short example could look like this....
please pay attention that this is written on the fly in this message and not tested in chuck!!

[Dr. Spankenstein]

Very much so!

For those who might be interested, my working code now looks like this:

[moudi]

aahhhm...
in your code here:

[Dr. Spankenstein]

O.K. I think I understand but how would this work with something simple like an integer?

For example if I were to have the Public Class in a seperate Shred on an infinite loop how could I reference it?

Code to be run:

[moudi]

Hi Rhys

first of all, a public class (with or without static data) gets loaded by a shred into the vm and is from this point on accessible for all shreds. (as long as the vm is running).

if you're in need for a static int (or all other kinds of primitive types) it's another case, because you're able to instanciate them directly in your class. the "hack" with the never ending shred is only needed, because you aren't able to instanciate static ugens directly in the class.

i made a little example (a master gain) for you:
1. load the MasterGain.ck
in this shred is only the public class. the shred will immediately terminate after you loaded it.
2. load the NeverendingShred.ck
in this shred, the public ugen will be initialised and the shred runs forever (as long the vm survives).
3. load Shred1.ck
there's a simple sine wave routed to the public ugen and played for 2 minutes.
4. load Shred2.ck
the gain value of the public ugen will be changed every 2 seconds

good luck
/moudi

---

MasterGain.zip
Description:		Download
Filename:	MasterGain.zip
Filesize:	672 Bytes
Downloaded:	16 Time(s)

---

[Dr. Spankenstein]

Thanks for taking the time to upload the Master Gain code moudi.

It has now been implemented into my code and works perfectly. Not only that, I understand how it works!

Rhys