Issues with adding u-gen , dc offset

1

I am adding a saw + square into a moog filter an envelope controlling fequency and mouseY controlling resonance , problem is that the output is still having a lot of dc bias , despite the fact that I subtracted a value of 0.5 for the moog filter last argument …
This is the code ( play with the mouse Y and see the bias increase )

({MoogLadder.ar
(Saw.ar(120,1,0.4)+Saw.ar(122,1,0.4),Line.kr(10000,100,10),MouseY.kr(0,1),1,-0.5)}
.play)
The two saw osc’s have moderate levels of 0.4 each

Is there a better way to to achieve adding two signals . ?
And how to post code ?

2

Also I would like to know how to show up the arguments at any time , afaik it only works when opening the parentheses for the first time +tab
Is there a way to re-show the arguments ?

Cheers

3

This is one of those details… SinOsc takes inputs “freq, phase, mul, add” and Pulse takes “freq, pulseWidth, mul, add”… but Saw takes “freq, mul, add.”

Because of the lack of a second input before mul, in fact you have mul = 1 and add = 0.4 – the DC offset is coming from the nonzero add.

There’s a thread somewhere on the forum suggesting to avoid using mul and add, instead writing Saw.ar(100) * 0.4 – which will work transparently with any UGen, no matter how many inputs. Lately I’ve shifted my coding style in this direction.

Agreed that this is an easy trap to fall into – I’ve been caught out by the same thing more than once.

There’s a keystroke for it but it depends on the OS. What system are you using?

hjh

4

for inline code, like this, surround your text with backticks: `like this`

for multi-line code snippets:

like
this

place triple backticks (```) one the lines above and below the code:

```
like
this
```

5

I don’t understand why you’re pointing out the different arguments for sine, saw etc…
I have only used the relevant arguments for saw , namely frequency and mul :which used a constant of 1 and add to subtract some dc ( constant ), afaik I don’t do anything wrong here

I agree with the rest , amplitude modulation for example can be achieved by multiplying 2 ugens
Example
({SinOsc.ar(freq:220,mul:1)*SinOsc.ar(freq:112,mul:1)}.play)

, but also using an U-gen as the mul argument in another (nested so to speak )
({SinOsc.ar(freq:220,mul:SinOsc.ar(freq:112,mul:1))}.play)

Are you implying that the second method is to be avoided, and not used nested U-gens to control certain arguments ?

I am sorry but saw can be added or subtracted a constant .
When I add a negative value to the add argument it will subtract a constant signal from it (
Saw is by default bipolar , so adding 0.5 in add argument will make it a unipolar saw with positive energy
only
Same when I insert a negato=ve value in the add argument , it will subtract this çonstant from the saw and give a unipolar saw with negative energy only
I may be a beginner in supercollider , but have been doing reaktor core for 10 years , si I do know some basic stuff
If you don’t believe me , here 's the code
{Saw.ar(100,add:0)}.play///default =bipolar saw
{Saw.ar(100,add:0.5)}.play//adding 0.5==unipolar ramp , positive energy only
{Saw.ar(100,add:-0.5)}.play//subtracting value 0.5 unipolar ramp , negative energy only

Untitled-1
Untitled-11019×767 237 KB

6

Saw doesn’t have a DC offset of -0.4, so using 0.4 for add will produce, not remove, DC offset.

But… this thread started with:

Saw.ar(120,1,0.4)+Saw.ar(122,1,0.4)
…
The two saw osc’s have moderate levels of 0.4 each

So I guessed that you believed it was mul=0.4 here. It isn’t: as your code is written, both Saws have mul=1 and add=0.4.

So I guessed further that you had seen other oscillators like SinOsc and Pulse, which have arguments freq and one other before mul, and extrapolated from this that Saw might follow the same pattern (it doesn’t). That’s why I mentioned them.

Anyway, the upshot is that you’re adding a total DC offset of 0.8 and then subtracting only 0.5, which still leaves a nonzero DC offset.

I would suggest to avoid DC offset here by simply not adding it in the first place.

({MoogLadder.ar
(Saw.ar(120,0.4)+Saw.ar(122,0.4),Line.kr(10000,100,10),MouseY.kr(0,1))}
.play)

If all else fails, LeakDC will remove DC offset after the fact. I use this unit fairly often. (Or, HPF with a cutoff of, say, 10 will also remove DC.)

Not necessarily. The point is that there’s no strong advantage of using mul (there might have been, two decades ago, but not now) – but using mul does open up the risk of getting the position wrong as in your Saw example. It’s not wrong to use mul, but * may be clearer and more resistant to mistakes.

hjh

7

I am sorry but saw can be added or subtracted a constant .
When I add a negative value to the add argument it will subtract a constant signal from it (
Saw is by default bipolar , so adding 0.5 in add argument will make it a unipolar saw with positive energy
only
Same when I insert a negato=ve value in the add argument , it will subtract this çonstant from the saw and give a unipolar saw with negative energy only
I may be a beginner in supercollider , but have been doing reaktor core for 10 years , si I do know some basic stuff
If you don’t believe me , here 's the code
{Saw.ar(100,add:0)}.play///default =bipolar saw
{Saw.ar(100,add:0.5)}.play//adding 0.5==unipolar ramp , positive energy only
{Saw.ar(100,add:-0.5)}.play//subtracting value 0.5 unipolar ramp , negative energy only

Untitled-1
Untitled-11019×767 237 KB

And some plots
2
21019×767 106 KB

8

for whatever reason Saw.ar produces waveform in range -0.5,0.5.

But SinOsc range is -1,1

rather than using the add: param I like to call the .unipolar method when necessary

{SinOsc.ar(20).unipolar} will produce only values >= 0

the best way for a cutoff param though is to call the .range method

SinOsc.ar(20).range(100,1000) will produce output in the range 100,1000

also try .exprange when you want the range to be scaled

9

Maybe there’s a language issue here but in English, “I’m sorry but…” carries a meaning of “you’re wrong.” I don’t understand how that applies to my response to your initial question.

You asked “problem is that the output is still having a lot of dc bias” – that is, where is the DC offset coming from and how to remove it? Which I explained.

Now you’re saying “but look, I can make DC offset!”

I find that a bit… confusing…? That post is at an exact opposite purpose from the initial question.

hjh