crow v3.0.1

This is a small patch update for crow v3, primarily fixing connectivity issues with norns scripts, and fixing an issue in ASLs with very rapid gradients.

We’ve also updated druid to fix Windows connectivity, and have refined documentation for updating crow’s firmware.

Update druid with

pip3 install --upgrade monome-druid

Update crow after updating druid, in Terminal / PowerShell:

druid firmware

If you have any connectivity issues, try closing your Terminal & open a new one.

If you’re on Windows and having connectivity issues, watch this video walkthrough of the process.

A new norns update 210706 fixes crow initialization when attaching crow to norns, and changing scripts.

Use SYSTEM > UPDATE on norns.

After updating norns, be sure to update all scripts from the Maiden library as many scripts have had small updates fixing crow connectivity.

See here for the full crow 3 update, and a walkthrough of the new features.

If you have connectivity issues, please email rather than posting symptoms here. Please include your computer’s OS, and whether you had a previous working version.

Hoping to keep this thread focused on the new crow v3 changes & features!


Here’s a little demo showing how ASL’s new dyn (read: dynamic) variables can be used to create envelopes that are intrinsic to an oscillator, as well as switching oscillator frequencies on the fly.


woahhhhh this is incredible. what was the inspiration for dyn?

@Galapagoose is there currently a way to set/change crow addresses? i see there are Teletype ops for addressing up to 4 crows, but can’t find any info on setting addresses.

1 Like

I replied on discord with what I think may be the solution

1 Like

just saw that! thanks, i’ll try it out and report back :slight_smile:

edit: no luck with removing a crow from the bus and using crow.sel 2. it seems like crow.sel 2 just makes all subsequent crow calls get sent to crow #2, or in my case to nowhere. issuing crow.sel 1 gets things working again, but with both crows responding to every command still.

Looking at the firmware source code, it seems like you are supposed to set the address of an individual crow with ii.set_address(2) for address 2 and so on. I tried putting that in the init() function of a user script saved to flash, and then cycled the power for the crow. When the crow turned back on, print(ii.get_address()) reported that the crow was crow 2, but it still responded to commands for crow 1.

Looking in main.c, it looks like when crow is turned on, the low-level I2C system gets initialized (and the address gets claimed) before any user script is loaded, so the address at the lowest level is always the default: 1.

I’m guiessing that ii.set_address needs to be changed so that it will re-initialize the I2C system when it is called. At that point, though, we’re well past the limits of my knowledge of I2C so I have no idea how that could be done safely.


I’ve tried running /w and Just Friends at the same time on M4l and either the connection drops out or Ableton crashes after 30 seconds of running both simultaneously. This happens when operating command center + w_synth and command center + jf_synth. Does anyone have workarounds or tips how to prevent this?

hi hi! hope all’s well otherwise!

are you running two instances of command center? you can only use one per crow :slight_smile: (same goes for running druid and command center — only one or the other should be loaded at a time)

otherwise, happy to troubleshoot with any steps you can provide to reproduce the issue!


Ahhh I see, I must’ve forgotten the multiple command center thing. Thanks, I’ll give it a second try!

1 Like

Did you work out a dual crow setup with TT that is persistent?

i was not able to get things working, unfortunately. in my attempts, it seemed like both crows always respond to address 1 regardless of what you set them to.

this is definitely something i’d love to be able to do though.


Ok so i recompiled the firmware with the suggested commit Re-init I2C HAL layer when setting address by beels · Pull Request #431 · monome/crow · GitHub

if you ensure ii.set.address(2) is present in the lua script loaded in the second crow the TT CROW.SEL 2 works on startup.

Obviously a hack but works for me.

Edit: if anyone wants the firmware lmk i only changed two lines


I kinda liked giving the script direct control over its address. (My crows move around, so their addresses need to change depending on the patch.)

Unfortunately, that pull request is in a kind of liminal state right now. I’ve demonstrated that the bug is just a matter of the existing address code not being exposed, but it’s not clear how to expose it properly. My PR doesn’t fit @Galapagoose’s requirements for structuring the firmware, and I can’t figure out how to make a more conformant change without a rewrite of low level code that I really don’t understand.

If anyone who has more experience with crow (or the underlying hardware stack) wants to take a look, this feature could use some love.

1 Like