Limiter overshooting with large numbers

[dkmayer]

SC 3.11.1 on OS 10.15

Limiter doesn't suppress single peaks with sudden large numbers. The help file is a bit misleading in this regard as it says: "Limiter will not overshoot like Compander"

// two peaks

{ Limiter.ar(SinOsc.ar(100, 0, 2 ** 30), 0.01) }.plot(0.05)

{ Limiter.ar(SinOsc.ar(100, 0, 2 ** 30), 0.01) }.plot(1)

The second plot might suggest that it could be an init time issue, but it isn't:

{ Limiter.ar(LFPulse.ar(10, mul: 2 ** 30), 0.01) }.plot(1)

The same behaviour can be observed with Normalizer.

Daniel

[capital-G]

I started looking at this.

Limiter is just a 1:1 name-wrapper for Normalizer which contradicts the credo

There should be one-- and preferably only one --obvious way to do it.

of another big programming language. Another not so nice thing about this is that there are docs for each of this functions although they are the same. But back to topic:

Interestingly, there is a Limiter Ugen which is probably never used.
The naive idea to simply switch the Limiter to its designated UGen did not fix the bug - but this is no suprise as both UGen look quite similar.

There is probably some kind of bug in the calculation of the slope which is applied here as

supercollider/server/plugins/FilterUGens.cpp

Lines 3348 to 3349 in f279c02

	LOOP(nsmps, ZXP(xinbuf) = val = ZXP(in); ZXP(out) = level * ZXP(xoutbuf); level += slope;
	val = std::abs(val); if (val > curmaxval) curmaxval = val;);

but its my first look at a Ugen so I still need some time to figure out whats going on exactly.

[joshpar]

Limiter is not a wrapper - it just inherits the methods from Normalizer. ^this.multiNew('audio', in, level, dur) Connects to the different underlying UGen C code. Both just have the same arguments and names. Hope that helps. Josh

…

On Dec 3, 2020, at 17:12, capital-G ***@***.***> wrote: I started looking at this. Limiter is just a 1:1 name-wrapper for Normalizer <https://github.com/supercollider/supercollider/blob/f279c025288d404b48bdc375d5477b8b19a6f772/SCClassLibrary/Common/Audio/Compander.sc#L40> which contradicts the credo <https://www.python.org/dev/peps/pep-0020/> There should be one-- and preferably only one --obvious way to do it. of another big programming language. Another not so nice thing about this is that there are docs for each of this functions although they are the same. But back to topic: Interestingly, there is a Limiter Ugen <https://github.com/supercollider/supercollider/blob/f279c025288d404b48bdc375d5477b8b19a6f772/server/plugins/FilterUGens.cpp#L3388> which is probably never used. The naive idea to simply switch the Limiter to its designated UGen did not fix the bug - but this is no suprise as both UGen look quite similar. There is probably some kind of bug in the calculation of the slope which is applied here as https://github.com/supercollider/supercollider/blob/f279c025288d404b48bdc375d5477b8b19a6f772/server/plugins/FilterUGens.cpp#L3348-L3349 <https://github.com/supercollider/supercollider/blob/f279c025288d404b48bdc375d5477b8b19a6f772/server/plugins/FilterUGens.cpp#L3348-L3349> but its my first look at a Ugen so I still need some time to figure out whats going on exactly. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#5274 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAANHLHOCID7CQ7SZMK6YJ3STAZQBANCNFSM4UJWTGQQ>.

[telephon]

To extend josh's explanation: there is code in sclang that is just an interface code. Some few cases of this you'll find in methods whose body is replaced by a more efficient version by the interpreter. But UGens are always just names that are used to build a SynthDef which specifies hoe the scsynth builds its graph.

Btw. SuperCollider does explicitly not follow that particular line in the python credo. If I tried to formulate a counter-line: there should always be several obvious ways to do something (In order to be able to do things right, you have to have several ways to do the same thing).

For good or bad!