Think probably the Windows hard reset procedure that @csboling walked me through above should be documented. I guess it’s mainly covered in that word doc though.

One thing I remember about the moment that caused crow to seize up in the first place: I was sending very fast (audio rate probably) LFOs to the modulate input on the less concepts patch. Is it possible that fast LFOs could cause the unit to seize up?

This is a good point!

Posting a photo of my Crow/JF i2c cable setup. Either as a good example of how to plug them in with jumpers, or someone can stop me before I do it wrong!

5 Likes

I’ve had quiet a few instances of the crow freezing up while using druid.

It mostly happens when switching between running scripts and running some manual commands (which are essentially the same thing).

To get it back up and running I’ve had to re-flash firmware.

Using Mac btw.

Looks right to me

(Will probably link you this from i2c thread)

Ive had a lot better luck utilizing crow via norns than I have via druid.

Are there any dangers in connecting the i2c backwards or otherwise incorrectly? Or will it simply just not work?

Not sure if anyone else has seen this issue, but I’ve had trouble connecting my just-arrived crow to Harvestman / IME 1V / oct inputs.

Had me baffled for a bit.

No problems with various other modules (Make Noise, RE-301), but when I use crow First to drive oscillator frequency for either an IME Hz Donut III or Piston Honda III I get nothin’. Only works if I stick something like a buffered mult in between the crow and the IME 1V / oct ins.

Electricity! Bah!

(Investigations continue.)

I have no experience with Windows but doesn’t the “Add Python 3.x to PATH” checkmark add Python and the place that Python “executables” are installed to to PATH?
https://docs.python.org/3/using/windows.html#installation-steps
@csboling do you know?

And why is running as admin required for connecting to crow/using druid?

P.S. The info in that document to install druid itself are not correct/out of date

I actually had the same issue with HD3 yesterday, didn’t even realise it before you said it, cause I tried First so quickly.

I’m having trouble getting anything out of my new crow, also on a shared system. spent the last few hours getting nowhere fast, trying different cables and plugs etc etc. but anyway, just spotted this post and sounds like the issues I’m experiencing. so do I change the ‘first’ script, or something on the crow itself? I’ll see if updating crow fixes the problem.

it just wont work. no dangers, outside of likely frustration :slight_smile:

I have no experience with Windows but doesn’t the “Add Python 3.x to PATH” checkmark add Python and the place that Python “executables” are installed to to PATH?

yes

And why is running as admin required?

it shouldn’t be, but maybe depends on the windows security setting on the machine being used?

I don’t think there’s a new release firmware with the updated threshold voltage, so updating is probably the same. If you have druid working, you can send ^^v to crow for it to tell you its current firmware version, if this says 1.0.0-something you are currently up to date.

To adjust the threshold for the time being you can either:

  • execute the following after every time you load First (so after every power-on), until a new firmware is available with this change:
    input[1].threshold = 1.0
    input[1].mode = 'change'
    
  • OR modify First.lua, adding a , threshold = 1.0 here, and upload this as the user script. Uploading scripts may also give you some trouble right now, especially if you’re on OSX, this should also be improved in an upcoming firmware + druid update.

Good question, probably if it tries to modify your system path instead of the user path? I have basically always configured paths to Python binaries manually on Windows. I think sometimes it would configure the path for the Python binary but not pip? Really not sure off the top of my head what the Python installer does.

1 Like

Sorry, my question should’ve been more clear. I meant the fact that druid needs to be run as admin. Are regular users not allowed to connect to UARTs/modems?

I find that I am only able to upload (via r mostly, but I’m pretty sure this applies to u as well) once without a power cycle. That is, first upload goes fine, then second one hangs. Maybe once in a while I can get more than one without a power cycle, but I pretty much gave up on trying and just made the power cycle part of the process so I’m not sure how often this happens nor have figured out anything that might make it work sometimes but not others.

Is this the (or one of the) problems that will be addressed in the upcoming update you reference? If not, anyone involved please see my first paragraph for a bug report.:wink:

Speaking of bug reports. Should I just skip the forum and go strait to Github, or is it best to discuss it here first?

1 Like

Oh, nope, I don’t need to do this! One possibility is if you run it in a command prompt that defaults to a location like c:/ or c:/Windows it would fail to write log files or read scripts. Running from the user’s home directory ought to be fine.

Yes, this is hopefully much improved by some changes that should be in the next update. In particular you may find that it works better if you convert line endings of script files to \r\n instead of just \n, going forward druid will do this conversion during upload. Still not sure why but this seemed to resolve a lot of problems in my tests. There is also a change on the crow side that may improve this behavior.

Yeah, checking the GitHub issues pages for crow and druid may help to figure out if a problem is already known. I would say discussion here is probably good for figuring out weird behavior, if you have a reproducible bug report for a new problem then filing a GitHub issue sounds good to me.

1 Like

4 posts were merged into an existing topic: ^^ crow help: max and max for live

Thanks for this. Can confirm sending the command from Druid got First responding to my various gate sources. Happy it’s not broken :sweat_smile:

closing the loop: the default threshold for input changes is being updated to 1.0 in the upcoming release. this manual adjustment for ^^First to respond as expected to certain makers’ gates will not be necessary by this time next week!

2 Likes