Ansible Development and Beta Firmware Discussion

What do you mean with just “div sync” here?

That’s why I was so happy to see these changes :slight_smile: The combination of all or per track time division sync and time division queuing means I can finally use the time divisions again :tada: and be a lot more deliberate in my choices/action/influence on what’s happening.
Whilst I do sometimes like to be less in control and see where the phasing brings me, most of the time I do want the control, so this makes Kria a lot better for how I’d like to use it :slight_smile:
Anyway, long winded way to say thank you and to confirm that just playing with it and trying it out is a good idea to figure out what makes sense.

That’s probably a good idea :slight_smile:
I’ve been considering an option to trigger once every x loops similar in UI/UX to the probability page.
Let’s say a range of 1-7 (or maybe 1,2,3,4,5,6,8?), with 7 being the top row and 1 being the row before the bottom row.
When selecting this the step only triggers every x loops, where x is the selected number.
This would allow a combination of faster/frequent triggers and sparser triggers that are not random.

It might be that it’s expected behavior and the behavior described in the above quote, but I noticed the duration for triggers with deleted ratchet steps was shorter than for steps that didn’t have any deleted ratchet steps.
Is this to be expected? Should I have deleted the rests? I couldn’t figure out how to delete them from the UI/naturally. Found it a bit odd they stayed around/dimly lit and I wasn’t able to get back to the original state with them being off.
Maybe just pressing on the bottom row should delete them?

  • Pressing the bottom row will reduce the number of total subdivisions
  • Long-pressing the bottom row will clear everything, bringing you back the default one-trigger behavior for that step
  • Pressing the top row will increase subdivisions
  • Long-pressing the top row will eliminate all rests at the end of a step

These are very dimly lit because I didn’t want them to be too obtrusive but they probably ought to jump out a bit more.

I’ll look into the duration issue, not sure what I expect to be happening here – the duration calculation I think is unchanged from previous ratcheting behavior.

I agree that this is a funky part of the UI, and I have gone back and forth a little bit trying to figure out what the most sensible behavior is – maybe it should just never give you rests at the end of a step unless you specifically opt in to this by increasing subdivisions. But I also wanted enabling/disabling notes to be very playable, to allow experimenting in real time with different rhythmic patterns, and it seemed like reducing subdivisions automatically could cause unwanted changes in the phrasing when you’re trying to toggle triggers off and on. Maybe this needs its own configuration toggle somewhere.

I have just had a run with the latest version and everything seems to work.
Unfortunately the led problem now is fixed only for the note section but not for the octave and duration where there is still the problem that my old grid do not show any light.

All other features seems to work but I have not done an extensive review as I am quite knocked and need some sleep.
Hope this helps for the moment.

1 Like

Forgot to respond to this – in the current version, this is the NONE, TRACK or LOOP settings for which division settings are shared, whereas “note div sync” is the behavior where note + trig are tied together but other parameters may be independent. The language feels kind of overloaded I think but haven’t thought of another term yet. This is one thing I like about the sync matrix idea conceptually – all the different types of sync are the same, you’re just “patching” sync connections together with the matrix.

This is after changing the "grid_varibrightness" setting in the JSON file? I’m unfortunately without a 4-step grid to test with so this is all a bit of guesswork, but I did try to make sure that with "grid_varibrightness": 4 it would use the same brightness level as was used originally in the 1.6.1 firmware. I think there may be a couple other spots that could use brightness tweaks as well. @kbit could you comment on if you are also affected by this or any other UI elements that are hard to see?

Noticed something about looping seemed to have changed as well with the new versions.

Originally when I set a loop, for example 3 notes, I’ll be able to hold the loop button and move this 3 note loop around by just pressing once on any button for that row and that button would be the start of the 3 note loop. Now when I press a button, it just becomes a 1 note loop.

1 Like

(Please do move this if there’s a better place for general Ansible feature requests.)

I’ve been seeing quite a few videos where the scale interface is used as a performance tool, which is a really fantastic way to do things. However, I wonder if it could be made more playable. At the moment each row offsets the pitch and all higher pitches which means you can’t just shift one note in the scale - for example by just flattening the 2nd or whatever without simultaneously shifting all the other notes.

So, how about the option for a second, less bright, button on the scale row. This would indicate a “temporary” offset for only that note in the scale. The subsequent higher notes in the scale would still follow on from the offset of the brighter lit up button.

The interface would be that a single press would work as before (and remove the temporary offset) whereas holding down the bright button and making a second press would create the temporary offset.

