^^ crow help: general (connectivity, device q's, ecosystem)

I’d recommend looking at the source for druid. It’s pretty short and concise. You can see the serial sending stuff here. There’s a lot of moving parts going on, and the serial port behaviour is platform dependent (below the python layer).

I’d also recommend reading crow’s readme-development document which outlines a number of considerations when building applications that talk to crow.

Additionally, there’s a work-in-progress electron app here that is covering similar territory I believe.

Regarding sending code, I would note specifically that using ^^s and ^^e will reset the lua environment every time, so they are designed for uploading whole scripts. If you want to send code to be executed in the Lua environment on top of the current state, you’ll need to use the ‘multiline’ characters (three backticks surrounding the code block, like markdown) to avoid evaluation errors. That input buffer is 2kB, but perhaps there is something else going on causing the 380 char limit.

If you have some way for us to observe the unresponsive state I should be able to debug what’s causing it, but it’s a little hard because none of my tools are able to send this right now. If you want to open a Github issue on the crow repo that’s probably the best way for us to look into this further, and not have it buried here.

Thanks for the links to the dev resources. It looks like line writer has a short pauses after every line. I’ll investigate strategies related to that.

I do understand the ^^s/e effects, I’m am only using that for uploading whole scripts. I just did a quick experiment with backticks and it seems to actually make it worse (i.e. I can send less code before hanging Crow).

I should have enough info to get me to beta. Once I have something that’s ready to share (so this isn’t just theoretical to everyone else) I’ll devote more effort to optimization.

That looks like an interesting project. Fortunately, I think there’s not too much overlap in our efforts.

Thanks much for your feedback.

Sorry if I ask this question that has an ansered somewhere else, I am still confuse about the i2c connection.

I have the following modules in my rack:
teletype (older version, green PCB)
just friends
w/ x 2
crow

How to connect them all? Besides the i2c cables what do I need?

Thanks!

Nothing else needed, just make sure everything is connected together. Your main i2c power is crow because the green PCB Teletype has weak i2c power. Just make sure that Crow has the latest firmware update installed on it (pull-up resistor power is on by default)

I would go Teletype-> Just Friends -> Crow -> w/

1 Like

20 characters of thanks @mlogger!

1 Like

N00b question here :slight_smile:

I’ve been getting inconsistent results with Norns as a “master clock” for my eurorack setup. Norns is running Awake, CLOCK OUT is set to YES, CROW CLOCK OUT is ON, OUTPUT is set to CROW OUT 1+2 and everything is updated, but when I try to send a clock signal from Crow outs 1+2 to Pamela’s New Workout CV1 IN I got the bpm constant jumping between random values. Is there anything else I need to configure on Norns or Crow for this to work?

That seems odd. I do this and have no trouble. Are you fully up to date on all firmware (Norns, crow, awake)?

Also, what is your ppqn setting on Pam’s?

I think so, Norns is running 191201, Awake is v2.0.0, Crow is updated to v1.0.2. The ppqn is set to CV and I’m using the CV1 IN, I tried sending the signal to the Clock in as well with no success

You’ll want to patch the clock to clk input on Pam’s and not cv. Then change ppqn parameter to something like 24ppqn, also experiment dropping down to something like 4ppqn.

Also, when you patch to clock in does Pam tell you there is a clock present?

Ok, I patched Crow’s outs 1 and 2 to Pam’s Clk in, also tried the different ppqn modes and it shows a message saying “ext clk: 029 unstable!” the bpm value keeps changing from 010 to 029 and 034. I’d like to clock everything to 60 bpm by the way. Are you running an updated firmware on Pam’s?

Not that I know of. I’ll try this tonight and let you know what I’m doing exactly.

1 Like

Ok, great! Thank you!

It’s been a while, and this may not be helpful but, I also had trouble syncing to Pams in the past and remember changing the PPQN until it finally locked in. Pams also never kept a stable clock. It always fluctuated even when I got the ppqn correct. The fluctuations were only fractions of a bpm but the screen was constantly changing and I thought something was wrong but that’s “just how it is” with Pams

It does say in the manual that Pam’s prefers to always be the primary clock source. There’s also some details about utilizing run for more accuracy though I haven’t figured that out/experimented yet.

That’s good to hear, man. I think I finally found a workaround. It’s a little bit messy but it works. I’m using a MIDI DIN - USB cabe/interface to send clock information from Norns to Digitakt, so it goes MIDI OUT from Digi to MIDI IN on Hexinverter’s Mutant Brain and from MB gate outs 11-12 to the respective Clk and Run input on Pams. The bpm is a little off though, the screen is showing 59 bpm when the whole project is in 60 bpm.

Yeah, I’ll try experimenting sending a gate out of the Mutant Brain and send it to the run input on Pams.

I’m having some trouble finding info on how I might send asl info to my crow in real time, was wondering if someone could give me their two cents;

I’m using less_concepts and want to use output 3 and 4 for LFO’s (not sure if they both can handle that, someone can correct me on that too). In i2c JF mode, the norns script has left the outputs free.

What would I need to do to assign an LFO to those front crow outputs and could I do that in real time without having to alter the norns lua script and relaunch it? Could I add the asl lines to the maiden command line? What would be a example of that?

My dream would be to use a TT command to just hijack those outputs through i2c, but from my understanding, that’s not possible yet…

for sure! this section of the norns crow studies should get you there. once you find the lfo settings you like, you can add them to initialize in less concepts when the JF option is chosen by placing the ASL commands + their corresponding crow.output[x]() calls here.

not yet, but I believe on the roadmap!

also, if you have any feedback about how to have served up those docs while you were searching for info, please let me know either here or dm. thanks so much! :slight_smile:

1 Like

Thanks, I’m going to hopefully have a chance to make it through the studies tonight. Been squeezing in crow time where I can. Been insanely busy and when I get to my setup I just wanna makes noise.

So, all in all I need to add LFO concepts to the script as an initialized function? Could I use both outputs 3 and 4 as LFO’s? I can’t inject it in real time (similar to how the live type might work on a teletype)? If so, that’d be something I’d be extremely interested in having in the timeline either through the maiden command line for now and hopefully through i2c communication with the teletype (oh how I wish I learned more programming!!!).

As for thoughts on the documentation, I’ve had a ton of thoughts about this over the last few months when driving back in to the monome scene and would love to share them! I’ll DM you for that to keep things relatively brief.

Gonna go check out the studies in a bit though. Thanks

you totally can! I wasn’t sure what your ideal use case was – you can either initialize through the script or through maiden’s command line. the commands are the same, either way.

dope! a lot has been shifting and gettin’ shaken up, so I’d be v happy to hear from fresh eyes + minds! looking forward to it :revolving_hearts:

1 Like