Forums > MaxMSP

omx.comp~ for noise gate… can't find the magic words

June 20, 2011 | 5:51 am

Is anyone successfully using omx.comp~ for noise gating?

A forum search revealed http://cycling74.com/forums/topic.php?id=26004 and this points to http://www.cycling74.com/docs/max5/tutorials/msp-tut/mspindex.html — many compression tutorials, and some mention of gating, but I don’t see anything explaining why the following appears to have no effect on the mic input at all, regardless of the gate threshold.

– Pasted Max Patch, click to expand. –

I’m fairly sure I’m reading the omx.comp~ reference correctly — to set the threshold, I should send (ngThreshold dB), where dB is a positive number that will be negated for the actual threshold.

[number] –> [prepend ngThreshold] –> [omx.comp~]

Right??

I’m initializing [omx.comp~] with [loadbang] –> (agcEnabled 0, limEnabled 0, ngEnabled 1).

(Just for giggles, I also tried negative dB, also no effect on the sound.) I would have expected, for instance, if the incoming peak is -40 dB and my threshold is -2 dB, according to the reference, the output signal should be -2 – (2 * (40-2)) == -78 dB.

By contrast, the equivalent setting in SuperCollider’s Compander ugen does produce a gain reduction by a factor of two for signals below the threshold.

Compander.ar(sig, sig, thresh: -2.dbamp, slopeBelow: 2, slopeAbove: 1, clampTime: 0.01, relaxTime: 0.1);

What am I missing?


June 20, 2011 | 11:21 am

omx uses an arbitrary scale of 0 to 100 for its values which are interpreted by the object according to the variable they represent, so the actual values in dB come out the third outlet, after much routing and faffing about

have a look at the help file in the subpatcher [p params_and_messages] for how it works

I’ve adjusted your patch so you can see how the 0-100 scale is translated to dB

In my mind it is a very confusing object to use with a rather arcane approach to its implementation

– Pasted Max Patch, click to expand. –

June 20, 2011 | 11:59 am

I got it to work fairly handy. I selected downward enable and set the expansion threshold to very high and it worked. Just 2 controls.

– Pasted Max Patch, click to expand. –

June 21, 2011 | 2:15 am

omx uses an arbitrary scale of 0 to 100 for its values which are interpreted by the object according to the variable they represent, so the actual values in dB come out the third outlet, after much routing and faffing about
…snip…
In my mind it is a very confusing object to use with a rather arcane approach to its implementation

That. Is. Insane.

I may have to take the documentation’s other advice and use a vst~ that works intuitively.

I checked it out and there is some gain reduction, but not as much as I hoped. If I set the threshold appropriately for the incoming signal, there is almost no noise gating at all! Threshold at 0 dB = 100 omx-wacko-units makes -22 dB at the input become about -33 dB at the output. In SC, it works more like standard companders.

a = {
	var	sig22db = SinOsc.ar(440, 0, -22.dbamp),
		comp = Compander.ar(sig22db, sig22db, thresh: 0.dbamp, slopeBelow: 2),
		// wait, to let Compander clamp down before printing
		printTrig = Impulse.ar(1, phase: 0.01),
		// like [peakamp~ 100]
		peaks = Peak.ar([sig22db, comp], trig: Impulse.ar(10));
	peaks.ampdb.poll(printTrig);
	FreeSelf.kr(Trig1.ar(printTrig, ControlDur.ir));
	0  // calculate only, no audio output
}.play;

UGen Array [0]: -22
UGen Array [1]: -45.1296 // -23 dB below threshold, gain reduction *2

But as long as there is vst~, Cycling ’74 have an excuse not to implement a proper compressor…

:-p

James


June 21, 2011 | 8:38 am

Solution: [vst~] + "mda Dynamics.dll"

omx.comp~ = not. impressive. 2:1 downward expansion was just not enough.


Viewing 5 posts - 1 through 5 (of 5 total)