Home | ER-101 | ER-102 | ER-301 | Wiki | Contact

Clicks...cpu 66%



yep - the moment the sample player gets a trigger, it changes from continuous to trigger mode.


hey brian, i could test the firmware today and sadly i wasn’t able to trigger the manual grain unit anymore except for the manual trigger, that still worked. however every other solution to trigger it didn’t work (sine osc, taptempo, external signals). it seems that the grain unit is broken in this test firmware…
what i noticed is a lower cpu usage, when i monitored it it was at 56% for the exact same patch as before (at 66%), but maybe that was because of the not working grain unit.


Sorry about that @kilchhofer! :bow: There was a problem with the new bypass behavior when restoring from a preset containing a bypassed unit.

I believe you should be able to test with v0.2.15 (just released). I am hoping that the bolded items will address your issue.

v0.2.15 CHANGES

  • FIXED: In 6-track Recorder, saving a single track to a single file will fail if the destination file already exists.
  • FIXED: Possible float pointing exception (division by zero) in the Manual Grains unit when duration is zero.
  • FIXED: Pops would occasionally appear in IN1-4 and ABCD inputs at CPU loads above only 65%.
  • FIXED: Ladder Filter, Sine Osc, Aliasing Saw, and Aliasing Triangle units were not restoring f0 parameter from presets created prior to v0.2.12.
  • FIXED: Unable to re-enable a unit that was loaded from a preset in a disabled state.
  • FIXED: Display process was starved when loading quicksaves or presets.
  • FIXED: Unit control still focused when exiting from a subchain via UP button.
  • FIXED: Rational VCA was not rounding the numerator and denominator to the nearest integer since v0.2.14.


thanks @odevices!


Actually, don’t touch this one. Use v0.2.16 instead.


I’m getting pops and clicks on the outputs at around 60% load in the lastest 96kHz firmware.

Edit: Make that around 50%. :frowning_face: 0.3.05, BTW.


The CPU load screen is still just displaying loads sampled at 1Hz so there might be spikes that are not visible. If you have the time to describe in more detail the patch then I will of course be more than happy to investigate further.


Yeah, sorry for not being specific.

The patch is not too complicated, as I recall (I’m away from home, but I will double-check later). One chain with a clocked delay, reverb, and fixed HPF; one chain with a sample player, fixed HPF, and variable delay; one chain with a sample player; one with a sine oscillator. A smattering of ADSRs and linear VCAs – not sure of the exact count, roughly 10 of each across all chains.

CPU load appears to be pretty constant. Certainly the driving triggers are fairly steady. I started noticing the pops when I added a sine wave sub-bass. The pops are somewhat infrequent but very noticeable with such a signal.


I know you probably thought of this too but I will need to first rule out that the pops are not coming from the ADSR modulation of this low frequency sine wave. This can be simply done by disabling everything except for this part involving the sub-bass, or even better, just set the gain on the amplitude modulation to zero so that we are not changing the CPU usage. I’m using of course that you have a VCA+ADSR on the sine wave sub-bass.


I believe I have ruled out that possibility. Removing a somewhat expensive unit (such as the variable delay) eliminates the pops. Bringing the apparent load up to about 55-60% with a stress unit reintroduces them.

You are correct about the VCA+ADSR. There is also a pair of ADSRs modulating the pitch.

I won’t be able to test anything for a little bit. I’m away from home, and my laptop through which I monitor everything is out of commission.


That convinces me it is not VCA-induced popping. I’ll investigate and see what I can find.


This effective 60% CPU limit is really killing my buzz. I would gladly use 48kHz, but unfortunately I can’t tolerate the additional latency. I hate to keep harping on these issues, but they severely limit the usability of the ER-301 for me.


are you still on v0.2 or on v.0.3.x now?


i confirm clicks at over 60% on 0.3.18@96kHz.
I don’t care too much about latency so using 48kHz firmware here, and no clicks at about 90% (didn’t go futher up).


I’m on 0.3.17 currently.


I am experiencing pops around 60% CPU usage as well. What is the best way for me to communicate the patch that I am currently working with? i.e., should I just write it down or is there a way to export a snapshot of how things are configured?

It’s also good to know that it can be addressed by using the 48 kHz firmware. I understand the difference between 48 versus 96 kHz in general. Can someone let me know how this applies in this context? Is it just when recording audio? Does it impact sample playback?


Giving me your snapshot is not really necessary anymore because this is a known “issue” which is caused by an inadequate CPU load meter. The current CPU load meter measures the average load rather than peak load which is much better at predicting pops and clicks. In other words, your average CPU usage is 60% but the peak CPU usage is probably closer to 95%. I hope to replace the average CPU load with the peak CPU load soon.

The 48kHz vs 96kHz rates are describing how often the ER-301 computes a new value to output to the DAC. First and foremost impact is that the highest frequency that the ER-301 could generate is half of this rate (i.e. 24kHz or 48kHz, respectively). However, in practice there is often not much difference in listening quality especially in the modular context. Let your ears decide whether reduction in patch complexity is worth staying at 96kHz. Do a blind test on yourself with a favorite patch for example. In the end, it is going to be up to personal preference.


Thanks @odevices, super helpful as always.


It’s similar to DAW use… running at 96K is forcing the computer to work 2x as hard as 48k so generalizing: if you were able to run i.e.: 4 plugins at 48k, running the same plugins at 96k you’ll only be able to run 2 (at the same buffer setting).

From what i recall (and @odevices can confirm if this is correct) - the processing buffer on the 301 is a fixed size, so with that, latency will be lower at 96K but you won’t be able to run as much stuff (but still a lot!)

Honestly, unless you’re doing a ton of time stretching, 48K will give you more breathing room.