#41

That looks correct if you used the ‘update.command’ script in the release. You should be able to close the terminal, and open a new one to talk via druid.

1 Like
#42

Thanks. I quit terminal and relaunched it, and it seems to be working now!

One question, I just downloaded the most recent Bowery version, but the dates on the files are earlier than the dates on the earlier version already on my Mac. Any idea why that would be the case?

#43

hey everyone! new norns and crow user here having some trouble getting crow to work. bought a few months ago and didn’t use it waiting for norns to restock. downloaded crow 2.0 in less than a few minutes and spent the day uploading scripts from the bowery with no problem.

norns came the next day and have been having all kinds of problems with it (norns), and now when I try to use crow a few days later, I can’t connect to druid, m4l or norns. it’s more than likely that I uploaded a bad script onto crow through druid - tried to force the bootloader and run erase_userscript/few different usb cables/run crow.clear() and reset in maiden with no luck a bunch of times, but I do get voltage out of crow. running awake on norns with output to crow 1 & 2, mangrove v/8 gives me a high pitched gargling noise with both freq knobs on mangrove at ccw.

any help here getting setup and running would be greatly appreciated as most of the suggestions I tried seemed to work for others. thanks!

#44

Not sure if this is the best place to ask this but I’m just curious if anyone out there is using both crow and teletype in tandem? I have both but am using them in separate setups. I’m planning out a very monome/mannequins centric case with multiples of most of the mannequins modules and I’m wondering if it would be cool to have both or if it would be overkill. Mostly just doing some pre-planning because it’s a pain to swap out i2c connections.

^^ crow 2.0.0
#45

I use both - I’ve not seen any i2c commands that let one talk to the other but I have crow, w/, f8r , Txi , TT and ansible all running off a backboard on the TT and I normally do something like using the ansible trigger out from Crow to fire scripts on TT via a patch cable (or something like that depends what I’m up to)

I normally don’t let both Crow and TT talk to the same device but I occasionally notice that I’ve got scripts running that both read Txi or F8r - with seemingly no ill effects BUT I’m pretty sure the behaviour would be “undefined” at best so to be avoiding I suspect

The way I normally use them both is playing different parts - so as an example I have a rhythm generator script running on Crow and then using TT to make some kind of bassline but obviously the sky is the limit - generate envelopes on the crow and pitches with the TT

2 Likes
#46

This sounds like probably what is going on. What is your computer operating system? There are a few different driver / permissions things that can make accessing the bootloader work somewhat differently on different platforms.

#47

macOS 10.12.6 (older macbook air)

#48

it seems time to email help@monome.org and we can assess, very sorry for the trouble

#49

Thanks Brian. Will do.

#50

Is anyone else using a crow and a 16n faderbank to control Just Friends?

I’ve been trying to poll the faderbank and update each JF voice independently to get simple drone like synth control going - as a proof of concept for more complex things, but I’m finding things very unstable. Not sure if it is my code, or some other issue.

The behaviour I’m seeing is that the script will run and then lock up and ii commands stop responding. Occasionally I’ve seen error messages about the ii lines being low, which I understand can also be an indicator of the ii bus being overloaded.

I’ve only got the crow, Just Friends and the 16n on this ii bus - no other modules. The 16n is connected via a passive DIY connector that converts from the TRS jack to i2c. It works fine when I query the 16n interactively from druid. AFAIK, hardware-wise, I don’t need a powered bus for this config, but maybe I do??

On the scripting front, it seems that if I try polling too quickly, things lock up. Even at a poll rate of 0.5 sec, which is very slow, this script works for a bit and then locks up. I’ve seen the ER301 16n script set to poll the 16n at 0.02sec, so I figure I’m doing something wrong here.

Here’s the basic script I’m using. Any suggestions welcome.

Metro[1] polls the 16n, one fader at a time, and stores pitch and volume levels.
Metro[2] updates JF voices (one at a time) with the relevant pitch and volume levels.

function init()
    ii.jf.mode(1)
    metro[1].time = 0.5 
    metro[2].time = 0.5 
end

pitch = {0,0,0,0,0,0}
vol =   {0,0,0,0,0,0}


ii.faders.event = function( e, value)
    if e.name == 1 then
        pitch[1] = value
    elseif e.name == 2 then
        pitch[2] = value
    elseif e.name == 3 then
        pitch[3] = value
    elseif e.name == 4 then
        pitch[4] = value
    elseif e.name == 5 then
        pitch[5] = value
    elseif e.name == 6 then
        pitch[6] = value
    elseif e.name == 9 then
        vol[1] = value
    elseif e.name == 10 then
        vol[2] = value
    elseif e.name == 11 then
        vol[3] = value
    elseif e.name == 12 then
        vol[4] = value
    elseif e.name == 13 then
        vol[5] = value
    elseif e.name == 14 then
        vol[6] = value
    end
end

