#70

Revisiting the situation and everything is working. Probably missed something yesterday. Thanks for your help.

1 Like
#71

This is probably expected behaviour/user error but:
I’m using the shift register script on crow to control JF by I2C. A couple of odd things happen:

  1. I don’t understand how to stop JF responding to Crow without restarting the module. I can change the script on Crow, but it still continues to pulse like it is receiving a clock, emitting sound but the pitch not changing. I can address by JF Synth in Max, and that will play it, but the pulse still doesn’t go away. So is there a Crow/Druid command that will reset JF back to its normal state?

  2. There could be many explanations for this. I can put a quantised random voltage into the shift register, and it will play fine and keep in tune. But if I feed it an output from Ansible (Kria), it’ll go wildly out of tune. The same sequence straight into JF is fine.

I think I’m looking for an answer to the first, and speculation on the second! Thanks all.

#72

To get out of synthesis mode you can send this message from druid ii.jf.mode(0).

Not sure about the second question.

2 Likes
#73

Is crow capable of jack detection?

#74

Same/similar question. Looking to “normalize” input 1 to input 2 when nothing is plugged into input 2. Could not find anything in the docs.

If not directly supported maybe there is a clever programmatic way to a chive this?

#75

@Galapagoose @csboling I am having an issue with Ansible playing 2 x JF with an Arc and wondering if it is Crow related. I have a Crow / Teletype / er301 / w/ also on the bus but not running any script. Once first set up, JF works fine activated in Ansible. The problem is whenever I reboot.

If I reboot, JF does not come back to synth mode and very difficult to get back to synth mode. It doesn’t lock up, but the synth mode is lost. The correct JF settings are still there in Ansible. Changing the JF setting in the system menu on Ansible after reboot, has no effect. The only way I can get JF back to synth mode is to send II.jf.mode(0) in Druid. I tried sending a mode change via Teletype but no effect, only via Crow worked. Reboots didn’t get JF synth mode back.

Not sure if it’s an Ansible issue, JF, or Crow. I’m on the latest firmware on all those modules. I was wondering if Crow is somehow running something on reboot that is reseting Just Friends and stopping the Ansible script working. Like a boot sequence that overrides Ansible.

I tried changing the Ansible system menu to select er301 after one of these reboots and that has no effect. Basically the whole of the i2c bit of Ansible is unresponsive after a reboot. The II.jf.mode(0) from Crow seems to clear the whole i2c line.

The only other thing I could think of was pulling too much power off the bus? I recently added 2nd JF to the case. I do have a powered backpack running and also Crow with pull up power. It’s just weird because it only happens after a reboot and when Ansible i2c modules are selected

Just Friends v4.0
#76

You could set a metro, check if the input is 0V, and increment a counter if it is. Anything other than zero clears the counter. Then trigger your function if your counter gets past a threshold.

1 Like
#77

Hi --I am thinking about trying out crow in my small eurorack system and was wondering if it’s possible to use it get polyphony from Just Friends without Max/Live. Is this something I can do using druid?

Also, has anyone done anything interesting with Reaper and crow?

#78

Yar! I believe that is precisely the theme of this episode of Maps w/ Trent.

1 Like
#79

Oh awesome! I didn’t know that existed and will check it out now. Thanks!

#80

This sounds kind of like something in Ansible’s i2c code got messed up during startup and after that it can’t send i2c commands, or something like that. If you have leader mode activated in your saved Ansible settings then it will try to set JF.MODE 1 as soon as Ansible starts up, if you have a large I2C bus I can see how sending a message during power up could maybe be problematic. However turning off all followers should cause Ansible to change to follower mode, which for the most part resets Ansible’s i2c driver, so it’s odd that this is having no effect. This is possibly difficult to reproduce given that it most likely depends on your i2c configuration, but I can try.

In particular I’m dimly aware of some issues where ER301 takes a while to be ready to accept i2c commands during startup, so I wonder if this could be related, but I’m not an ER301 user. I realize messing with one’s i2c bus can be a bit of an ordeal but it might help narrow down the problem if you can identify which maximum set of modules it still works correctly for, like “with modules X Y and Z connected it works, but after I add module Q it breaks”.

#81

Thanks, I tried again today. On reboot, both JF still didn’t default to synth mode I left it in. This time however, i managed to get them working by repressed the exact same JF lit settings for pitch and mode.

It’s interesting what you say about the er301 - that could be it. I’ll try turning off the i2c in the boot up system setting on the ER301. Then switch it on afterwards.

Update - i disabled the er301 i2c but still no joy with Ansible keeping JF settings on my system after rebooting. And again changing any of those system i2c settings in Ansible has no effect, the same as my original post.

i’ve open Druid and typed ii.jf.mode(0)
i get this error
ii: lines are low.
check ii devices are connected correctly
check no ii devices are frozen

i am pretty sure my lines aren’t low and correctly connected, but there are a lot of devices on my i2c that could be conflicting somehow after a reboot when connected to Ansible. Both JF aren’t frozen as they light up when switched to cycle. Ansible isn’t frozen as the output lights are working. As a test i connected Norns to Crow and tried the Awake script with JF as output but no go.
What is interesting is both Just Friends after a reboot sometimes play for 1 sec then cut out and stop.

Update : i took off er301 and the second Just Friends from my i2c.
I still have the same issue with Ansible after rebooting - i have to reselect the i2c for JF. Its seems like that setting is being overwridden on reboot

Just Friends v4.0
#82

Suddenly i have a error on my crow.
I now get
!ERROR! Out of memory
upload failed returning to normal mode

I get this when i want to upload any script (so even really small ones)
How can i fix this?

#83

This error is sent (from here) when crow fails to allocate memory for the new script you’re trying to upload. This could be due to the existing script on the device using up all available RAM. If you use the p command in druid to print out the currently uploaded script this may be helpful for understanding how all memory is getting consumed. To get out of this state I would expect the following to work:

  • send ^^c to clear the user script and reset the Lua VM
  • try uploading your script again

If this is still failing try restarting your system after the ^^c was sent.

1 Like
#84

Thx this worked out. I think i kind of hit the limit with the script im using right now.
Time to rework some parts.

#85

Here i am again :roll_eyes: It all worked fine until yesterday then my crow got unresponsive and now i cant get it connected to druid either so there is no way to run a clear or a reset. What to do in this situation?

#86

Hey all, first post here. I’m barely more than a novice with programming in general and this is my first exposure to LUA beyond modding Battle for Wesnoth as a tween!

I’ve been going through all of Trent’s livestreams since I got my Crow last week, and I really wanted to try modifying this script: geode ii script. Druid is up to date, Crow is on 2.0. It seems that the update broke this script. It runs for a number of counter cycles and then stops, soft-locking crow and doing unpredictable things to druid (I can elaborate if desired but I’m mostly concerned with trying to figure out how to maneuver in the latest version).

My question is: how can I refactor this script to run on Crow 2.0? I checked the changelog on github and I’d guess that it has to do with the breaking change re: ii commands, but I can’t find much more info about those changes or how to update older scripts for compatibility.

For what it’s worth: I want to procedurally vary divisions/repeats per geode voice, per certain number of clock ticks, which I think I can figure out as soon as I can get the script working in the first place.

Any help is appreciated! Thanks for reading my verbose post!

#87

This is actually a bug in crow that is on our radar. You can’t alias an ii device before using it.

The fix is either

  1. Remove the j = ii.jf and change all the j. to ii.jf.
  2. Add a line at the top of the script which uses jf before aliasing. Looks like
ii.jf.trigger(0, 0) -- could be any ii.jf command
j = ii.jf -- alias

Either should stop the crash after a few seconds issue. The script is otherwise 2.0 ok.

2 Likes
#88

Force the bootloader and run the ‘erase userscript’ file that comes in the firmware zip. This has usually gotten me out of that state

#89

does anyone know if it’s possible to control a meadowphysics (non ansible meadowphysics version) via i2c with crow?