Peaks Crashing in Drum Mode

Steps to reproduce:

(1) Set all four knobs to their center positions
(2) Power up the Peaks
(3) If Split mode is on, turn it off
(4) Switch the Peaks to the Main Drum mode (LED not flashing)
(5) Turn the second knob all the way to the right (clockwise)
(6) Turn the third knob all the way to the right (clockwise)

After step 6, my Peaks has crashed. It does not respond to triggers nor button presses until power is cycled with at least one of the second or third knobs backed off from the full clockwise position. If the knobs remain in the full clockwise position when power is cycled, the Peaks starts in the crashed state.

Steps 5 and 6 may be transposed.

This behavior does not manifest in the FM Drum mode.

The installed firmware is built from a clone of the current (as of 9/11/2016) git repository.

Just given this a try and I can’t reproduce it, sorry.

Edit: Peaks V1.0 here

same problem here, but with an older version

Thank you for trying it out. Based on the information you provided, I reverted my Peaks’s firmware to the June 12 version*, and the issue could not be reproduced.

When I re-installed the newer August 21 version**, the issue re-appeared. Can anybody reproduce this with the newest firmware?

(*) Commit 8173ac5c57d7c2c8bb04bbedb6696414b75b4cd2
(****) Commit 6165129cd99416c762da3087594d9148e4c29222

I’ll have a look tomorrow…

Maybe the problem is in the file, in the member function BassDrum::ProcessSingleSample at the line:

lp_state_ += (resonator_output - lp_state_) * lp_coefficient_ >> 15;

The right-hand side gets calculated OK, but my Peaks seems to halt at the lp_state_ += whatever that stuff is.

I doubt the instruction above can cause a crash. Are you sure the crash did not occur in an ISR?

I did not manage to reproduce the problem, and I could reproduce only once the following bug - which is very probably related.

Maybe I’m missing something - another condition that makes it easier to reproduce?

I do have a correction of my previous description. In the “crashed” state, the Peaks does respond to triggers initiated via CV, but not via button. None of the buttons work until the power is cycled, but the drums can be triggered and heard at the output. So it appears that just the buttons stop working, and I’ll refer to this as a “lockup” instead of a “crash.”

> I doubt the instruction above can cause a crash.

I know, right? It’s just an assignment. If I just assign the right-hand side to an int32_t, there’s no problem. It even locks up with this code:

lp_state_ += (resonator_output - lp_state_) * lp_coefficient_ >> 15;
return 0;
/*int32_t output = lp_state_;
CLIP open paren output close paren; // dunno why the forum is messing with this line
return output;*/

If I put the return 0 ABOVE the lp_state_ ± line, then no lockup (but no drum, either, obviously). If I do this:

int32_t iv = (resonator_output - lp_state_) * lp_coefficient_ >> 15;
iv += 0; // just to keep the compiler happy by using iv (warnings are errors)
return 0;
/*lp_state += iv etc...*/

then also no lockup.

> Are you sure the crash did not occur in an ISR?

I’m ridiculously unsophisticated here. I compile the code with the makefile and transfer the wav file via afplay. So no, no ISR.

Anyway, don’t sweat this, certainly, if I’m the only one with the issue. I’ll mess around with it from time to time, and I’ll add any new information that I discover to this thread. Maybe I’ll pick up a JTAG some day (not for this problem, which I don’t consider a showstopper, but to speed up testing of my own Peaks modulators), and maybe I’ll get some useful debugging messages. Until then, thanks for your time.

Oh, you mean you got the information that the lp_state_ line was causing the crash just by editing it, not by actually using a JTAG debugger?

Then it might be that the extra code in the assignment is pushing the CPU use to the maximum (which means that the task generating the audio is still running, but is taking all the CPU for itself, with no CPU left for the UI task).

In which environment are you building this?

OSX 10.11

> Oh, you mean you got the information that the lp_state_ line was causing the crash just by
> editing it, not by actually using a JTAG debugger?

Correct. Yeah, it’s painstaking, but sometimes my curiosity goes off the rails.

Are you using the vagrant environment? If not, which arm gcc version?

I’m not using Vagrant.

arm-none-eabi-g++ (GNU Tools for ARM Embedded Processors) 4.8.4 20140725 (release) [ARM/embedded-4_8-branch revision 213147]

Ah, the answer is simple then… Peaks’ drum synthesis code is so close to filling up the CPU that small changes in compiler versions are enough to make the difference between 99.7% and 100.3% CPU used :slight_smile:

The “old” firmware (8173ac5c57d7c2c8bb04bbedb6696414b75b4cd2) does not do software offset compensation, the more recent does (6165129cd99416c762da3087594d9148e4c29222) - so the older version has more “margin” to tolerate variations in generated code efficiency.

To be on the safe side, stick with the exact same version I’m using for the production firmware, 4.5.2. Or try different optimizer flags.

I know it’s silly, but that’s what happens when I try to cram as many features as possible :slight_smile:

Huh, that’s interesting. And educational, thank you for explaining it.

I’m using the new firmware because I need the offset calibration for tuning my chromatic quantized sequencer. I value the calibration over the stability of the drums (and I can work around that issue*), so for now I’ll stick with that firmware and review the optimizer flags when I have time.

(*) Simply limiting the values in set_punch() and set_tone() doesn’t seem to help anything, for some reason, so my work-around is “don’t cause the problem.”

I just disabled the high hats in my fork, and everything’s fine now, except for the lack of high hats.

In DMC, I ended up having to run the randomised hi-hats at half the sample rate, to prevent crashes. The original hi-hats are still there, at full sample rate.

Ah, great idea, I appreciate the tip!