Seems like this would be very playable and also have the advantage of not looking any different for current users. How hard would this be to implement? Are there any obvious issues with this? (I’m also happy for any pointers for where to look in the code for this, although I’ve never done any firmware programming myself!)

1 Like

Loving the new firmware @csboling !!!


Oops! This got broken on the trigger & note pages when I was implementing “note sync on + loop sync off”. Other parameters I think were fine. This is fixed in the latest posted build (PR).

Very neat idea! Went ahead and added this in the latest build. This is a “live” setting – it’s not saved at all and it’s not part of scale or pattern state, so when you switch scales or patterns any active scale adjustments are still active. This might be odd – possibly changing scales or patterns should also clear the adjustment, give it a whirl and let me know what you think. If you’re interested in the code changes for this you can review them here – pretty straightforward to hack around on stuff once you’ve got your compiler toolchain set up. For that I recommend this Docker image.


Amazing! Thank you so much for this. I’ve given it a go and it works perfectly. I think it makes a lot of sense when building up a scale. Once nice trick is to set all the notes to unison, and then work up from the bottom, starting with temporary notes and then locking them in and allowing the notes above to jump as a result. Another pleasing effect is to have an arpeggio running and then use the temporary scale change to make the notes’ pitches to switch order.

I think it makes perfect sense to have this as a live setting and not saved with the scale or pattern state. I kind of think that changing the scale should reset the adjustments, but I can also see a use for keeping them in place when patterns change…

Thanks again for the incredible turnaround from vague idea to actually being able to use it. Awesome!


As the Varigate was my go to sequencer for awhile, I can’t help but wonder if some of its tricks could be implemented while we’re in the process of development of Kria. There is a possibility on the Varigate 8+ to set a randomization range, for example I can set the range from 0-5 for Ratcheting per step/trigger, and when that step is triggered, I will get a random number of ratchets from 0-5. This random range can be set for all the parameters, from trigger, to trigger width, etc.

And stray lit LEDs, this has been there since I received my grid and ansible, where in certain screens, with certain notes on, there are some stray LEDs lit. I don’t really understand it or if this is a bug in the original firmware, anyone also experiencing this?

1 Like

This was such a wonderful suggestion, it’s so much fun to play scale degrees with this new behavior! I agree with keeping this as a live setting and I’d support clearing adjustments once scales have been changed. I think that would keep the cognitive load low and encourage improv scale changes.

I haven’t tested the 4-step-brightness mode yet because I found a bug in loading preset files, which @csboling is working on :+1:

Just posted a new build (9cee10a) with:

  • fix for Kria state not being saved/loaded to disk! oops! I think this may have affected builds from the past couple days.
  • changing a scale will reset scale adjustments for all steps, but changing a pattern will not
  • fixes for bugs identified by @kbit in PM – note division page was unresponsive, ratchet division page was changing the wrong thing when note div sync + div sync were on

Thanks again to everybody for all the beta testing!


to be honest, I completely forgot I had to modify the hex file…
I will do one of these evenings…
Unfortunately I am in the middle of a big life change event so I can only do just a few bits of beta testing but I am loving all the ideas everyone is proposing.

Thanks for doing all this work.

I’ve been thinking about this off and on but don’t have a rock solid UI picture of it yet. I’m unsure of both how the input should work and how the randomization range should be displayed once it’s programmed. With notes, I think it would be great if you could program multiple note choices for a single note step, Parc-style, and as the loop visits that step it would select one. But as a further wrinkle I think it would be awesome if you could select a direction mode for how it should cycle through notes, i.e. select the next note via forward/reverse/triangle/drunk/random strategies. I find myself drawn to a lot of sequences where I want to change the selected note each time the loop comes around, but then I want to go play with other parameters, so I wind up copy-pasting the loop over to another couple pattern slots and make tiny alterations to each one. But adding this kind of complexity maybe has a lot of consequences for cognitive load, storage space, UI design, … I’m especially interested in what people think the UI for parameter range/randomization features ought to act like.

I have noticed this! I believe I also encountered this when first learning Kria before I had made any firmware changes, and originally thought it was some feature I had activated by mistake. I’m not sure how it happens and I haven’t been able to reproduce it consistently enough to properly debug these spooooky ghost keys. Though I do sometimes wish I could peek at a different parameter page from the one I’m working on, especially when trying to place a parameter change on just the right step.

1 Like

