When crow connects to norns, we ‘reset’ the crow virtual machine, stopping any currently running script. This is by design, and was implemented a while back because it became very confusing to people when they tried to run a norns script with crow integration and it was partially still doing the ‘crow-script’ thing, plus whatever the norns script added on top.

We don’t clear the script on crow when connecting to norns, simply deactivating it instead. That script is still available though, hence my suggestion of simply running crow.send "init()" which tells crow to run it’s internal init() function that the crow script should define.

One thing to note, whenever you load a new norns script, the crow environment is reset. This means you could have a script that just executes the above line, but as soon as you reload another script to have norns do anything, it will disable crow again.

From your message it sounds like the above is not working correctly, but I’m having a hard time understand what is happening vs what you’re expecting. If you could run through what happens on crow before you attach it norns, then when you connect to norns, and again when you run the crow.send "init()" command. If you could post the crow script you’re using that’d be super helpful too. I looked at Cyrene and nothing in there suggests it would break this functionality.

I know you say it’s not a big issue for you, but I think it should work, and perhaps there is a tiny fix that needs to be made to make it act as expected.

3 Likes

Hi, I was just wondering what Norns scripts would be best suited to pass clock from Ableton Link to Crow? I’m a new Crow user and unsure about the capabilities of the current scripts with existing Crow support. Thanks!

none needed! :slight_smile:

  • in the CLOCK menu, select source link to get norns synced up with Live
  • scroll down to crow out and select an output to send a pulse at the specified crow out div

oh right, totally spaced on this – could the three line crow init function posted above actually just be getting swallowed? since it sounds like @jasper_ryder is looking for a laptop-less way to do this, maybe it’d be easier to assign a norns key to crow.send("init()")? that way crow is reset at norns script launch and the key press can reinitialize the crow script?

2 Likes

Hi @Galapagoose. Thanks for the reply.

When crow connects to norns, we ‘reset’ the crow virtual machine, stopping any currently running script. This is by design, and was implemented a while back because it became very confusing to people when they tried to run a norns script with crow integration and it was partially still doing the ‘crow-script’ thing, plus whatever the norns script added on top.

I mentioned that crow did this when Norns usb was connected because in my brain it seems like as long as Crow has that usb connection it is in a “Norns” mode and so far I haven’t been able to get crow to run it’s “memory script” when in “Norns” mode.

We don’t clear the script on crow when connecting to norns, simply deactivating it instead. That script is still available though, hence my suggestion of simply running crow.send “init()” which tells crow to run it’s internal init() function that the crow script should define.

Yes yes, now if we can reactivate it as easy from Norns! So far the crow.send “init()” hasn’t fully gotten there for me.

One thing to note, whenever you load a new norns script, the crow environment is reset. This means you could have a script that just executes the above line, but as soon as you reload another script to have norns do anything, it will disable crow again.

I guess what I would do then is initialize Crow’s “memory script” then simply unplug Crow from Norns. That way Crow would be doing it’s internal script and I could then select a Norns script without any issue.

Now that I think about that, if simply unplugging the usb connection between Crow and Norns could re-initialize Crow that would work fine for me.

From your message it sounds like the above is not working correctly, but I’m having a hard time understand what is happening vs what you’re expecting. If you could run through what happens on crow before you attach it norns, then when you connect to norns, and again when you run the crow.send “init()” command. If you could post the crow script you’re using that’d be super helpful too. I looked at Cyrene and nothing in there suggests it would break this functionality.

Yes I used Cyrene in the example because I have been using it a lot lately so I wanted to see if I could go from that script running to initializing Crow easily.

So to try and keep this clear, when I run the crow.send “init()” script, Crow “resets”. Which is to say it stops outputting any script on it’s outputs, but it does continue to output Norns clock signal (on output 4). This happens regardless of running it while having a Norns script running or from “none”. Does that make sense? So Crow just doesn’t go that extra step to running it’s “memory script” it seems.

Now as far as before I attach Norns to Crow; lately I power up the rig all together. Crow powers on with a usb connection to Norns and is in “Norns mode”. If I power up Crow without a usb connection to Norns, Crow plays it’s “memory script”.

The current script I have on Crow is: 0-ctrl crow.lua (426 Bytes)

Ok, I think I understand the issues here. Thanks for posting the crow script as it helped a lot.

Firstly regarding the clock on output 4, this is managed by the norns system itself, not a specific script, so it make sense that it would continue. If you want to turn that off automatically when switching to crow’s internal script, you can set that param directly but I don’t know how to do that (though I know it is possible).

The problem with the script is not that it isn’t running, but that the input[2].change handler has been overwritten by Cyrene. You can get around this by giving your event handler a name, and then reassigning that inside the init() function, like so:

0-ctrl crow. restartable
function init()
  input[1].mode( 'scale', {0,3,5,7,10}, 12, 1.0 )
  input[2].change = change_handler -- forces update when crow env is dirty
  input[2]{ mode = 'change', direction ='rising'}
end

count = 0

change_handler = function()
  v = input[1].volts
  if math.random(100) > 50 then
    output[1].volts = ((v * 12) + 5) / 12
  else
    output[1].volts = v
  end
  output[2](pulse())
  count = count + 1
  if count >= 5 then
    count = 0
    output[3].volts = v
    output[4](pulse())
  end
end

I looked for a way to reset the Lua environment on crow without triggering norns to capture control, but I think it would require a firmware update, so the above seems the best option for now.

1 Like

Edit: The altered script works very well. Thanks! Would, for example, the bowery scripts require a similar tactic as well?

Thanks @Galapagoose,

I’ll give this a try this evening. :grinning:

A post was merged into an existing topic: ^^ crow 2.0+ help: general (connectivity, device q’s, ecosystem)

Really loving using Crow with Norns, but seem to have some variability with how the gates behave.

Some scripts seem to trigger envelopes perfectly (Circles) but others (Awake, Flora) either seem to double trigger or completely hang at higher tempo’s. The only way I can get them to work accurately is by attenuating the gate signal first. Is this normal, or am I missing something?

hi! can anyone help me out with this issue? it’s about norns and crow connection. I would be very thankful!