I have latest for jf and my crow is running 4.0.1. I don’t seem to be having any of the issues that people above have been having with ii. My crow is from the latest batch.
1 Like
I really don’t know how to answer this question, I don’t think so anyway.
I personally don’t use crow for live coding or to sequence JF or W/ via Druid, so after this v4 update I’ve used Druid only one time, very quickly, but I’ve experienced few strange behaviors doing simple tasks like quitting, resetting, or checking crow firm, something that was flawless till v3.
I use crow a lot as a bridge for Norns and eurorack and after the update I’ve experienced norns freezes with certain scripts connecting crow via usb to Norns and as soon as the usb cable was disconnected Norns un-freezes, never happened before, or simply struggling to play JF or W/ with scripts that was very stable at this tasks on v3.
1 Like
you do not need to update the other modules.
1 Like
quick update to say i’ve finally found a reproduction case for the bugs people are mentioning. it seems to be specific to some norns scripts, but i’ve yet to nail down exactly what is causing the issue. probably won’t get to a fix today, but hopefully tomorrow. apologies this wasn’t found in our (extensive!) beta testing round.
and i can confirm that you don’t need to update anything other than crow itself (even the first JF firmware with just type will work fine).
32 Likes
_pete
45
Hey @dani_derks - this is an older unit, gifted to me by a friend.
My crow became unresponsive about an hour ago after uploading krahenlied.lua via druid. running 4.0.1, and it’s an older crow. after opening up the krahenlied.lua file, it does mention that the script can lead to crashes – which I don’t know. I just picked one at random. I’ve tried forcing the bootloader from both norns and druid, but no luck. druid reads and maiden reads “no DFU device found” I’ve also tried power cycling the case a couple of times. Any suggestions on what to try next?
So today I received a powered i2c busboard from Pusherman and that seems to have remedied my issues interfacing with Just Friends. Take thatvfor what it’s worth.
Re @tofuBahnMi
I’ve had that happen and ended up having to manually force crow into the bootloader using the procedure outlined here: manual update | monome/docs
2 Likes
thanks @David_Panseri! that did the trick.
If it can help, I wanted to add my own experience with my i2c setup. It involves one crow with the v3 firmware from an old batch, one crow with the v4 firmware from the last batch, a w/ with the v2 firmware and a Just Friends with the 4.1.2 firmware. Everything is connected with an i2c cable i’ve made with 6-pin (2x3) ribbon connectors. As soon as I send an i2c command, Just Friends freezes, it could be a command for JF or for one of the other modules it doesn’t matter. But, apart from JF, everything works fine, crow[1] to crow[2] and opposite, each crow to w/.
Prior to this new setup, I’ve had one crow (the [1] with v3 firmware) with JF only and they were connected with a 3-pin dupont cable, everything was working perfectly. So I tried to connect the new crow (v4 firmware) to JF directly with this same dupont cable and it crashed the same way. From this experience, it seems to me the new crow with the v4 firmware causes some troubles with JF only.
mreid
50
I had previously managed to avoid the lock ups others had described but now I can also fairly reliably make crow v4.0.1 lock up by trying to have it talk to multiple devices.
In particular, when I use timeline to loop ii.raw talking to i2c2midi and then also try looping some ii.jf and ii.wtape commands I can always get crow to lock up.
Interestingly, even if I am only sequencing i2c2midi notes using a (large, 280 line) script I wrote the timeline loop will play for about a dozen notes before locking up. If I cut down the size of my large script to half its size (by cutting out a bunch of op I wasn’t using) then the lock ups stop happening.
My only hunch is that there is some kind of memory and/or bus contention going on?
Hopefully @Galapagoose’s forthcoming fix will address all of these problems. I’ve been really enjoying v4 so far, even with the hiccups.
Hello all!
Just a quick note to say we’ve released v4.0.2
This update represents a lot of changes to the underlying system, but makes no changes to any of the available features. The purpose is purely based on stability, and specifically at making i2c messaging more consistent and less taxing on the system. Norns scripts that would previously freeze crow (flora, et al) now work correctly even with all of the i2c features turned on at once.
There’s also substantially more RAM available at runtime so scripts can be more intensive than with v4.0.1 without causing memory issues.
There are still some issues with the biggest scripts that I haven’t yet figured out, but we wanted to get this point release out there so folks can have their crows working with all the norns scripts again. For anyone still seeing issues that don’t occur with v3.0.1 but are still present in v4.0.2, send me a DM with the details on what scripts you’re running & I’ll try and get them to reproduce on my testing system so we can get them fixed too.
Thanks for your patience with the issues in v4.0.1 & looking forward to what you all come up with using the new features!
(also a little sidenote for norns users, the updated sequins library, and new timeline module are now available natively in norns, so you can explore their usage without needing crow around.)
47 Likes
Thank you for the effort and solutions! Quite excited to explore sequins on Norns 
3 Likes
Thanks for the effort, really really happy for the 4.0.2 release!
I have a couple of silly questions: where can i find the actual 4.0.2 release? Downloading from the 4.0.2 github page, once i open the directory on my computer, i can read 4.0.1 anyway.
Another question about Fledge script: i’ve already updated crow3 to crow4 with Fledge, but i really don’t remember what i’ve done with 4.0.1 file the last time and Monome docs says only to download the script and launch it, is Fledge aware about which is the latest firm release by itself?
Thx thx!
2 Likes
Fledge isn’t really aware of what is currently on your crow, it will simply upload the newest release from github, whatever that is.
I realize now that I didn’t update the naming of the zip file properly, but rest assured Fledge will put v4.0.2 onto your crow, even if it looks like a funky 4.0.1 version. I’ll update the files to avoid this confusion in future.
6 Likes
Yep that’s basically what i thought 
I’m actually confused anyway i’m sorry, it’s true that on Druid as well we receive 4.0.1 and not 4.0.2 after ^^version , or it’s just a ‘laptop directory thing’? If that’s true and i’m on 4.0.2, i’m experiencing the same exact i2c inconsistence and Norns freeze behavior unfortunately.
1 Like
2197
56
the druid firmware update method still doesn’t work (going from 4.0.1 to 4.0.2). it says 4.0.1 is already installed.
just tried to update manually and i get this:
dfu-util: Warning: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release
Opening DFU capable USB device...
Device ID 0483:df11
Device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Interface #0 ...
Determining device status...
DFU state(2) = dfuIDLE, status(0) = No error condition is present
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "Internal Flash "
Downloading element to address = 0x08020000, size = 285396
Erase [=========================] 100% 285396 bytes
Erase done.
Download [=========================] 100% 285396 bytes
Download done.
File downloaded successfully
dfu-util: can't detach
Resetting USB to switch back to Run-Time mode
then when i open druid, i get the following message(s) over and over again:
(...tail calls...)
userscript:15: in field 'stream'
?: in function 'stream_handler'
?:-1: attempt to call a nil value (field 'io_get_input')
stack traceback:
?: in function <?:44>
any clues on how to proceed?
EDIT: i appears those stack traceback messages are related to the script i was running… after a ^^first it appears to be working fine again. and ^^version tells me i’m running v4.0.1-14-g7721314
2 Likes
I am going to add my name to list of people having trouble with 4.0.2. I wasn’t aware that there was anything wrong until yesterday, because everything I had done since upgrading had been controling other modules via i2c. Yesterday I tried accessing input and output and I get the same issues as @2197.
I am running 4.0.2 (which identifies as v4.0.1-14-g7721314) and druid 1.1.4 under python 3.8 on Windows. I get the same behavior whether I install the firmware via fledge or by downloading the zip file from github and installing with dfu-util.
Edit: I should make it clear that I am having the runtime errors reported by @2197 (nil value for ‘io_get_input’) but not finding that the errors are resolved by loading first.
4 Likes
Same issue here with v4.0.2 (aka v4.0.1-14-g7721314)
> print(input[1].volts)
?:-1: attempt to call a nil value (field 'io_get_input')
stack traceback:
?: in function <?:44>
(...tail calls...)
repl:1: in main chunk
runtime error.
EDIT: Downgrading to v4.0.1 fixes this issue
2 Likes
So it isn’t necessary to downgrade all the way to version 3? That’s good. Why didn’t I try 4.0.1 myself?
4.0.1 should be missing the i2c fixes for Just Friends, though. Right?
1 Like
tehn
60
thanks for the heads up, will get this fixed tomorrow
9 Likes