these recent updates are phenomenal, thank you @csboling!

there has been mention of this previously, but i think all the extra kria-counterpoint is bringing the issue to greater attention: ansible CV output channel-to-channel accuracy isn’t perfect.

with the new JSON import/export plumbing (stunned at this accomplishment!) i’m wondering if the presence of a textfile with scale tunings would be a good solution?

  • bugfix: ch-to-ch accuracy
  • bonus feature: weird microtuned scales! (?)

i’m not sure what sort of tuning granularity we’re looking for? i’d almost suggest just correction for octaves, and then have a macro generate the 12 tones between? or it’d be not too much trouble (and perhaps more interesting generally) to have the full map exposed?


If you’re looking for something to work within the idea of a 12 tone scale but with a little more granularity, I’d suggest looking at the 22 Shruti intervals:

More in-depth reading of how these are derived can be found here:

I’ve used Teletype to convert KR.CV to just intonation based on these intervals and it allows for some beautiful harmonic relationships while not straying very far from 12 tone theory.


I think being able to load arbitrary tuning tables from disk would be pretty awesome! For matching CV outputs, I’m not sure what a typical procedure is, it seems like repeatedly tweaking tunings in a text file and loading them up until all the CV outputs match might be a time consuming way to try to hone in on the right values. So maybe you would want some kind of UI to dial in the pitch corrections? Anybody have any favorite grid UIs for tuning, or for defining microtonal scales? Maybe there’s a simple way to calculate the right adjustments based on a couple voltage readings or something though. I think lots more interesting customization options would also open up with the JSON files if I ever get around to writing a PC app for manipulating them – this could be a friendlier way of managing non-ET tuning tables, but still might not be able to account for mismatched CV outputs.



there is an inherent mismatch between ansible channels, meaning that if I play the same note on all channels, it does differ in the voltage that could be read as output by any channel.
I believe @tehn was talking about this.
I did measure it some time ago and he was so kind to send me a replacement output board that did not fix completely the issue but it is close enough.
I believe this might be fixed on the software side?

Also I want to ask you if you can send me a better explanation on how to install your python script to convert the hex to json file.
I did not manage to do this yesterday
I have 3.7.3 version of Python installed on Mac OSX EL Capitan.


Does this procedure work? Namely:

git clone
cd ansible/tools/flash_tools
python -m venv .
source Scripts/activate
pip install -r requirements.pip
python extract --version 1.6.1 ansible.hex --out ansible-preset.json

Let me know where you run into issues and I can update the readme. If you prefer you can also PM the hex file to me and I’ll convert it for you. I have not added the suggested option yet for indicating what grid_varibrightness you want, so that will have to be edited into the JSON file by hand – this would require a bit of script rework that I’ve been putting off to play with Kria.

To clarify the usage of the Python script:

  • if you are updating from one Ansible beta to another, or from future releases > 1.6.1, it should not generally be needed. The ansible-preset.json file can be saved by Ansible on one firmware and then loaded after you update, or vice-versa – this forward/backward compatibility is one major motivation for going to the trouble of using a JSON representation rather than a binary dump.
  • the primary use case for the Python script is to carry over presets saved on a currently released version (<= 1.6.1) to the new version, so that from that point on you can use JSON files to manage presets.
  • providing the firmware version that the hex file is from is required and must be exact so that the script knows the memory layout of the hex file. Currently I only have layouts for 1.6.1 and 1.6.1 + Earthsea. If you know have an older version, its layout will need to be added to the Python program, please let me know when you PM a hex file. If you’re not sure, but you know it’s a release version, you may be able to figure it out from the release changelog, otherwise I can try and do some reverse engineering - knowing an estimated version range would help. Trying to convert from a hex file and specifying an incorrect version might not work at all, or might have out-of-bounds values that could break the functionality of Ansible apps. I will do my best to sanity check any backups that I convert but this is also a component in need of some beta testing and the converter program might have its own bugs.

I’ve been having a blast playing with the temporary scale change feature to create melodies and chords on the fly. Im creating new scales so easily that I find myself wanting to save them.

So, could a copy/paste function on the scale screen work? Maybe a gesture like holding the current scale position to copy, then long press a second scale position to paste; and any temporary changes made on the scale while the copy/paste procedure is being performed are written into the new scale as well.

I could see some issue with this if the temporary change position is below the previous scale interval. Perhaps a saturating limit can be imposed in that situation, resulting in a duplicatiom of the higher pitch in the new scale to keep it in tune?