Multipass - a framework for developing firmwares for monome eurorack modules

yeah, things like updating display should be done on their own timer. pretty much everything in multipass runs on various timers (like polling CVs, checking for grid presses etc etc). this is the same design as used by other monome eurorack firmwares.

all events are processed by the same queue, so if you have some heavy calculation or a lot of i2c sent when reacting to an event, it’s likely timing accuracy will be reduced. there are a couple of things that could be done - supporting prioritizing events and having a separate queue for sending events to control, perhaps.

if you want to do something more time sensitive i would look at modifying main.c. also, in libavr32 timers run on 1ms intervals, i think there is a way to configure it to run faster but i’ve never tried it.

it sounds like for your application you might be able to just use timers. so basically create a separate timer to update display with the interval of 63ms, that’s what teletype uses. for slewing CVs it uses 6ms.

i should add some functions to make it easier and handle it similarly to how grid LED updates are handled - you put full LED update into render_grid function, and whenever something requires updating the LEDs you just call refresh_grid(); and it will schedule an update.

would love to hear that!

1 Like

gives these a try:

multipass_mp.hex (101.4 KB)
multipass_ww.hex (101.9 KB)

i haven’t tested either, and in my previous tests buttons behaved somewhat unreliably, didn’t have a chance to figure it out, could be just my shnth, give it a try.

i’ve modified the app to support up to 8 gates, so yeah on meadowphysics you can trigger 8 outs.

all the latest changes are on github

1 Like

So, I just got a teletype to play with a JF and I’m trying to get up to speed with all of this. I’m curious… would it be relatively simple to get something like Kria playing through the JF using i2c? Am I misunderstanding how this all functions?

in terms of multipass - yes, it supports i2c devices but somebody would have to port kria to multipass first.

but you don’t need that as i believe it’s possible already: Ansible Development and Beta Firmware Discussion

1 Like

Hmmm, I guess I’m just a little confused… can the ansible stuff be easily applied to the teletype? I am just a bit behind on what firmwares can run on what. I guess there’s also a white whale on teletype thanks to multipass, yeah? I’m sure I could get those running if I’m not mistaken about the properties. Just in classic monome and lines fashion, it’s a bit tough to find the ‘dummies guide’ style post. I’ll read what you forwarded to tho a bit closer.

oh i see what you mean.

the features that multipass provides are only available to firmwares specifically created with multipass. right now this only includes polyearthsea.

check out this guide for more info on what various firmwares are available: A user's guide to monome eurorack firmwares

1 Like

The latest beta in the Ansible thread is capable of switching Ansible to I2C leader mode, which is intended to let you use Ansible apps like Kria to control another module over I2C. TXo works pretty well, ER-301 I think mostly works, and the Just Friends implementation isn’t correct because I wrote it with a very limited understanding of Just Friends / Just Type. I’d like to work on this some more soon.

This was all done based off the Ansible firmware, which does not use multipass. It should be possible to get some or all Ansible apps to work with multipass, in which case it would be possible to run them on Teletype, but someone would need to port them. You also would also have to reflash the Teletype firmware to switch between Teletype’s normal functionality and “multipass Kria”.

Note also that whatever module you use as an I2C leader, some module has to be supplying pull-ups. Teletype and Crow can do this but Ansible and the Trilogy modules cannot by themselves.


Ooookay, this is kind of what I thought. I was under the impression that possibly the advent of the multipass framework you have provided might have resulted in a type of agnosticism within these different applications and firmwares.

I figure there are other clever ways I could achieve said results, such as using your ‘simple example) of translating midi to cv or i2c with something like the ww, kria and meadowphysics midi apps found across VCV and Norns. Or I could just get the dang ansible module as well! :man_shrugging:

But I love where the multipass opportunities might take the community. Thanks for that response!

1 Like

Okay, thanks for the clear answer on this. It all makes sense. I like to know the current status of all my gear can do. I appreciate the info!

pushed a couple of small changes - added a function to check if a clock input is present and increased the number of presets to 16.

white whale and meadophysics have a dedicated clock input, so that’s straighforward. for ansible, trigger input 1 is used as a clock input, and trigger input 2 is available as gate 0. this is different on teletype: no clock input but you have 8 gate inputs 0…7.

for presets i will need to figure out a way to make it configurable for each app, since the number of presets available depends on the app itself and how big its preset data is, so this is just a temporary change to allow for more presets.


I am unfamiliar with the UART trace/debugging mentioned here. Can anyone please point to some details on how to use it or some documentation that may exist? Thanks!

Running into more cases where my coding might benefit from more detailed logs than just printing some info on the teletype screen :slight_smile:.

check out this thread: Trilogy uart header

and some info here: Tips and info on programming a firmware for Ansible

1 Like

Thanks, mate! That helps a lot :slight_smile:.

1 Like

Does Ansible or any other monome module come with the UART header populated? One of the threads you linked to seemed to indicate that, but I am not able to see any pictures in the interwebs with populated headers.

I am worried that I might goof up my soldering and make contact between the points since the UART header is not a through hole mount on Teletype etc.

If you ask when you buy a module direct then Brian would probably populate the header for you. But it’s an easy soldering job, even for a shaky-handed novice like me. Get a right-angle pin header like this or this, lots of options, the important thing is you want the side with the bend in the header to be about the length of the pad and the straight side to be long enough for the FTDI cable headers.

Hold the side with the right-angle bend on the pads on the board and tack one pin down with solder. The pads are already silvered so you don’t need much if any to get a pin to stay in place. If you didn’t get it aligned quite right, reflow it. Then you can do the rest of the pins without having to handle 3 things. Spacing on these is pretty generous, don’t think I’ve bridged any pins in the 3 modules I’ve done but it should be easy to fix them with wick or just your iron if that happens.


Thank you for the detailed advice! That gives me confidence. Let me try it out with my Teletype itself then :slight_smile:.

This should also work, correct?

Yeah, this looks good. I have mostly preferred to have right-angled headers sticking out the back of the module (and found them a little easier to come by) rather than sticking out to the side, depends on the placement you want for the module in the case and your FTDI cable.

1 Like

Makes sense. Thank you!

Ordered the header as well as the FTDI cable from Digikey. Hopefully I will be up and running by next weekend :slight_smile:.

Just now remembered: where is the reset switch on the board and what header to use for that one? I figured I will also solder in the reset option to avoid turning off and on the whole rack every time during dev :slight_smile:

1 Like