On Tue, 2008-08-05 at 15:23 -0400, Martin Peach wrote:
Roman Haefeli wrote:
On Tue, 2008-08-05 at 14:19 -0400, Martin Peach wrote:
Frank Barknecht wrote:
For example as in the attachment.
Interesting playing with that...If you give the osc~ a gain of 100dB, which dbtorms translates to a gain of 1, then [env~] outputs 96.99dB and the vu meter -3dB. To get 0dB on the meter you need to give 103dB to the osc~, a gain of 1.413. My onboard soundcard starts clipping with the vu meter at -3dB, so a gain of 1 on an osc~ is the maximum the hardware can handle. That is, maximum gain allowed by the hardware is 100dB ("sound pressure level"), 1 ("full scale"), or -3dB (why not 0dB?). Why does env~ give an output that is 3dB less than, or 1/2 of, its input?
i think (correct me, if i am wrong) this is dependent on the crest factor of the signal:
http://en.wikipedia.org/wiki/Crest_factor
altough, the peak of the sine is 1, -1 respectively, the average (that is what [env~] gives you) is lower, 3dB to be exactly. try the same with a square wave and the result should pretty much be 0dB, respectively 100dB.
Yes, that makes sense. That's why in analog equipment you try to stay around -3dB instead of 0dB because the peaks are at 0dB. In analog you can go above 0dB with progressively reduced gain, but in digital equipment you get hard clipping at exactly 0dB, so it's nice to know when it's happening. [env~] will give different output depending on the waveform it's measuring, so it's not too useful for determining if overload is occurring. Maybe [peak~] from flib is appropriate for that, but it seems to involve doing an fft so it may be computationally heavy. I'm still not able to instantiate [>~] from zexy...
on extended? which version? from what i heard, extended-0.40-rc4 doesn't suffer anymore from this problem. [>~] from the multiclass library should work well, no matter what version.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de