#1

I’m getting some very strange behavior when connecting crow to norns. It seems like crow keeps running its script (in this cast, the default First script outputting 2 pitch/env pairs whenever a gate is received on input 1) even when it’s connected to norns. It’s doing this in addition to whatever commands my script sends it. I’ve tried calling crow.reset(), but that doesn’t seem to help.

Additionally, it seems that my crow <-> clock integration is basically broken. It’s worked a few times, but most of the time no matter what clock I send to crow input 1, it doesn’t change the tempo.

Maiden is showing now errors, crow.connected() returns true, so I don’t know what’s going wrong…

EDIT: callling crow.clear() when the script starts seems to have fixed all my issues… reading back through the thread this has affected a few people, so I’d love to hear if this is the “right” way to use Crow with norns, and if so it should probably be mentioned somewhere in the documentation

I’m also wondering how to be robust to crow disconnect/reconnects. If I unplug my crow, then plug it back in, it seems to no longer send or receive any values. Interestingly, its ability to detect clock seems to keep working, so there’s probably something that the main norns system is doing to fix this that I could port into my script :thinking:

^^ crow help: norns
#2

Can you confirm what version of crow firmware (crow.version()) and what norns software release you’re working with?

It appears that what this function does is causes crow to evaluate this function, which resets crow’s input handlers, clears crow’s metros, and zeros the outputs but does not otherwise clear the script. This gets run when a norns script initializes or when a crow device is added (here) so it seems odd that this would need to be called manually during your norns script’s init function, but the behavior you describe seems consistent with crow.reset() not being sent and hence crow still using the input handlers from the First script. When I have first loaded and connect crow to norns, matron prints:

>>>>>> norns.crow.add / 2 / crow: telephone line

and crow stops outputting envelopes / doing First stuff. Additional disconnects / reconnects show:

>>>>>> norns.crow.remove 2
>>>>>> norns.crow.add / 3 / crow: telephone line

I have yet to learn about the clock system so I can’t really advise here but I would guess that this could also be explained by norns not setting up some default code to run on crow when your crow is connected.

This was always returning true due to a bug but this should have been fixed in the 200604 update. But maybe the connection detection logic is not working or something, hence crow.reset() not getting re-run?

Yeah this will clear the crow userscript from flash and reset crow’s Lua VM. As such it is not probably a good thing to do in norns scripts intended for public distribution since it might wipe out a stored script.

2 Likes
#3

crow v1.0.0, norns 200604. I just got this crow brand new a bit more than a week ago, so I assumed it was on the latest (which https://github.com/monome/crow/releases shows as v1.0.3), but I guess not. I’ll update to v1.0.3 and see if that fixes things.

Yeah, crow.reset() didn’t help, it was crow.clear() that did.

I get the same printout, and at first crow stops running First. But if I switch norns scripts, crow goes back to doing First stuff

That makes sense, but it also seems to be the only way to get crow to stop running whatever user script it has on it, at least for v1.0.0. I’ll update to v1.0.3 and see if that fixes the issue.

Thanks for the thorough reply!

EDIT: updated to v1.0.3, no change in behavior. To quickly summarize repro steps:

  1. Make sure the user script on crow is First, crow and norns are powered on, not yet connected
  2. Get sound from First (send a clock to crow input 1, send outputs 1 and 2 to a vco v/oct input and a vca cv input, respectively)
  3. Connect crow to your norns, hear First stop running
  4. Go to norns menu, select a different script, launch that other script
    :boom: First resumes running. If the script you just launched uses crow, its communication with crow will be added to First’s behavior, rather than replacing it. Also, the crow->norns clock connection is broken: the tempo norns sees doesn’t match the tempo crow is being sent, and changing the tempo of the clock gate that crow is receiving results in no changes on norns’ end (although it does change the speed at which First runs)

2nd EDIT: this seems to only affect some scripts. Here’s the minimal reproduction script I’ve found:

function init()
  for track=1,4 do
    crow.output[track].action = "ar()"
  end
end

(as in that’s literally the entire norns script). Upload that script to your norns, then follow the reproduction steps listed above, and where the steps say “select a different script”, select this minimal reproduction script.

2 Likes
#4

Thanks for the procedure. I’m not actually able to reproduce this behavior at these versions with this script, unfortunately – First stays stopped until I explicitly restart the crow firmware by sending ^^r. Quite puzzled by this at this point!

#5

spent some time this morning testing and i believe there’s something wonky happening when redefining the norns clock source. if norns clock is already set to internal when loading the test script, then everything works as expected – eg. First stops running, each of crow’s outputs are AR envelopes and can be triggered with crow.output[x]() messages in the REPL.

however, as soon as the norns clock source is changed to crow, i get the described behavior. i’m running 200604 on norns and the public 1.0.3 crow firmware.

here were my steps
  • had awake loaded on norns, First running on crow, both disconnected from the other
    • norns clock set to internal
  • connected crow to norns, First stopped running
    • switched from awake to the test script, still nothing
    • executing crow.output[3]() in repl produced AR envelopes
  • changed norns clock to crow, First restarted and executing crow.output[3]() in repl would not produce an AR envelope
  • changed norns clock back to internal, First continued running
    • executed crow.init() in maiden repl, first stopped
    • switched norns clock to crow, First’s out 1 action (v/8) restarted though i did not see pulses from out 2
  • reran the test script with norns clock set to crow, First restarted with both v/8 (out 1) and pulses (out 2)

additionally: from the clock code, it seems that crow.input[1].mode("change",2,0.1,"rising") gets executed when source is set to crow – executing this in the repl with the test script + clock source set to internal (the known “good” state from my testing) immediately re-enables First’s actions

(edit: @21echoes + @csboling, made a standalone thread for this)

2 Likes
#6

I can dig into this soon. I hVent looked at the way crow-clock is being activated but it seems like there’s a bug there somewhere!

2 Likes
#7

Awesome work! I can confirm that I’ve had clock in crow follow mode the whole time, so that matches my experience. To be clear: I’m not switching from not-crow-clock to crow-clock at some point during the steps I listed, the norns is just in crow-clock mode as effectively step 0 and just stays there throughout the reproduction steps.

#8

The clock code just turns on the change mode on crow again.

The issue here is that First redefines that change event to control things internally on crow, rather than send the default message to norns. I’m going to change this behaviour so that the crow.reset function doesn’t just set input[n].mode = 'none' but also resets the event to the default usb message.

5 Likes
#9

confirmed fixed in (edit for clarity) crow release candidate! thanks @Galapagoose for the quick push :slight_smile:

1 Like
#10

To clarify – in the upcoming norns release, this bug will be fixed? No crow update needed? And does my norns script need to explicitly call crow.reset or anything, or will everything Just Work?

#11

@21echoes, it was addressed on crow’s side, but you’ll want to update norns + crow when the updates are simul-released :revolving_hearts:

you won’t need to explicitly call anything in your script, beyond the standard input/output definitions as you outlined in your repro script :slight_smile:

1 Like