Mac Tutorial: How to compile and upload the firmware of MIs eurorack modules



quick question on the peaks side, are the trigger in’s only capable of binary detection, or could a CV be passed to them? If I can get around needing a quantiser by loosing a couple of the special features in place of that, I’d be able to avoid having to scale up my racks.

I expect not, but worth asking :wink:


“I’d be able to avoid having to scale up my racks.”

Or more to the point, I’d stop my wallet crying for a bit of time.


If it was capable of sensing CVs, I would have already coded a secret Oscillator mode :slight_smile:

It only senses whether the signal is above/below 0.6V.


> It only senses whether the signal is above/below 0.6V.

Hmmm, now Peaks could be turned into a VCO if you used a little module in front of it that took a voltage and turned it into a series of pulses at the right frequency to be fed into the trigger inputs on Peaks…no, wait…that little module would be a VCO!


not a bad idea none the less… one thing I had thought about was a swinging clock. There seems to be little in the eurorack way to introduce a swing to a clock without a lot of work. Currently I use an iphone app or an external sequencer.

The trigger could be used to translate a swing, then you could also have a hold and scale intervals into it in 4 pot mode.

1: swing - (sensible amounts like- 15)

2: pulse rests, as in scale the rest into the detected gate length: – -- – -- > - - - - (great for hats from envelope less modules like tides etc)

3: proportion of every 1/4th gate against the 4 1:1 > 4 un-proportional in the swing.

4: clock division. ( I use a channel on maths for this as it seems like clock dividers are very expensive in relative terms ) This super secret mode would mean both outs are controlled by the one 4 channel mode. so you can get boom chika chika chicka boom with a peaks and 2 vco’s.

Actually now I think about it this plus 3 more simple things utilising the 2 outs as a single master strip … Memory wise, possible? Peaks isn’t at breaking point like braids in terms of the footprint left is it?

If not, BennelongBicyclist … I think I have a plan as to what to start playing with.

Peaks mode other.

1: swing clock mode
2: dual noise which can be quanta clocked or random with a pseudo filter for the random.
3: fighting clocks. master clock mode. (why use a VCO as a clock!) think a digital wogglebug of sorts nice clean output and 1 with influence against it by the 2 triggers.
4: dual clock divider. uses 1 in. second can be used to POP a division up and down to to the secondary value set to create a weird rhythmical messes.

I’d be happy to loose the sample and the morse code gen for these. Mainly because I could then remove theanalog solutions lfo I have for nothing other than a master clock at last.


Everything in your “Peaks mode other” list looks feasible, although 2. would be the most difficult, as it would involve porting some DSP code from Braids, assuming it can be made to run on Peaks.

There is quite a lot of free flash storage space left in Peaks, so removal of existing features may not be necessary. By far the largest constraint in Peaks, amongst all the hardware constraints, it its limited user interface - basically some buttons and LEDs. The tricky thing is to come up with ways to overload those controls to allow selection of the additional modes. Possible, but testing required to see how complex button-pressing patterns work in practice.


I updated the tutorial to make it easier to understand and removed some errors. Any remaining mistakes or obscurities?

I also added a second thread for ideas about alternative firmwares to keep this thread focused :slight_smile:


A few notes:

  • uploading firmware via the audio interface is slower, but I don’t think it is very slow - it takes about 90 seconds for Braids and Tides much less for Frames or Peaks.
  • uploading firmware via the audio interface only works if the audio bootloader has already been installed. Thus it is always a viable and good option for owners of factory Braids. For DIY Braids constructors, the audio bootloader and main firmware must be flashed to your module once via FTDI or SWD/JTAG, in order to bootstrap the module.
  • you only need to connect the TX, RX and ground pins on your FTDI interface to the correct pins on the module (RX->TX, TX->RX, GND->GND).
  • make sure that your FTDI interface is set for 3.3V levels, not 5V levels. Some interfaces have a jumper to set this, others require a trace to be cut on the PCB and/or a solder bridge installed.


Being something of an idiot, but one that’s prepared to experiment a little with the Peaks code, would it be in any way possible (and not a massive amount of work) for someone to build a little standalone Mac app that could automatically compile (probably not the correct term to use here) a specified folder of code into a WAV to play into the Peaks to update the firmware.

The instructions above, while very thorough are WAY above my paygrade at the moment.



The makefiles provided by Olivier and referred to in the notes at the top of this thread, and run by the make command, do exactly what you request. They just happen to run from the terminal prompt. But if you follow the instructions carefully, it will just work, especially if you are on a Mac, no need for a GUI. After all, there’s no point-and-click GUI to create source code C++ modifications - it’s all just text and you need to type on the keyboard. I’m not being flippant or sarcastic, just pointing out the nature of the task you are contemplating. It is definitely not rocket science, but nor is it just a matter of clicking a mouse either.


I just find myself almost consistently failing at being able to make anything I need to try doing in terminal work.


Such a tool would be pointless, because if you have the skills to understand the codebase and make significant modifications, using the command line and makefiles is not a big deal.


I can kinda logically follow (small bits of) code having done a tiny bit of arduino/processing stuff but the instructions and syntax of the command line stuff is totally over my head. I was just going to try to tweak the range and polarity of the lfo’s rather than conjure up some new feats of programming genius.

No big deal. Cheers anyway.


But you don’t even need to understand makefiles or shell scripts - you just need to follow the instructions to run the files as provided by Olivier. The only things you may need to change are the path to your toolchain and device name of your serial or programming interface. You would need to specify those even if you had a GUI…

Anyway, I’m happy to apply a small set of tweaks to Peaks code and compile the code for you, if you want. Just post your proposed changes in a new thread on this forum, so as not to derail this thread too much. However, I don’t (yet) have a Peaks on which to test the compiled code, so you will have to do the testing yourself. Note that there is a slight risk that code changes may brick your Peaks in a way that is unrecoverable, even by reloading the factory firmware via the audio interface. In that case, you can always recover your Peaks by re-installation of the firmware using the serial FTDI or JTAG/SWD programming interfaces on it - but that will require use of the make scripts from the terminal prompt… However, the likelihood of that happening with minor tweaks is small, but it can theoretically happen if stored settings are changed in a way that stops your Peaks from working and which also stops the factory firmware from booting up successfully. Braids v1.7 now has code to protect against this, but not so the other modules, I think. However, it is unlikely to occur, but is theoretically possible if care is not taken when hacking the code.


I have no exprience yet about AVR Flashing or programming but some projects waiting on my desk will require that I need to do it.

Do you think this tool useful ?

AVR8 Burn-O-Mat: eine grafische Oberfläche für avrdude


Pretty sure there’s an IDE around which makes builds a bit easier to execute, but there’s still dozens of things to go wrong. The time it would take you to figure out the IDE means you’d have figured out the command line in less time.


I’m having trouble compiling Clouds. (Elements was fine, so I know the toolchain for the gcc eabi must be ok). Clouds bootloader compiled OK too.

I’m seeing two issues:
./clouds/dsp/fx/pitch_shifter.h:101:39: error: ‘ONE_POLE’ was not declared in this scope

and …
./clouds/dsp/granular_sample_player.h:156:55: error: no matching function for call to 'Crossfade(float, float&, const float&)'
1.0f, window_gain, parameters.granular.overlap);


I bet your version of stmlib is outdated.

git submodule update stmlib.


Updating stmlib fixed exactly the same problem I had last week … quick fix !


Aha…That was it. stmlib was out of date. Thanks!