metro[1].event = function()
    ii.faders[1].get(next_fader)
    if next_fader >= 16 then
        next_fader = 1
    else
        next_fader = next_fader + 1
    end
end

metro[2].event = function(c)
    f=c%6+1
    ii.jf.play_voice(f,pitch[f],vol[f])
end

metro[1]:start()       
metro[2]:start()
#51

I’ve used some similar scripts with success down past 20ms update frequency. I did have stability issues at the time but I chalked it up to having multiple bus leaders. Are there only three devices on your bus? Do you have pull-ups on the 16n, the crow, or both?

What I’m seeing in your script looks like you are pre crow 2.0. You should update crow and JF both, then check out the new crow i2c getter where the events now return the input arguments.

1 Like
#53

+1 for firmware update – the 2.0 update states explicitly that it increases stability with 16n.

Was having a similar issue last night and the update fixed it.

2 Likes
#54

Not sure what you’re seeing that looks pre2.0? The e.name usage in the ii.event function has only existed since 2.0. Do make sure Just Friends is up to v4.0 as that helped with ii stability a lot.

I’d guess it comes down to a bus stability issue. The 16n is unfortunately a device that I haven’t been able to test with personally.

Not sure if it speaks to ii stability, but FYI the way you start the metros at the bottom of the script is actually starting them before they’ve been configured. I’d encourage you to move the metro:start() calls to the end of the init function.

I’d focus on bus stability as the likely problem as there’s nothing particularly strange or processor intensive in the script. How long is your TRS cable to the 16n? Try the shortest one you have (to see if it helps stability). You might need to get a powered bus-board of some kind. I believe Teensy powered devices (like 16n) put particularly high capacitance on the ii lines, requiring higher pullup current.

1 Like
#55

Oh I missed the e.name calls! Yeah that looks like 2.0.

I really want to test out the latest crow + JF combo… Geode is calling to me!

#56

Breaking into Crow and feeling a bit at a loss. The documentation is excellent, and given the plethora of configurations it makes sense that there’s not necessarily a set path per use case. Looking for guidance on executing a specific idea // generally upping my understanding of what exactly is / isn’t possible. I know that it’s a ‘just jump in’ situation, but I’m coming up all dead ends at the moment, and have spent much of the day (and last night) looking for answers. I’ve broken it up into phases but that’s as far as I’ve gotten:

  1. Get JF in Synthesis mode running off Kria through Crow (I know Kria has to be in leader mode, with the dots for Crow + JF lit but I’m not sure how to get Crow to receive Kria triggers and turn them into notes without patching Kria trigs directly to Crow’s ins and accepting the two-track limitation).

  2. Rig up the 16n Faderbank for per-track probability control, metro time (both continuous and divisions) plus pattern select. Currently not aspiring to metro times sub-100 ms, because instability.

  3. Add a second JF triggering in the scheme off track 4 (bass). (this seems like the easy part, despite being the ‘newest’ functionality)

This is part of an ongoing project to streamline a patch I first put together ~ a year ago that just… still gets me, despite being pretty simple conceptually.

I also understand if this is in some way too vague – I’m just not even sure if it’s possible.

What… tacking ought I to take to be able to accomplish something like this? Break the functionality up across a series of scripts and then attempt to combine them? Make my list more granular and add things one at a time?

It’s sort of a… meta-level approach to coding kind of question, I guess. It’s completely uncharted territory for me BUT I see the potential for designing instruments and would like the skill set it takes to more actively contribute here as a coder // beta-tester (not to mention the utility for my personal creative practice).

#57

Sounds like you want both Kria and crow as leaders. Can you poll Kria in follower mode to get the info you need? You would have to poll fast to get acceptable latency/jitter.

1 Like
#58

I could tie the polling to the metro (thinking ~100 is my threshold on that – is this fast enough?) so that Crow checks for a trig every tick of the metro. Ideally the metro would be swinging – I’ve been using @shellfritsch 's ez / flip method for swing on TT; would something similar work with Crow?

Should I just devote a week or so to learning lua outright and then print a reference for Crow scripts?

If Kria’s in leader mode, how do I get Crow to receive its triggers – or is this also possible in follower mode, since Crow is, per Sam’s foreword, “always listening”?

There’s a real chance I’ve missed a doc or something somewhere, too (although I doubt it).

#59

One thing that might be useful for what I think you’re trying to do (but has not been implemented yet) is to have Ansible send some type of ii messages to crow for note events. For instance Ansible would send a ii.crow.call4 message that passes (track, tr_state, pitch, duration) or so and you could handle this with arbitrary Lua code on the crow side.

1 Like
#60

That would do it, yup.

As it stands, can Crow receive the ansible triggers over I2C directly, or does it have to poll the trig outs at some regular interval to catch gate high?

#61

Correct, there is not currently any code in Ansible leader mode for sending ii messages to crow.

1 Like