Steady climbing CPU

Questions
1

I’m a novice.
I’m having the patch maxing all the CPU after 5.5 minutes.
I think it’s this SynthDef, specifically the CombL . I thought it might also be the envelope.


(
SynthDef(\b, {
	var sig = PlayBuf.ar(1, \buf.ir(0), \rate.ir(1))/4;
		sig = Pan2.ar(sig, \pan.ir(0), \amp.ir(0.5));
		sig = sig*Env.perc(\atk.ir(0.001), \rel.ir(1.0)).ar(2);
	Out.ar(\out.ir(0), [sig*0.4, CombL.ar(sig, 2.0, 0.25, 0.25, 0.8)]*1.5);
}).add;
)
2

Hm, AFAICS the envelope should always release each synth, unless you set a very very long rel time.

CombL cannot override the envelope’s doneAction.

Maybe it’s a different SynthDef?

Btw because the code block is not properly formatted as a code block, it’s a bit mangled – please enclose in triple-backticks:

```
your code here
```

You can edit the post yourself (better), or a moderator can do it for you.

hjh

3

There seems to be missing an operator, probably * here: sig0.4. As is the synthdef does not compile, so my guess is that you are seeing the result of an earlier version of the synthdef

1 Like
4

I believe this is the result of posting code without using code tags – asterisks may be taken as italics tags and cause multiplication operators to get swallowed, which then causes confusion and delays a successful resolution.

I’m quite sure the operator is there in the original code.

hjh

5

Okay thanks,
The reason I thought it’s CombL on the sequence of sample buffers Is because when I take out CombL the pattern plays without the CPU maxing out. Also one of the samples produces a clip or click in the CombL sound.
I should mention I’m on a windows machine.

The gui shows It starting out with 1000 ugens and after 5 minutes running it says 9000 ugens.

6

Can you explain a bit more what you mean by “CPU maxing out”?

At the moment when the problem occurs, what are the numbers in the server status bar (bottom of the editor window), e.g. “2.07% 2.05% 0u 0s 2g” and the others don’t matter?

The reason why I’m asking is that, based on the SynthDef, I don’t see how it’s possible to max out the CPU except by creating massive numbers of synths in a very short time, or by extending the rel time to an extremely long value, like minutes. So there are a couple of possibilities at this point.

  • One is, maybe you really are creating a huge number of overlapping synths. This is hard to analyze at this time because you haven’t shared the code that is playing the synths. Can you please share that?
  • Another is, maybe the problem is not CPU-related at all – could be something else. We can’t be sure because we don’t know exactly what you’re running. (For instance, it could be about memory allocation for the comb delay. You’re allocating 2 seconds per delay, but only using 0.25 sec = 87.5% wasted memory. Those 2 seconds will use a half meg per comb instance. If you use the server’s default memSize for real-time memory = 8 MB, then you can have at most 16 simultaneous synths. If your synths are overlapping more than this, then the comb filters will eventually go silent for a lack of real-time memory. You might then interpret that as a CPU overload. There’s a lot about your scenario that you haven’t shared, so I just want to cover all the bases here.)

Also one of the samples produces a clip or click in the CombL sound.

This is expected because the output volume of the comb filter is not under control of the synth’s main envelope. You have an envelope for the source going into the comb effect. The comb filter will ring longer, and it’s being abruptly cut off by the envelope.

Maybe you’re thinking more like this?

(
SynthDef(\b, {
	var sig = PlayBuf.ar(1, \buf.ir(0), \rate.ir(1))/4;
	sig = Pan2.ar(sig, \pan.ir(0), \amp.ir(0.5));
	// NOT ar(2) for the source of a ringing effect
	sig = sig * Env.perc(\srcAtk.ir(0.001), \srcRel.ir(0.2)).ar(0);
	sig = [sig * 0.4, CombL.ar(sig, 2.0, 0.25, 0.25, 0.8)];
	// then, a main envelope controlling all of the final output volume
	sig = sig * Env.perc(\atk.kr(0.01), \rel.kr(1)).ar(2);
	Out.ar(\out.ir(0), *1.5);
}).add;
)

The gui shows It starting out with 1000 ugens and after 5 minutes running it says 9000 ugens.

You’re possibly misreading synth node IDs as UGen counts. The server starts creating new nodes with ID = 1000 – this does not mean that 1000 UGens exist. If you go on to play 8000 synths, then node IDs will go up to 9000. Node IDs don’t go down – but, as older synths terminate, their UGens are removed. So the total count of UGens should fluctuate slightly but – with that Env().ar(2) – they should not accumulate.

Again, it’s hard to know exactly what you mean – you say “the gui” but which gui? I can guess that it might be “show node tree” but this is showing IDs and not UGen counts – so what you see in this window is not directly relevant to current CPU usage.

hjh

7

Thanks!
Your initial observation is correct. It was another Synthdef’s Envelope without doneAction:2. I must have created it at the same time and not noticed.

Your rewrite for the signal path for the CombL makes a lot more sense to have it before the Envelope.

Thanks again!