Peaks firmware update, release candidate


This is for sure. I did this from not reading the warnings thoroughly enough, and now have one Peaks with DMC on it that I can’t calibrate. Even if I did go back to factory, I still can’t figure out the calibration procedure. Don’t be like me. Luckily I was planning on 2 peaks in my skiff anyway so one is factory one is DMC with a slight bleed. I’m happy about it but as most probably know, BE AWARE!


I have been wondering for some time if there’s something like a trigger to gate module. I can do that using some other modules but a dedicated 2HP module would be handy…


Any idea if i can use the DMC with a Peaks V.3 now ?


The Doepfer A-162 Dual Trigger Delay can lengthen triggers to gates of up to 10 seconds:

You can also lengthen a trigger under voltage control via the A-142:


The DMC code has been updated but ithe changes are still being reviewed and tested.


Any news ?
Do you think i can install it without
having problems ?


Blockquote[quote=“panamuse, post:21, topic:8463”]
Even if I did go back to factory, I still can’t figure out the calibration procedure.

Is it not possible to install original fw? I was sort of thinking I would go back to MI fw, unknown module version of Peaks.


It is completely possible. If you have no bleed post DMC, then I can’t imagine you would need to calibrate the module. I went to DMC with a V3 Peaks (no trimpots) without understanding the warning, experienced slight voltage bleed, and then reverted to factory firmware and still failed to understand the calibration procedure. I intended to have 2 Peaks in my skiff anyhow, so I reloaded DMC on the V3 Peaks, and purchased another stock Peaks.


never mind. I was totally tripping

or maybe not. I’m confused now :grimacing:

(hey @pichenettes

I just updated my peaks and I encounter an odd behavior.

I’m in expert mode with the alternative drum on channel one and the usual drum on channe two.


  1. program an huge kick with channel one
  2. go to channel two to program a hi-hat
  3. go back to channel one and don’t move knob 3 + 4
  4. power cycle the case
  5. result : the channel one (alt. drum) get the values from the knob 3 and 4 from the hi-hat)


so yes, it appears that the module will take the values from the position of the 4 knobs when it starts, even if they were programmed in another channel


Am I the only one with this issue? Should I re-install the firmware ?


The answer to this question is always no. Unless the module does not power on, there’s no problem that reinstalling the firmware will solve.

I’m just back from vacations, I’ll dig through the orders/support request/emails pile throughout the next two weeks.


Hi, did you have a chance to check my issue?



I could reproduce it but I don’t categorize it as a bug. Let me explain you why…

So yes, what happens is that when the module is powered on, it rescans the 4 knobs and use their current position to set the parameters of the sound.

To make things work the way you want them to work, the module would have to save somewhere that (following your example) knobs 3 and 4 are not currently matching channel 1’s settings, and that, instead “invisible” values should be used.

There are two options:

  • Save this information when you press the button to go back to channel 1, and cancel it as soon as knob 3 and 4 are touched. The problem is that saving data freezes the processor for about 1s, so there’ll be a 1s glitch when turning the knob.
  • Use a time machine to predict when the case will be switched off, so we can save the information one second before.

Note that there’s another problem to be addresses: what if the knobs are turned while the module is switched off? To solve this, the module should be able to compare the position of the knobs before it is switched off, and when it is switched on again, something which has the same implications (either we continuously write the position, with the audio glitch and the flash memory rapidly filling… or we anticipate the power off event).

So I’m afraid there’s no fix. The expert mode comes with limitations (that are commensurable with the inconvenience of not being able to see the state of the module). I should simply have said no to people asking me for an “expert mode”.



Thanks for your answer.

The reason I though this was a bug is that I never noticed this behavior with the stock firmware.

I’m sorry if you thought that I was complaining about something lacking or that I had another feature request.

I can assure you that the expert mode is great and totally reliable the way it is.

I don’t think you should have said no to the expert mode request. But that’s my opinion.


I checked the code and confirm that in the previous version of the firmware, Peaks did not rescan the pots when powered on.

This caused another bug (reported on this forum I think)…

  1. Enable expert mode.
  2. Program some settings on channel 1.
  3. Switch to channel 2… hooray, settings from channel 1 are saved in memory!
  4. Change the position of the knobs.
  5. Move back to channel 1, and change the settings.
  6. Power off the module.
  7. Power on the module… The settings are restored from step 2, but the changes done at step 5 have not been saved anywhere.

Again, there is no solution to this because we either need to save continually, or anticipate that the module will be powered off - both impossible.

I thought that realigning the sound of the active channel with the position of all the knobs when the module is powered on would be a more acceptable behaviour.


Some modules/synths have a key combination that saves the current settings. Not ideal of course.


It is totally fine. Thanks for checking though.


I think a good tradeoff could be to store the settings after a certain time of inactivity. Let’s say after one minute without a change in the knobs position. If the knobs are tweaked continuously, the settings could be stored every five minutes.

Let’s assume the worst case: The musician touches the knobs once ever minute. The rig is on 8h a day, 365 days a year. That would be 175k write cycles per year. Acceptable? Maybe.


Doesn’t really work… Say you’re using Peaks as an LFO… You do your settings, then let the LFO running… And blam! after one minute of inactivity, the module saves the settings and your LFO waveform has a glitch.