Dead Man's Catch modified firmware for Peaks
  • I have released Dead Man’s Catch v0.7-beta for testing by anyone interested and game enough to play with it. As far as I can determine, it works as described in the release notes, and doesn’t seem to crash or lock up the module as sometimes happened with some of the previous releases.

    All the usual warnings apply! This is beta code, and although I have tested it carefully (see also discussion of re-installtion of factory Peaks firmware here and here), you install it at your own risk. That said, the risk of you bricking your Peaks by installing it is fairly small, and your Peaks can always be recovered by re-flashing firmware via the FTDI serial or JTAG/SWD interfaces – but both of those procedures require suitable programming adaptors.

    Note that Olivier Gillet and Mutable Instruments does not provide support for modified firmware and do not provide an unblocking or recovery service for failed firmware installations involving modified firmware such as Dead Man’s Catch.

    Full details, installation details, and downloads of the WAV audio firmware update file, can be found at

    Reports of successful installations, and feedback are welcome in this thread. More features will be added to Dead Man’s Catch in due course.

  • Here we go!

  • Cool! I just may have to give this a try!

  • “Note that Olivier Gillet and Mutable Instruments does not provide support for modified firmware and do not provide an unblocking or recovery service for failed firmware installations involving modified firmware such as Dead Man’s Catch”...

    Who does? Is there anyone who could restore a module back to factory if something goes awry?

  • Ehm, what do you expect ?
    Why should Olivier take responsibilty for someone tampering with firmware code ?
    If you brick it by any means not related to his supported firmware, it is up to you to fix it…

  • Funny how people expect someone to be responsible if their experiments go wrong. Installed Dead Man’s Catch, works great!

  • Adam> Who does? Is there anyone who could restore a module back to factory if something goes awry?

    Re-flashing the firmware from scratch is easy, and it is a well documented process, but requires a readily available $20 FTDI adaptor. Lots of people are or would be able to do it. One person in North American and one person in Europe (as well as me here in Australia) have agreed to offer a service to do just that, for a very modest fee, should anyone brick their Braids while install Bees-in-the-Trees modified firmware (there details are on the Bees-in-the-Trees/Mutated Mutable web page). No-one has requested those services to date. I’m sure they would be happy to offer the same service for Peaks. However, at this stage, if you don’t feel confident about refreshing your module yourself, then it might be better not to install Dead Man’s Catch. Wait a few months.

  • @Bennelong Fabulous – I’m going to install this tonight and have a play – been looking forward to seeing what you’d come up with for this module!

  • v0.2 just unlocks the bouncing ball that Olivier put in the code from the outset. v0.3 will introduce a brand new capability, though, but no timetable for it at this stage.

  • Fabulous! I never had the time to get to start working on that (already coding too much at work), but did some notes… maybe they are inspirational enough such that someone … uhrm … likes them enough to implement them ;-P

    Anyway, here are the notes on my to do list, just curious about feedback/ a discussion:

    1) @Bennelong how are you planning on making the other modes accessible? I thought about using the fun and split buttons to navigate linearly through the banks of functions (indicated by X times led blinking). Simply using fun to go forward and cycle through the functions + banks and the combo fun + split to go backwards.

    2) use soft-takeover for the parameters when switching from one function/split back and forth.
    3) Instead of an attenuator for the tap lfo, attenuverting may be a tad more useful

    4) @Bennelong what have you planned as additional functions? On my list, apart from the boundinc ball is/was Euclid, an additional chaos source Brownian motion/Lorenz/... , something that creates
    deterministic melodies, in the vein of the Future Retro Zillion Sequencer (haven’t checked on Peak’s DAC yet – but there was some discussion about it, if i remember?).

    take care!


  • I was planning to leave the four basic functions and the means of accessing them, and the way they are indicated, untouched, so that the panel labelling and the official user manual remain valid. Likewise the four alternative functions. And then just add extra functions as fifth, sixth, seventh etc alternative modes, indicated by various patterns of two or more of the 4 function indicator LEDs being lit (blinking because you will be in alternative mode). I also thought of using binary numbers from 1 to 15, but that might be too nerdy, but is easy to try – but again, only for alternative mode.

    The other thing I thought of was special-purposing the Easter egg handshake, so that the triple-long-press-on-both-buttons drops you into an extended, persistent parameter set for the current function – so adding 4 more parameters for each function, which persist. The problem is how to indicate that the extended parameter setting mode is active. Maybe by inverting the blink pattern?

    I have ported the Turing Machine code which I added to Bees-in-the-Trees to Dead Man’s Catch, as the sixth alternative mode, and it works rather nicely, spitting out CVs. Those CVs aren’t quantised, and are probably subject to some thermal drift, and thus it really needs to be used in conjunction with a quantiser, or with a quantising oscillator, like Braids running standard or Bees-in-the-Trees firmware, if you want to use the CVs to play a semi-random melody. Of course, the Turing Machine feedback shift register paradigm is very simple, and only one of many ways of generating interesting melodies, but it is a good place to start, and there’s plenty of flash storage space and CPU cycles available in Peaks to allow further elaboration and experimentation. However, the very limited user interface on Peaks will limit what can be done. Implement a Triadex Muse (or FutureRetro Zillion) on Peaks might be a challenge (but the Triadex Muse is ideally suited for implementation on some other open-source eurorack platforms).

    Other ideas for Peaks I have had or which others have had and which I have recorded can be found here – if you use or build on any of the ideas recorded there, please attribute them appropriately. Git pull requests for Dead Man’s Catch are also welcome – I only have limited time to work on this stuff, alas.

  • Question: Any risk involved in installing alternate firmwares on top of one another? Let’s say I want to go from Dead Man’s Catch to the Peaks drums firmware in the other thread or vice versa….

    Is it suggested to fall back to the original Peaks firmware first and update from there or am I OK just swapping back and forth?

  • There’s a bit of risk of if both alternates are using the exact same changes to make their saves incompatible with the original firmware. Going back via the original probably won’t help directly until all the save pages get overwritten.

    @BennelongBicyclist are you both adding zeroed padding? From the other thread it seems “best practice” is now magic number with check on load.

  • Just an extra 4 bytes in the settings strict at this stage. I’ll add a magic byte in the next version. If the factory code can’t find any good settings, then it re-initialise the entire setting flash page, so should be OK.

  • I don’t think Steve Crichton has published his drum samples code, so not sure what he is doing.

  • I’m not doing anything too special… I replace the sample in the numbers station, then put the hit’s sample starts into the array at the top of the file to allow the randomiser know the beat starts. Then change the modulo amount where the randomiser is called to the number of items in the array.

    The rest is turning off the ringmod and distortion in numberstation. Removing the flashy sequence on the the LED’s. Then finally I removed the code that detects channel 1. It’s more a case of how much did I comment out. I’ll fire you over a zip so you can A laugh and B try to actually improve it if you wish :)

    I do know someone who bought a peaks today on the hearing the demo today so it is maybe enough of interest to merit further exploration with the window of randomness I want to implement when work calms down again.

  • @BennelongBicyclist: there seems to be a pretty nasty bug in v0.2: going through all the “normal” functions (env, lfo, tap, drum), whenever I pass “drum”, the module freezes completely (instead of going back to env). I have to reboot to make it functional again.

  • Hmmm, I’ll check that tomorrow. I’m sure I tested that, but maybe not.

    Edit: I’ve spotted where the problem is, and I may not have tested that path through the UI. Shall fix it tomorrow.

  • @mqtthiqs: I just arrived home and tried to replicate the bug, but I can’t, it seems to work fine on my Peaks. Can you provide a sequence of button presses from power-on to trigger the bug? What firmware was on the module before you installed DMC v0.2? Did you compile it yourself or install from the audio file?

  • I asked a beta tester running the released v0.2-beta code loaded via the audio file to try to reproduce the reported bug, but he couldn’t reproduce it either. However, I was able to reproduce it with bleeding edge code compiled from the latest check-ins to the GitHub repository. Yeah, don’t use that code yet, it’s bleeding edge and buggy v0.3 code, not yet complete. I forgot to create a branch before I started making v0.3 changes.

  • I used the wav file you provided. Unfortunately I’m leaving my modular today for a week and won’t have time to check it again (I reuploaded the stock firmware) but, if i remember correctly, I went into bouncing ball mode, then long pressed on the button to go back to the 4 main modes, then pressed it again until Drum. Then pressing it again once more froze the module completely.

  • I had always had the original firmware before yours.

  • Version 0.3-beta of Dead Man’s Catch now available – see

    v0.3-beta adds dual Turing Machine semi-random looping sequencers.

  • Hmm, now I finally need a Peaks …

  • Wow! That is a great additional feature. I look forward to your work on Streams. :)

  • @audiohoarder: if only I had a Streams… maybe one day.

    Speaking of Streams, given that Peaks is dual channel, some more dual-channel functions would make sense. The Easter egg numbers station is the only one so far. The Lorenz attractor from Streams is an obvious candidate, but I can think of some others…

  • Thanks a lot ! will try this tomorrow :D

  • The Turing Machine implementation still needs some tweaking, but it is still quite usable as it is. The probability knob might be better with a log response. Currently it is linear from zero to 0.125, then jumps to 1. What I would really like to add is output CV quantisation. I think the hardware design of Peaks might provide sufficient accuracy to permit that. However I’ll be away attending conferences and cycling in Alsace for the next month, so it may be a while before I can explore that. Lots of other ideas too – if only Peaks had a display and an encoder…but then it would have cost as much as a Braids, which defeats its purpose, I think.

  • > but then it would have cost as much as a Braids

    Funny… From my point of view, Peaks costs more than Braids to make. In other words, sales of Braids subsidize the giving away of Peaks.

  • Yes, having, ahem, studied* the hardware design of both Braids and Peaks closely, I can appreciate that. The dual channel TI DAC in Peaks is bloody expensive, and so are the two precision TI op amps it uses, as well as the illuminated push switches. And quite a lot of fiddly and thus expensive, manual assembly, I dare say.

    Regarding displays, I have just completed building this module and I am impressed by the quality, utility and low cost of the display. I understand there are issues with supporting such displays on the same comms channels used by DACs or codecs etc operating at audio rates, but the more powerful STM32 chips can support multiple SPI or I2C channels, I think. The biggest hurdle is the “no menu diving” paradigm, which is fine for single function modules, but means that multi-function modules must make do with obscure sequences of button presses and blinking lights as their user interface. A few lines of text and and encoder seems so much nicer to me. None of this is intended as criticism of MI module design choices, BTW, just as personal musing on the design dilemmas which modular synths present. There’s no right answer.

    • a euphemism
  • Where can we get these displays in bulk? Might be useful for a new project…

  • Not sure where they can be had in bulk, but I bought the one on eBay recommended here by Max Stadler (aka Ultrabiege, aka mxmxmx), the designer of the module. About US$8 retail on eBay, no doubt a fraction of that in bulk from its manufacturer (in China), or a suitable wholesaler (in China). I notice that Max has now switched to a different, slightly more expensive display for an update of another of his designs – see details here

    The issue, as you say, is where to get them wholesale. The name Alibaba is surely ironic, isn’t it?

  • Looking for serious, long-term relationships only.

  • I’ll ask someone who claims to have extensive contacts in the mainland Chinese electronics manufacturing markets, and who might be able to help you source them direct from a manufacturer. And of course it will make many people very excited to learn that you are now working on the post-Ambika polysynth!

  • You can even buy different variants of the carrier PCBs if you want to do your own bonding of the display foil cable to a PCB. There’s a whole cottage industry who’s supplying these to hobbyist. You have to watch out for the number of pins connected, whether it’s 2- or 4-wire serial, 3.3V or 5V on-PCB power regulation and such details.

    It would be a safe bet to assume that the usual suspects such as Raystar, Xiamen Ocular etc can supply these displays in bulk. A quick check using Global Sources will turn up a few leads.

  • @pichenettes I imagine sales of Peaks have been pretty good, though!


  • Dual Turings?! I’m getting more and more excited about Dead Man’s Catch. Cheers – thanks for doing all this work. I’ll probably still wait a little while for bugs to be ironed out, but I’m keeping my eye on this space.

  • Thanks a lot ! just tried this alternative firmware :)
    Love the turing machine !!

  • There will be a three week pause in development while I am away attending some conferences in Scotland and Amsterdam, and drink wine in France. But I’ll be planning the next steps for DMC during the inevitable boring sessions.

  • Keep up the good work mate :-)

  • Coooooool!
    I love the innovation! I always thought Peaks had a little headroom to work with.

  • Actually, there are lots of things that can be added to Peaks. The real problem is the user interface – how to select the modes, and how to indicate which mode your are in, while retaining some consistency with the panel labelling. I don’t think it is possible, so I am tending towards a new alternate mode which uses a binary indicator scheme, and providing a little decoding chart. The four basic modes would still correspond to the panel labelling, however.

  • I’ve just released Dead Man’s Catch version 0.4-beta, which is modified firmware for the Mutable Instruments Peaks module. Full details at but basically, over the previous release this adds some additional envelope modes (a “double attack” ADSAR envelope, a “repeating attack” envelope in which the AD segments repeat while the gate remains high, looping ADR or AD envelopes which retrigger themselves automatically at the end of each cycle (and thus they act like LFOs). Support for these additional envelope types was always in the Peaks code – I have merely made these modes accessible. I think I have also fixed a bug in the previous Dead Man’s Catch release which could cause the module to crash when changing modes in some circumstances. Note that this is still very much a beta release and all the usual caveats apply, as described in the installation instructions on the page referenced above.

  • Thanks ! can’t wait to try it ! :)

  • I guess binary is the way to do it (that’s how Neutron7 of Orgone Accumulator fame is doing it), but it’s not the most (non-techy) user-friendly. That said, even with the standard Peaks firmware, I had to use a reference to remember the functions in the alt. modes, so I don’t mind looking at a chart.

    Hey, I posited a couple ideas a while back, before people started hacking in earnest. Maybe it makes sense to include this alternative mode:

    ASR (or AHR or just AR) with amplitude control — TAP LFO mode has a “depth” (level) control, but none of the ENV modes has it. This saves one having to use an external attenuator.

    I had other ideas, but I think you got to them before I even posted them!

    Great job! Going to mess around with this firmware tonight.

  • @glitched: yes, AR and/or AD envelopes with a level control makes sense. Maybe a delay control as well? A delayed envelope is great for modulating vibrato depth. Or maybe just some logarithmic envelopes, that fade in slowly, would be just as good?

    Also AD envelopes with controls for introducing some randomness. Perhaps random variation of level and decay duration?

    Similarly, maybe some variations on the drum modes with settable degrees for randomness for various combinations of parameters (level/volume, decay time), to reduce the “robotic drummer” feel and simulate subtle variation in how hard the drum is hit. Swing, however, I think is best handled by whatever is triggering Peaks, not by Peaks itself.

  • If we’re looking for a third parameter to include for this ADSR+amp envelope mode, I suggested a “curve” function: .
    Quoth me, “Center value: linear attack/decay. To the left: expo attack/linear decay. To the right: linear attack, expo decay.”

    Frankly, I don’t care too much about this curve thing, anymore. I was attempting to emulate the 4ms PEG’s envelope functionality in a way, but this extra feature is not that important.

    With regards to drums, we could always use more and different sounds. The high-hat at the end of the DRUM mode (I forget which one now) was a nice addition! No one is looking for an Analog RYTM in Peaks, but maybe a couple more sounds (synthesized or not) would be cool.

    EDIT: Nevermind about the drum stuff. Looks like @stevencrichton has been doing something with drums…

    EDIT 2: Nvm again; he was messing with the Easter egg.

  • Yup, the clocked noise model in Braids makes for a nice cymbal sound – that might be feasible. However, Peaks uses the same processor as Braids, but has to be able to run two oscillators at once, albeit at half the sample rate, so it may not be feasible. Worth trying, though.

  • The other itch I want to scratch is getting Peaks to work better with Grids. A frustration is that Grids has accent outputs, but Peaks has no way of making use of them, at least not without using other modules as well. Of course one can patch a trigger/gate out from a Grids channel into channel 1 of Peaks, and the corresponding accent out from the same Grids channel into channel 2 of Peaks, so that the accented beat becomes two percussion sounds at once, in separate channels. But that means using three Peaks to fully utilise one Grids.

    I was wondering if Peaks could be made to distinguish, say, a 1 ms trigger pulse from a 3 ms trigger pulse, and play an unaccented and accented percussion sound respectively? The inputs are scanned at about 1kHz I think, and the internal timer has millisecond resolution. Grids firmware could then be modified to output accented beats as 3 ms pulses instead of 1 ms pulses. Then you’d only need two Peaks per Grids, with a Peaks channel to spare. Of course, such a scheme would introduce 3ms of latency into Peaks (it has to wait that long to determine whether to fire the accented or unaccented sound). However, I have three Peaks, so not much personal motivation to try this.

  • The problem, of course, is too many possible functions and variations on those functions for the available user interface, resulting in increasingly confusing, implicit and hard-to-remember methods of operation as more and more functions are included.

    However, in the light of Olivier’s recent work on creating a standardised, packaged build environment, it now seems quite feasible to create a facility (a web site) which allows end users to select which, say, eight functions they want for the eight available slots in the Peaks user interface, from a much wider palette of available functions and variations on those functions. The selections could be made via a web interface, and then a custom firmware image would then be compiled for the end user to install on their module. The margin cost of running such a facility on, say, Amazon AWS is likely to be rather small.

    Of course, from a support point of view, that’s a bit of a nightmare, but from the end user perspective, the ability to run custom firmware tailored more precisely to one’s needs may be quite appealing.

    I’m not seriously contemplating doing this (although happy to collaborate if someone else wants to do it), but it is nonetheless an interesting possibility, consequent to open-source licensing of module code.

  • WRT accented triggers as discussed above, it seems that others are thinking about this too, although more sensibly sensibly using amplitude of a trigger signal rather than duration to convey accent (or pitch) information. There is, of course, no reason why trigger and gate signals can’t convey more information than just a binary state. But we digress…

  • Peaks’ inputs are scanned at 48kHz, with 1 sample resolution, so there’s more than enough resolution to discriminate pulse length.

    Regarding custom firmware, you don’t need much infrastructure – use a MAGICSTRING01234567 constant in which the last 8 digits are the available modes. You don’t need to recompile, just replace this string in the binary. You still have to generate the .wav though…

  • 48kHz… hmmmm, maybe conveying Grids accent information in the trigger pulse width isn’t such a stupid idea after all, and may be possible without adding any perceptible latency. Definitely worth trying. The modifications to the Grids trigger pulses would be transparent to other modules.

    Given that a WAV file needs to be generated anyway, I was thinking of a Python harness to interpolate the required chunks of source code and just recompile the whole thing, running on an Amazon AWS free instance, with a very simple web interface for choosing which functions for the 8 slots. No real need to register and authenticate users of such a facility – it is unlikely to be abused (famous last words…)

  • BennelongBicyclist> 48kHz… hmmmm, maybe conveying Grids accent information in the trigger pulse width isn’t such a stupid idea after all, and may be possible without adding any perceptible latency. Definitely worth trying. The modifications to the Grids trigger pulses would be transparent to other modules.

    One major impediment to this is that Grids, being Atmel-based, doesn’t support firmware updates via an audio boot loader, as (most) of the other MI modules do. Thus the user base for alternative firmware for Grids is restricted to those who are willing and able to buy an Atmel programmer device and fiddle with ISP connectors and firmware scripts etc. That’s a rather small proportion of Grids owners, I suspect. As an aside, I don’t think the value of the audio boot loader mechanism for firmware updates on MI modules can be overstated – it is an essential adjunct to open-sourcing the code, and it creates a large “marketplace” for alternative firmware which potentially includes just about every owner of these modules. This point was not lost on 4MS, who have adopted the MI audio boot loader for their new SMR module for the same reason.

  • RE: Additional drum sounds
    Clocked noise is useful as a percussion source, that’s for sure. Noise (pink or white) going into a LPF with fast attack/short decay is one of my favorite sounds. There are a bunch of flavors and colors of noise, too, as you may know.

    I actually think Peaks already does this type of sound really well, but I would not mind having a versatile noise-source.

    Some sort of LFSR noise-generator with various options for density, color, sample-rate, loop-length, or loop-point (where the feedback is, er, fed-back into the system) might be fun! It also might be too out-of-scope. But we’re just talking, here.

    EDIT: I’m forgetting that Peaks doesn’t have any type of CV control, so such a noise-source might be a little boring.

    I’m still really big on the AR/ADR+shape (or whatever) with amplitude. This will be a huge cable-saver!

  • Yes, the lack of CV input means that Peaks is best suited to triggerable or gated or stepped things. But then LFOs are an exception to that rule, I suppose, phase reset notwithstanding. Tap LFOs are not an exception, however.

    AD and ADR envelopes with an amplitude control are definitely on the agenda. Not sure about the response curve control. First step is to implement an envelope with a log response. Then adding a control to permit morphing of the response from log to linear to exponential might be possible.

    Echoing AD envelopes may also be useful – rather similar to the bouncing ball envelope, but implemented differently, just as an auto-retriggering AD envelope with quartic or expo curves, and a decaying amplitude each time. This could even be added as an Easter egg mode (Easter egg modes in Peaks are distinguished by the fact that they take over both channels) – and thus the “echo envelopes” could even pan or bounce across the stereo stage…

  • Grids has an audio bootloader.

  • pichenettes> Grids has an audio bootloader.

    Really?!? Ah, so it does! Update via SysEx on the MIDI input as well. Looks like the audio update file needs to be played into the Clock input. Presumably the audio boot loader is invoked by holding down the reset button at power-on?

    OK, encoding accent data in the Grids trigger width, and decoding it in Peaks, is back on the agenda for DMC.

  • Just got my Grids yesterday and spent 30 minutes on it playing peaks and hi hats from Bastl Grandpa (were I incidentally used the accent out from Grids hi hat player to trig two different sounds). Cool!

    Trying to read back (and think): the solution you’re suggesting would allow for accents on Peaks’ drum sounds? Wiggling Peaks encoders make for different drum sounds… so these rich triggers from Grids to a new DMC Peaks would essentially mean the drum sounds were tweaked to produce accents? How do you define “accent” on for example the Peaks kick drum – asking because adjusting the Peaks kick drum makes for different decay, which isn’t necessarily the same thing as accent?

    And what would you visualize the patch would look like from a modified Grids? It has… separate outs for accents as it stands – and I imagine the accent sequence data is currently used in a rather binary fashion, in that it merely sends a trig for the accent out in addition to the plain trig for any given drum channel?

    Keep up the great work! Sorry if the above is very low level or just inaccurate. My curiosity got the best of me!

  • > And what would you visualize the patch would look like from a modified Grids?

    The idea is simply to make Grids emit different trigger durations for accented / non-accented notes – so the accent information would be already present in the trigger signal itself. Thus you would only need to patch these 3 outputs – for example patching 2 of them to Peaks for kick/snare, and the third one to another module.

    On the 808, the accent simply raises the level of the pulse that hits the kick/snare “resonators”. It might also distort it a bit (the excitation pulse, not the output signal).

  • I’m excited by this idea, I have to say! I really like the Peaks drum sounds, but the lack of any kind of dynamics has always been a problem for me. This sounds like a great solution for people like me who use Peaks with Grids, and won’t inconvenience everyone else.


  • Yup, what Peaks might do with the pulse-width encoded accent information is not limited to the parameters currently exposed via the knobs. At the very least the accented beat would be louder than the unaccented beat, but it could also have a longer decay (to simulate a harder hit) etc. In fact, the accented beats could even be a completely different audio generator. Of course, the limited Peaks user interface can’t support tweaking all these possible parameters, which is why I floated the idea of a web service in which you use your browser to specify which 8 functions you want in your Peaks, and tweak all their non-real-time parameters, and then download your custom firmware with those choices and preference baked in. You could still adjust 4 parameters via the knobs in real time, of course.

  • I’d be happy with just the standard accented-is-louder, to be honest, but other effects might also be nice, depending on the percussion model.

    Bear in mind that it’s only Grids that will send out the appropriately modulated trigger pulse, and it sends out accents to indicate louder drum notes. It’s worth considering what might happen if other devices trigger Peaks drums. Depending on the length of the trigger pulse/gate, these devices may always trigger either accented or unaccented notes, or if being triggered by a manual gate input, may sometime trigger accented and sometimes unaccented notes, but not in an entirely intuitive way.

    You’re right, though, the Peaks interface is the limiting factor in terms of what you can ergonomically squeeze into it.

    I like the web app idea, if it can be made to work. Maybe the code can actually generate an audio file that can be played back directly from the browser…


  • @toneburst, I was envisaging this as a distinct trigger-width-aware set of drum functions that you would enable only if you were using your Peaks with a Grids running the suitably modified firmware.

    Yes, you could access the custom firmware web site from your smartphone or tablet computer and immediately play the file into your Peaks module through the phone or iPad audio socket. It would require a power cycle on your modular to allow your Peaks to be put into bootloader mode on power up, though.

    Variations on this theme are possible. The entire Mutable build environment and source code can easily be installed on a Raspberry Pi, as can the mooted web interface for firmware image customisation which we have been discussing. If you equip the Raspberry Pi with a wi-fi dongle in infrastructure mode, you could then access the firmware customisation web interface from your smartphone or iPad (or laptop). Connect the Raspberry Pi to an ST-Link v2 JTAG/SWD interface (via USB), and connect that to the mini JTAG port on the back of your Peaks. Then you could reconfigure the firmware image, including adjusting non-real-time (fixed) parameters etc, and reflash the module in well under a minute (including compile time), all without having to cycle the power or having to remove patch cords. That would work for all MI modules, so it could also be used to, say, swap between Tides and Sheep firmware. Total cost of the Raspberry Pi and other hardware would be under 100 euro, and it could just live inside the modular case – it doesn’t need any front panel space because the interface is a web site via a local wi-fi network that it itself provides. Now, with a clever electronic switch for the JTAG/SWD interface cable, connected to a few GPIO pins on the Raspberry Pi, you could even have one such device able to reflash multiple MI modules in the one synth case – you would select which module via the web interface.

  • Amazing idea!

  • That programmable Owl module has something similar going – really cool concept and somethin I’d love to see.

  • @accountboy – yes, although the Owl platform goes beyond this idea – it offers a supervisor into which you can dynamically load DSP plug-ins written in C++, or plug-ins written in the high-level PureData language, translated to C++ by Heavy (which is proprietary, not open source, I think), or DSP processing modules written in the Faust high-level DSP language, also translated to C++.

    In theory, Faust could be extended to include MI modules such as Clouds or Elements as a target, and emit C++ code that would run on them. That would be really interesting! Faust hails from Lyon. It doesn’t take very long to get there by TGV from Paris, or v-v…

  • RE: Curves on AD/ADR/whatever envelopes
    Yeah, I don’t really care about the curve at this point. The standard “quartic” or expo response will do well. I’m more of a percussive-envelope type of guy, anyway.
    Nice job! Innovative ideas!

  • OK, here is a quick-and-dirty demo of work-in-progress (not yet released, although the code is on GitHub) on a randomised AD envelope class in Dead Man’s Catch. In this class, knobs 1 and 2 control attack and decay times respectively. Knob 3 controls the degree of randomness of the envelope level, with a new random offset being chosen every time the envelope is triggered. Knob 4 controls the degree of randomness of the decay time, using the same random offset which is used to perturb the level. The perturbation is arranged so that louder envelopes have longer decay times, and quieter envelopes have shorter decay times.

    This demo uses two of these randomised envelopes to control the level (gain) of two Tides modules, each envelope triggered by a channel of a Grids module. At the start, both level and decay time randomness are set to zero on both envelopes. First, decay randomness is increased on the first envelope, and then level randomness is increased on the same envelope, so that some beats have a randomly longer decay time and are randomly louder than other beats. Then decay time randomness is increased on the second envelope, followed by an increase in level randomness. Finally, both decay and level randomness are returned to zero on both envelopes, thus returning to the initial, somewhat robotic, rhythm.

    Yes, I plan to do something similar for the drum functions as well. And yes, it would be great to have sequenced variations of each parameter, rather than just random variation. That’s a bigger challenge, but I have some ideas.

  • Oh wow….so that’s a really cool development! I’m all over that.

  • This is pretty cool! I figure I’m always doing something with randomness, why not have it built-in?

    Hey, two more silly ideas:
    1) “Bouncing Ball” gate/trig generator – similar to the other mode, but this one outputs gates/trigs on each “bounce.” I can see using this for drums and other percussive voices, maybe sending it to a clock-divider/multiplier for “ratcheting” patterns.

    2) Random gate/trig stream generator, but based on clock-divisions (a.k.a. “Richard Devine Mode”) – Much like the mode that’s already in alt Peaks mode, but the output-pulses are based on the incoming “clock”. I think the SSF Ultra Random has something like this.

    Eschew the probability control, but have these parameters:
    1) Variation – amount of randomness
    2) Range – of the divided or multiplied clock (1/2 to, I don’t know, x16 or something?)
    3) Repeats / Duration – probably not necessary; repeats should probably go on until the next incoming pulse
    4) Pulsewidth – of the output

    Just some more crazy ideas…

  • Definitely ideas worth trying – I’ll add them to the (ever growing) list. It’s clear that a “Pimp your Peaks” customisable firmware creation web site is going to be essential -there are just too many potentially useful things you might do with a Peaks to pack into one UI.

    I added an aide-memoire a few months ago to the Mutated Mutables wiki about carefully studying the ben_hex YouTube video about the SSF Ultra Random for ideas that could be implemented in Peaks – I must do that.

  • I guess that’s the trade-off for having such an open module: so many possibilities!

    Oh, you know what? The module I was thinking of was actually Qu-Bit Electronic’s Nano Rand, which has something like the mode I described.
    link (go to around 3:50 for the reference.)

    The randomly-modulating waveshape-output is particularly interesting.

  • Does anyone know of any VST ports of the Peaks drums? It seems that the peaks drums are a great candidate to be turned into a VST instrument since they have no CV inputs. Something like a Tides VST in contrast would be limited in comparison to the Euro version by the low resolution of available MIDI modulation.

  • @glitched, OK, thanks, I’ll check out the Nano Rand for ideas. Randomly varying waveshape sounds cool. I’m experimenting with randomly modulated percussion, with mixed results. Subtle random variation in frequency seems useful, but not so much decay time. Yet to try level variation.

  • Someone could end up with a rack of Peaks all doing different things at this rate :-)

  • @risome: um, yes, maybe half a dozen even.

  • More work-in-progress: demo of randomisation of pitch and hit strength parameters for the bass drum and snare drum models in Peaks. The degree of randomisation is adjustable, and a new random adjustment to pitch and/or various hit strength parameters is chosen by Peaks each time a trigger is received. Can be dialled back to almost subliminal levels of variability, where it removes the robotic feel just a bit (especially when combined with swing on Grids or whatever the trigger source is).

    Still to do: randomisation of the High Hat model. And then semi-random (auto-correlated) variation of these drum parameters – that is anticipated to sound better than purely random when the variation amounts are turned up, but we shall see.

    Changes demoed here are checked in to GitHub but are not ready for a release as an audio firmware update file yet.

  • Been having a great deal of fun with the new modes in DMC, but I’ve started to run into “crashes” (er, freezes?) when attempting to escape out of the secondary modes. Oftentimes, it’ll take a few power cycles to get it working again. Not sure if it’s just coincidence, but this seems to happen mostly when I’m switching from twin/expert to split or vice versa within the secondary modes.

    It’s interesting because I wasn’t experiencing this pre-v.04 beta, but I know that a fix was implemented for this particular issue in this most recent version.

  • OK, thanks. Two other people have reported this, but I can’t seem to reproduce it. I’ll be working on DMC this weekend, so will investigate further.

  • @REVIVER and anyone else who has experienced a crash running DMC, does the module freeze (buttons unresponsive) when you are in standard drum mode and, for channel 2, you turn knobs 2 and 3 fully clockwise – that is, when you enter high hat mode?

    It seems that the high hat model is causing the user interface to freeze. No idea why at this stage.

  • No, I’ve mostly experienced the freeze when in a secondary mode; such as the sequencer or Turing Machine. Seems to happen mostly after the module has remained untouched for a while (not that timing necessarily has anything to do with it)....if I try to long press on the mode button to switch to something like the LFO, it’ll then freeze.

    Actually, just as I was typing this, I got it to freeze….

    1) Was in TAP split mode
    2) Long pressed on the mode button to send it in to secondary mode
    3) Pressed split; which should’ve dumped it into Trigger Stream Randomizer
    4) Frozen

    Cycling the power did the trick this time, but that isn’t always the case…sometimes it takes a few cycles. Almost like it’s defaulting back into a frozen state.

  • OK, thanks. Unfortunately, I can’t seem to reproduce that. I suggest that anyone running DMC beta versions should re-install the factory firmware for now. At this stage, I don’t know when I will be able to provide a fix for this problem in DMC- I won’t have much time to investigate it over the next few weeks.

  • I have to say that the randomized snare doesn’t do much for me. If there were more parameters to randomize, a high random value might more interesting (you could end up with bleeps, pure-noise, FM stuff, metallic stuff…) Since it’s an 808 SN model, I suppose there’s not much to work with (osc pitch, decay, filter, noise-level?) The subtle settings are more enjoyable. (I’m not sure I would use a randomly-pitched 808-snare in my compositions, but possibly would use the BD.)

    Byte-beats in Peaks…hummm!!! This gets me excited.

  • I’m not entirely happy with the randomised drums myself. I plan to try a random walk, so there is a degree of autocorrelation in the random perturbations, rather than just an independently random perturbation on each beat. However, yesterday I quickly hacked in the byte beats that I had previously added to Bees-in-the-Trees, and yes, they are a lot of fun! I’ll be implementing many of the byte beat equations from the Microbe Modular Equation Composer that I can over the next week or so. Also, it seems that the high hat was the culprit for the lock-ups – disabling it seems to have fixed the issue. The FM drum can still be used to create a convincing high hat sound, both open and closed, I think. Anyway, maybe a fresh DMC beta release some time next weekend, although no promises.

  • Looking forward to it!
    I’ve been playing with “byte-beat” (viz-nut) compositions for quite some time and envied owners of the Microbe module.

    I think Peaks may become the best multi-function module money can buy (as if it wasn’t already)!

    Additions I’m most looking forward to: 1) envelope with amp control 2) byte-beats (!) 3) randomly-modulating wave-shapes LFO 4) “bouncing-ball” gate/trig mode.

    Thank you for your efforts!

  • @glitched, 1) and 2) will be in the next (beta) release.

  • @glitched, can you describe how you envisage the mapping of the controls in normal/expert and split modes working for your settable amplitude envelope? I can’t come up with a sensible scheme, unless the amplitude is only settable in normal/expert mode, but not split mode.

  • @BennelongBicyclist thanks for all your hard work on firmwares. I’m considering buying Peaks after reading this thread. The split mode amp control is important to me. How about knob 1 is amplitude and knob 2 is decay? Just assume 0 attack in split-amp mode. It’s a compromise but it would work well for many scenarios! What do you think?

  • @cliffemu, yes, that’s what I was also thinking of as the best compromise too. It will be several months before dead man’s catch is ready for production use, but of course you are welcome to try beta versions. But Peaks is a really excellent module even with the standard firmware, and worth having in your rack – I’m just adding some flourishes around the edges.

  • Bennelong:
    Split-mode is where we can get really complex or keep it very simple.

    One of my original ideas was to emulate the 4ms PEG’s “preset” envelope-types, but I eschewed it as being a little too much.

    Still, if you’re feeling adventurous:
    Knob 1/3 — “preset” shapes progressively going from short-attack/short-decay, short-attack/longer-decay, short-attack/longest-decay…

    EDIT: Looks like Streams has something even better:
    From the manual

    “The SHAPE knob controls the envelope shape. Over the first half of the course of the knob, envelopes with immediate attacks and increasingly long decay times are available. Over the second half, the attack progressively increases as decay shortens, producing envelopes more typical of brass instruments.”

    (Oliver is pretty brilliant with his single-knob control schemes!)

    OR: we could make it ultra-simple and have knob 1/3 control decay-time and 2/4 be amplitude, as cliffemu says.

  • @glitched emulating Streams like that sounds like a great idea! Thanks again to Bennelong for taking this on. It would basically make Peaks a mini-Streams :)

  • Yup, that’s a very good suggestion. I also want to port the Lorenz attractor Easter egg from Streams as an additional Easter egg in Peaks – and maybe some other cyclical algorithms as well. However, I’m still tweaking the current set of additions – which takes a lot of trial-and-error, listening tests etc. I want to get those right before moving on to adding new things, although every day a new idea occurs to me.

  • What festures, if any, are being omitted from the og firmware for dmc? I understand there was a lot space for your changes. Thanks!

  • So far, only the high hat model, which is accessed via the snare drum model and isn’t adjustable, has been removed, or rather, disabled. For unknown reasons it was crashing (pun intended). The plan is to substitute a different, more adjustable high hat model as a separate function, not overloaded onto the snare drum model, in due course.

    The numbers station Easter egg may need to be removed at some stage – I’m reluctant to do so because I find it charming and I have a crush on the person reading out the numbers, but the samples it uses do occupy quite a lot of storage.

  • I found the cause of the problem I was having with the high hat model – or at least, I found a possible fix for the problem. The high hat model runs two instances of a state-variable filter at double the sample rate (Olivier has left a comment in the code: “for stability”), which seems to be too much for the MPU to cope with, at least in the DMC context (but I’m not sure why it works OK at twice the sample rate in the standard firmware but not in DMC). Anyway, running both filters at once the sample rate, not twice the sample rate, seems to have fixed the problem. I need to check what effect that has on sound quality/stability (of the filtering), though. But a mystery at least partially solved.

  • To be clear, when running the high hat SVFs at double the sample rate, as in the factory firmware, DMC doesn’t crash, but the UI stops being polled and refreshed at the proper rate, so it appears to have locked up. But the high hats keep playing in response to triggers, so the entire module doesn’t crash. It’s like it is skipping the UI interrupts.

  • > but I’m not sure why it works OK at twice the sample rate in the standard firmware but not in DMC

    The F1 is weird… the run time speed of bit of code may depend on its position. Just adding more code somewhere else that will shuffle the position of the block of code in flash is enough to change the timing. I suspect this could be due to prefetching/internal caching – working less efficiently when a sector boundary is crossed.

    The HH render code is copied in RAM to avoid this problem, but maybe something somewhere else is running slower.

  • @pichenettes: yes, I noticed the IN_RAM directive on the SVF .Process() method. Anyway, at least I have a work-around for now, and I’ll periodically test whether restoration of double the sample rate works as the DMC code evolves.

  • OK, I have released Dead Man’s Catch v0.5-beta, for those interested in testing it. Full details and downloads on the GithHub release page for it, but following is a summary of the functions added by DMC v0.5 over the standard Peaks firmware. No functions have been removed.

    • it unlocks some hidden envelope modes which have been in the Peaks firmware from the outset: a double-attack envelope, a repeating attack envelope, a looping envelope, and a Bouncing Ball envelope generator. The Bouncing Ball envelope emulates a ball which is thrown into the air and then allowed to fall back to earth and bounce several times – think of a basketball bouncing on a basketball court. The envelope output equates to the height of the ball at any instant.
    • it adds a “randomised AD envelope” mode, in which the level (amplitude) and decay times of the envelope have random amounts added to them each time the envelope fires. The amount of randomness added is adjustable, separately for amplitude and decay time.
    • (new in v0.5) it adds “randomised” bass and snare drums, in which the pitch and/or the level or decay time of the bass (kick) and snare drum models follows a random walk, with the stride of each step being adjustable from zero (no randomisation) to a fair bit.
    • it adds dual Turing Machines, which are semi-random looping CV sequencers, modelled closely on the Music Thing Turing Machine.
    • (new in v0.5) it adds a “ModSequencer”, which works in a similar way to the DinSync MODSEQ module, and which is, under the bonnet, just a very simple extension to the existing Peaks mini-sequencer mode.
    • (new in v0.5) dual “byte beat” noise generators have been added, with clock rate and two other parameters settable via the front panel pots. Eight different byte beat “equations” are available (it is easy to add more in later versions, or better equations substituted).
    • (new in v0.5) the high hat model has been moved to its own function, rather than being available only as part of the snare drum as in the factory firmware. The high hat is now also adjustable. However, it runs at half the sample rate of the high hat in the factory firmware, and thus sounds somewhat different. It offers randomisation too.

    Here is a quickly-recorded-in-one-take but rather lengthy demo of two of these new features: the randomised high hats, and the byte beat equation oscillators. The thing to note about this demo is that the only sound source used are two Peaks – one for the high hats at the start, and the rest of the track is a single Peaks (filtered through two Ripples). That’s it, nothing else except a bit of reverb in Logic Pro X. Props to anyone who can identify the cultural reference in the title of the track without using Google.

  • Thank you! This is excellent. Having a great deal of fun using the random AD.

    Though, it seems that I’m still experiencing occasional freezing. The best way for me to recreate this is to start off in a split mode standard function and then long hold the mode button to enter secondary. It seems to happen going the other way to. Sometimes from secondary to standard.

    If I start up the module, it’ll boot right into where it was when it crashed, but will ultimately crash again if I try to swap between secondary and standard modes. At this point, it sometimes also freezes when swapping between split and twin modes. Usually requires a few “reboots” before it’s out of the freeze loops.

    Any thoughts? Doesn’t seem related to the drum/hi-hat in any of these cases…

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion