ansible firmware updates

Monome
1

ansible 3.1.2

→ instructions and update link

  • FIX kria out-of-bounds access on pattern + prob page @csboling
  • FIX kria metapattern out of bounds and levels ii @csboling
  • NEW 256 grid support for kria and earthsea @Dewb
  • FIX add a bootup delay when in leader mode @scanner_darkly
  • FIX usb presets: fix reading of split numbers @csboling
30 Likes
2

20 char of thanks all!

1 Like
3

Thanks for the update ! Just a heads up : I got confused because the update reverted my settings to synchronized loop sync. A quick look at kria | monome/docs did the trick, as it’s not a setting I often change.

edit : I was also wondering if it could be possible to check the firmware version of Ansible or other modules like White Whale, etc. with a Teletype command, provided the modules are on the same i2c bus. It could be useful to do a quick check or for troubleshooting. Just an idea.

4

Just got around to updating my 2 Ansibles. Thanks to everyone ever who has contributed to this tight little module.

1 Like
5

I think that I’ve updated it with v3.1.2, but when I check FW using USB method but it showed
v3.1.1-d105733

It doesn’t seem to be v3.1.2 :no_mouth:

Any idea?

The update process seemed to be ok:
admin@Mac ~ % /Users/admin/Downloads/ansible/update-firmware.command ; exit;
Checking memory from 0x2000 to 0x7FFFF… Not blank at 0x2001.
Erasing flash… Success
Checking memory from 0x2000 to 0x7FFFF… Empty.
Checking memory from 0x2000 to 0x21DFF… Empty.
0% 100% Programming 0x1FE00 bytes…
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>] Success
0% 100% Reading 0x7E000 bytes…
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>] Success
Validating… Success
0x1FE00 bytes written into 0x7E000 bytes memory (25.30%).

Saving session…
…copying shared history…
…saving history…truncating history files…
…completed.

[Process completed]

6

yo, had some issues with the current ii implementation in regards to crow and w/syn.
made a post over here about the issues i’m having but i think this is the more relevant thread to post some of my findings in.
tldr;

  • crow’s ii as two CV/Gate pairs is not working at all, outputting no signals
  • w/syn’s ii communication gets bricked if you try to swap modes without disabling w/syn in the ii menu first, requiring a full power cycle to re-enable
    • this includes unplugging grid and plugging in a generic midi device
    • as a result/example, if i want to use midi to play w/syn polyphonically, i have to load up kria on a grid, enable ii for w/syn, unplug grid and plug in a midi keyboard, then full power cycle the case with the midi still plugged in, and then i can play it. sometimes re-bricks itself if i try to swap between midi modes.
  • crow’s operating mode menu doesn’t seem to exist? no buttons are lit up in the top right, even though the docs suggest that it has multiple modes.

if i had to hazard a guess, i’d probably say that there’s some issue that cropped up with resetting ii followers on mode changes when the crow or w/syn implementation was added. if i was any better at programming, I’d try helping out myself, but alas, i am not :pensive:

7

I think I’ve noticed something off with how Ansible works with i2c followers. It might be intentional, but I wanted to check.

I have a bus that includes Ansible, Teletype, JF, W/, and Disting EX (Plaits mode). Things are largely running smoothly on the bus. Each module is updated to its respective latest firmware version.

When I use Ansible as a leader, the same pitch sent to JF, W/, and Disting are all in different octaves. I set up a scale that only outputs one pitch (D in my case), and started using each of the devices as followers. If I’m assuming JF is correct, then the same note sent to the Disting is one octave higher, and the same note sent to W/ is 3 octaves higher.

What’s interesting (to me anyway) is the same thing isn’t true when Teletype is sending note events. The same note event (or at least sending N 7 or whatever to each device) results in the same note in the same octave on each device.

I can resolve this with octave adjustment in the Ansible follower config, so it’s only so much of a problem. But, it does mean that when lead by Ansible, the W/ for example has a fairly limited range and can’t reach into lower registers.

Again, this might be intentional, or it might be documented somewhere that I wasn’t able to turn up. Still, I thought I would bring it up. This seemed like the right place since the devices act as I expect when the notes come from Teletype, so Ansible might be the thing at issue here.

Thanks for any info!

edit: I’m away for the weekend but I can see that this file is almost certainly where changes could be made to affect this: ansible/ansible_ii_leader.c at main · monome/ansible · GitHub

When I’m back I can set up the firmware toolchain and experiment with those, to try and bring the values in line (at least with what I expect).

2 Likes