ahhh fantastic. <3 i will not ship code if i don’t understand why something works! i used this in arcologies. this was the final mystery… for now. thank you.

1 Like

Hey ya’ll. Having an issue with clocking norns via crow. Pam’s is sending a gate to crow input 1 at 83bpm. When I select “crow” from the clock menu in norns, it reverts back to 120 bpm no matter what I do. I’m running Awake, FWIW.

Are you sure you’re on Awake 2.4 and not 2.3? I remote helped @perbarfot yesterday and we found this to be the issue. I think 2.3 uses an old implementation of Crow sync.

Also, I think you have to wiggle the external clock to make Norns respond to the BPM. (Not sure this is correct though, only from memory of my own experience).

1 Like

Edit: Yeah- I’m up to date on Awake, norns OS, and Crow. Tried wiggling as well. Resets to 120bpm.

Like @vicimity wrote, I had a similar problem yesterday. I actually also had the latest version of Awake, but for me it helped to un-install and then re-install the script, and also restart Norns.

2 Likes

Fixed it! I had updated crow to 2.0 yesterday, but calling ^^version returned 1.0.2. Aha!

So, tried the update again, restarted everything, and viola!

3 Likes

Hello! I have a Crow on the way that I’d like to expand with two Ansibles via ii. It seems that the Crow 2.0 firmware enables addressing multiple Ansibles, but the Crow studies for Norns don’t indicate how to do so. Is this currently possible?

first test coding lua for crow. wanted to build a simple quantizer for my 0-ctrl. outputs 1-3 works as expected but output 4 which should output a chromatic scale tilts the base pitch up one step. any help appreciated.

function init()
  input[1]{ mode = 'stream', time = 0.001 }
  output[1].scale({0,2,4,7,9}, 12, 1.0) --major pentatonic
  output[2].scale({0,3,5,7,10}, 12, 1.0) --minor pentatonic
  output[3].scale({0,2,3,5,7,9,10}, 12, 1.0) --dorian
  output[4].scale({0,1,2,3,4,5,6,7,8,9,10,11}, 12, 1.0) --chromatic
end

input[1].stream = function()
  v = input[1].volts
  output[1].volts = v
  output[2].volts = v
  output[3].volts = v
  output[4].volts = v
end

edit: i realize this should probably be in another thread after seeing “norns” in the subject line. not sure how to move it to the right place after posting. sorry.

edit #2: i also want to add a slew function takingg values from input[2] and applying slew according to the input value. i get it working, kinda, but the lew sounds like it’s being quantized aswell.

The off by one error is likely due to a small voltage offset somewhere. The voltage windows for each semitone are only +/-42mV so it’s possible that’s being accumulated somewhere. You can work around this with a small offset before you assign to the output eg: output[4].volts = input[1].volts + 0.02.

Regarding slew, yes the slew will be quantized. This is by design so you can use slew & shape to create arpeggiations without explicitly timing each note.

If you want to quantize an input to an output, applying a quick slew as the notes transition you can do this with an input.scale mode. The syntax is the same but it creates an event in input[n].scale = function(s) ... end.

The limitation is each input can only be quantized to one scale unlike the 4 you have now.

You can always access input[n].volts regardless of input mode, so you can read the input level in a metro if you want to do something more complex.

At some point we could make the .scale methods into a standalone library (not linked to input or output), but it’s not currently on the radar.

2 Likes

i’m working on a script with norns that controls a CV sequence doing something like crow.input[1].mode("stream", .01); crow.input[1].stream = process_stream. what value can i set the interval for checking the pitch input without causing problems for either crow or supercollider?

i set the interval to 0.001 and was getting some assert errors like:

lua: /home/we/norns/lua/core/crow.lua:34: [string "norns.crow.stream(1,1.27441)..."]:6: ')' expected near <eof>
stack traceback:
	[C]: in function 'assert'
	/home/we/norns/lua/core/crow.lua:34: in function </home/we/norns/lua/core/crow.lua:30>

lowering the interval helps, but ends up getting into weird alias-ing territory when modulating the pitch by audio rate.

The bit rate for crow’s serial communication is 115200 bits per second. The default behavior for the stream event is for crow to send a message like ^^stream(1,1.27441)\r\n which is 21 bytes = 168 bits. So the maximum frequency this can be sent over the serial port is 115200 / 168 = 685.7 times a second, or once every 0.0014583 seconds. If your stream fires this frequently or faster, it is probably losing some data in the serial communication, which accounts for the error you’re showing from norns – it’s not getting the ^^stream(1,1.27441) message in the format it expects because the data is being sent faster than the communication channel can handle.

It’s possible to have a stream event run faster than this with code that runs entirely on crow and doesn’t send data over the serial port, but if you’re trying to drive a norns function this way then you can’t get quite this fast. crow is not really designed as an interface for audio rate modular signals. Even if you used some more compact binary encoding for the data, 115200 / 8 = 14400 means that you could only transmit 8 bit audio at 14400 samples per second at most.

1 Like

I hadn’t considered serial baud rate I thought there’d be a separate DAC limitation – that explanation makes perfect sense thanks!

1 Like

I’ll add that the input jacks currently only run at 1.5kHz sample rate, so there’s no point going faster than 0.00067s rate.

Not sure what you’re using the CV signal for in norns, but if you can use one of crow’s built-in input event detectors, it could drastically reduce the traffic passing through the different apps.

the context i was using it with was i made a little additive oscillator thing that i wanted to control with rene, since the output from rene is going to be quantized – i can probably use input[n].mode( 'scale', ...) as long as i don’t want any slew on the frequency of the oscillator, right?

i guess input[n].mode( 'change', ...) would allow the same but only for a given voltage precision, though i could add lag in supercollider to make up for any “stepping” you might encounter depending on the rate of change.

this was my first foray into messing with crow, so i was a little brain fogged by the end of it. it seems like polling will work but definitely either of those should feasibly work better.

I’ll add that the input jacks currently only run at 1.5kHz sample rate, so there’s no point going faster than 0.00067s rate.

cool, this is good to know as well, ty :slight_smile:

I’m truly embarrassed to be asking this here, but maybe someone can throw me a bone. Are there any other “just crow” apps besides the one it ships with? Where do you find or upload crow apps? I see all sorts of Norns apps that basically use crow as CV output - is there anything else cool currently to do with it?

1 Like

I think the best way at the moment is to look for the #crow tag in forum topics: https://llllllll.co/tag/crow - of course that will also include things that use or require norns et al.

I am a bit fuzzy on this myself, to be honest. The crow ecosystem is looser than norns/dust. There is the bowery repository which may have been intended as an umbrella for these apps, but as yet it doesn’t seem to include any beyond the core examples.

1 Like

There are quite a few scripts for just crow. You’ll want to get familiar with druid. From druid you can upload scripts. There is a repository called “bowery” with a good amount of crow scripts in it.

Start here: https://monome.org/docs/crow/

The coolest thing to do is to make your own scripts!

1 Like

Yes, this is the real joy of crow!

hi

this is a great question…check the thread below for druid scripts (crow standalone apps that dont require norns/max/something else to function)