Ansible Development and Beta Firmware Discussion

Thanks a lot for your hard work. The new features sound amazing!

I’d like to try your latest build, but no luck so far. A few months ago I updated my Ansible to 1.6.1, so dfu-programmer is installed on my Mac.

When I downloaded the 1.6.1 ZIP file I got a ansible.hex file and the update-firmware.command file. When I’m downloading the ZIP file from your link I get the complete folder structure, but no hex file, so that doesn’t work.

Sorry, I don’t know nothing about using Github. Could you please tell me how to upgrade to your build? (I don’t have presets I want to transfer.)

Thanks a lot!

sounds amazing. if possible, and you have the means, would you be able to post a quick vid with an example? I have the newest firmware installed but I’m not quite clear on how this is implemented. Thanks.

thanks for the explanation but I cannot run the venv module in python.
When I write python -m venv . it says “/usr/bin/python: No module named venv”.
So I assume it is some problem with python then.

/UPDATE/ I have to use python3 and pip3 commands instead of python and pip, now I am stuck on the last commend to convert the file.

Anyway, thanks also for the explanation regarding the use of json but Am I right that I need to upload the prest file to be able to use a 4 step varibright monome?
Does this mean that I will always have to create a preset file and modify it when there is a new version of the software?

This is something that would be really important to understand

Simple enough that a video shouldn’t be necessary! On the scale page your intervals are choose with the glyph on the right hand side. To alter the note of the scale without changing any of the other notes, hold the square that is active then press another in the same row to shift it. You should see a lighter grid to indicate the temporary position. If you single tap the original square once again it will shift back to normal. If you single tap any other key you will alter the scale as the original behavior would.

i think I get it now. Will try to give it a spin when I’m back at home. thanks!

1.6.1 is the previous/existing release. It does not contain the changes described in this thread, which is for prerelease betas. To try those you want the ansible.hex file uploaded as an attachment to the first post in this thread – it sounds like maybe you’re working with the 1.6.1 zip file from the Github releases page? I’ve only uploaded hex files so far. update-firmware.command should probably also be included but currently is not – once you have ansible.hex the commands you want are:

dfu-programmer at32uc3b0512 erase
dfu-programmer at32uc3b0512 flash ansible.hex --suppress-bootloader-mem
dfu-programmer at32uc3b0512 start

which is the same as what’s in update-firmware.command. (Or it should be – I think older update-firmware files might contain at32uc3b0256, which might work fine or might give an error now that the code uses more memory.)

The default firmware assumes 16-step varibrightness, and the only way to change this is from the JSON file, so this change will need to be made in order to be saved into Ansible’s flash. After that, this setting can be treated like part of your presets: insert a USB disk and do the disk save procedure before you flash a new firmware, then load your presets off the disk after updating. This sounds annoying / easy to forget, I’ll find a spot to add this setting to the grid interface somewhere.

From earlier in the thread it sounds like you are already on a beta firmware, so you don’t need to run the Python script to create an ansible-preset.json file unless you just want to – you can just do the USB disk save procedure, then edit the file on the USB disk with your computer, then load the preset back up on Ansible. In fact if you are working with an ansible.hex backed up from any of the betas I’ve posted, rather than from the official 1.6.1 release, this could be why the Python script is encountering an error (most typically this manifests as something along the lines of “expected bool but value 5 was found” or something, but other errors are possible).

I have posted a new build (afb85ec) which contains a prototype grid interface for arbitrary reassignment of Ansible’s tuning table. This is not very polished but I wanted to post it to get some feedback, especially because it sounded like @tehn was about to start working on this. So first some caveats/questions/observations:

  • I apologize that I have not tested this with 4 brightness levels. I agree that having to re-initialize the varibrightness setting via the JSON file is pretty annoying, I think the next thing I’m going to do is make this programmable somewhere on the grid interface. This should have the side effect of making it much easier to check out different varibrightnesses while developing a UI.
  • If you calibrate your CV outputs, since KR.CV reads the current DAC value, you will read different KR.CV values from Teletype for two different outputs even though the voltages they output are equal. This suggests maybe a need for a KR.N op to get the calculated pitch in “semitones” that Kria is using, (i.e. octave + octave shift + scale note + scale note shift + alt note… am I missing any offsets?), so that you can differentiate the programmed pitch from the actual output voltage. Note that such an op would not be able to read the exact pitch value while an Ansible CV is slewing.
  • How should interpolation between octaves work? Should we fit a line to ensure that the entire output range is mapped linearly, or is it useful to be able to correct for nonlinearities? The fit I’m using is just a dumb piecewise linear interpolation between octaves. This has the downside of being nonlinear, so it’s possible to have weird pitch tracking behavior depending on how you program the octaves. It has the upside of being nonlinear! This lets you do some fun stuff like have a tuning table which gets lower in pitch in the middle and higher at either end, or use one or more tracks of Kria as a really flexible if mind-bending CV sequencer, or whatever. Possibly multiple interpolation methods are needed? It seems like maybe this interface could be made to even support arbitrary interpolation waypoints, where octaves would be the default, using a long-press or something.
  • Completely by accident, if you have a Kria sequence running when you switch to tuning mode, Kria is still running, and you can re-tune a running track on the fly, or play the tuning interface to accompany your sequence microtonally. Frickin’ rad. You can quick mute some tracks if you want to tune them without the sequence running. You can also switch back to Kria or to other apps to experiment with the tuning you have programmed, but tuning tables are not saved until you explicitly save them, so if you like what you’ve got make sure you go back to the tuning page to long-press the save button before powering off.
  • This is maybe kind of a complicated interface! There’s a lot of data it’s possible to manipulate. I’ve attempted to keep it so that routine tasks are fairly accessible but in-depth tweaking is still available. I’m planning to follow up with a step-by-step guide for calibrating Ansible using this UI. I think it may also be possible to devise a Teletype scene that partially or completely automates this procedure using the ANS.G ops…

Which brings us to the (other) fun part:

Tuning interface

Enter Kria. Hold Key 2 (config). The Scale page key from Kria remains highlighted with Key 2 held. Press it to enter tuning mode. You can let go of Key 2 now to exit tuning mode, and tap Key 2 again at any time to go back to Kria.

The top four rows, as in Kria’s trigger page, correspond to tracks, with only the center 12 keys highlighted to represent the 12 steps in the tuning table between two “octaves”. All tracks and therefore all triggers are on by default. The playing note in each track is highlighted, and the currently tuning row is highlighted slightly brighter than the other rows. By default all notes being tuned are the same (Ansible’s lowest note slot, 0V by default). You can change which note slot is selected and playing from each track by touching the corresponding key in the top 4 rows. If you touch a different track than the currently tuning track, that track becomes selected for tuning. If you touch the active note in the track that is currently tuning, the corresponding trigger output goes low, so you can mute one or more voices if you are tuning by ear and patching the trigger outputs to your VCAs. Note that a note slot may be currently selected for tuning even though the corresponding trigger output is off – probably this should still be highlighted somehow but currently is not.

The bottom row provides keys for increasing (keys on the right) or decreasing (keys on the left) the value that will be sent to the DAC to play the currently selected note slot. From the center out these are +/- 1, 2, 4, 8, … +/- 128 on the outermost keys. Some of these should probably be un-highlighted when you can’t step that far because you’d hit the minimum/maximum DAC value.

The row above the bottom row is a quick reference for the DAC value the currently selected note slot is set to. As the DAC value increases, the leftmost key will get brighter, then it will turn off and the next key over will get brighter, etc, mapping the full CV range over 16*varibrightness steps. You can touch a key on this row to jump to a DAC value, note that this will result in the key to the left of the key you pressed at maximum brightness, because otherwise all the LEDs in this row would be off and it might be tough to see where you’d switched to.

The left side of the row above this selects which “octave” you have selected, just meaning a group of 12 note slots.

The right side of this row (third from the bottom) is for load/save functionality.

  • The key to the left which is separate from the other two is the panic key – press it to restore your saved tuning table from flash, long-press it to go back to the factory default equal temperament tuning table. This long press does not save anything, so you can quick press the key again to go back to the tuning table you have saved, if that’s different from the factory default.
  • The first key on the right is for interpolating the tuning table between octave values. Quick press it to do a piecewise-linear fit between the values programmed for each octave. Long press it to fit between octaves and then save.
  • The key furthest to the right can be long-pressed to save all note slots with their tunings exactly as currently programmed.

i’m a visual kinda guy, so I think I figured it out. for once I “may” have something to contribute around here instead of my constant mooching :slight_smile: video essentially shows everything kbit described in text.


@csboling: any chance that if we select 1 or more extra notes per note in the scale, that we can get Kria to randomly select between them as well?

Is the tuning mode added in the latest version (20/06/2019)?

Replying to the convo on Ratcheting and selecting a range:

Would it be a possible to do it by holding the button for where you want the first ratchet then press the second button to indicate the range (a bit like hope we set loops). And the ratchet sub-division selection would work and be applied to all the ratchets in that column.

Make sense?

I downloaded the “ansible.hex” file attached to your fist post. But where should I put it? The folder structure included in your ZIP file includes an scr folder, which contains the “update-firmware.command”. Should I drop your “ansible.hex” file into the same folder – or into the “ansible-master” folder?

Thanks a lot!

this is great— if you’re interested in pushing forward on this please do— i have a billion other things on my list :slight_smile:

have the recent features stabilized? when shall we call this 2.0? (i’m figuring a version bump given the inclusion of earthsea)


Yes, should be – I just double checked that I uploaded the right file.

I think this is pretty intuitive, I was thinking out loud (in my usual verbose manner) about this idea in this post, but haven’t tried implementing anything like this yet.

I think if you have dfu-programmer installed on Mac you should be able to put the ansible.hex file anywhere and then run the commands from that folder in a terminal. On Windows I put them in the same folder where I have dfu-programmer.exe. ansible.hex is the only file you should really need. If you downloaded a 1.6.1 zip file and extracted it, I think you should be able to replace the hex file in that extracted folder with the one attached to this thread, and then double clicking the update-firmware.command should hopefully work?

I think things that have gone into master so far are pretty stable. Things I’ve currently got in the works:

  • Need a way to set the desired varibrightness through the grid UI, rather than just from the JSON file. This I think should go in the release.
  • Sounds like subdivision selection on the ratchet page is maybe confusing as-is, I’ve got some ideas for making that less surprising for basic usage.
  • I would also like to include tuning mode since I agree that DAC calibration goes well with the other features.

That said there are always more little things to tweak and I realize you’re trying to start shipping a batch of new Ansibles here in a couple weeks, so unless more bugs are found I think I’m fairly happy with the existing functionality and we can always do another release fairly soon. So I think I’m probably good with calling it after, say, whatever I can get done this weekend.


Yeah, tbh I don’t find it particularly intuitive, I don’t understand why their steps stay after removing a ratchet. I just expected the entirety of the ratchet to be gone when I disable a ratchet.
Maybe that doesn’t make sense? On the other hand that’s how all my sequencers work.

Also doing triplets doesn’t actually seem to be doing triplets, at least it’s not doing what I’m expecting. Need to try it out a bit more to determine if it’s me misunderstanding something or if it doesn’t work correctly.

I guess with this implementation they probably are not on the beat, but shifted by the length of one tripled?

I have not tried the latest features yet, but from just reading I get a bit worried if the UI is still intuitive and easy to use/play. Hopefully Kria does not get overloaded for some quite specialized use cases as random ranges for features that already are very filigrane like ratchet and note offset.

BTW, I always thought Kria already had an official feature for altering single scale notes without shifting the rest of the scale.I rarely used it - has it gone lost somewhere on the way to the current firmware?

At the latest beta I can’t manage to disconnect notes, triggers and tracks. All config graphs are unlit but still everything is bound together. And the UI ist messed up when the loop wraps around the right end of the grid on note page.

I think this is to make it easier to program one extra “ratchet” trigger for example on substep four of possible five without actual having the five substeps triggered. I have to admit that this is one of the more esoteric features which I am afraid that they make Kria less intuitive and easy to use and I would be fine with just a simple 1 to 4 ratchet.

I guess one would need to be quite smart for intentionally using all this to program interesting sequences. Otherwise it would just come out as the usual pseudo random quantized sequence music. There is nothing wrong with this I am just not sure how heavy featured that would have to be.


Can you describe more of what you mean when you say your UI is messed up when a track wraps at the right side?

Also the scale manipulation behavior you are referring to was in place on the White Whale version of Kria; I don’t believe it got ported over to the Ansible version. Thankfully I find the way the sacle shifting works right now to be pretty intuitive and fun :slightly_smiling_face:

@simonvanderveldt I’ve been thinking about your inability to create triplets the way you want and I had a thought: it sounds like the triplet behavior you’re expecting akin to an “eighth-note triplet” setting on a clocked delay, is that right? If so, this would be a succession of three evenly spaced trigs in the time frame where two trigs would normally occupy. (Please correct me if I’m wrong!)

The ratcheting function creates a succession of evenly spaced trigs only in the space where a single position on the trig page exists. I just checked and confirmed that the speed of the ratchets is tied to the divider setting on the trig page. This makes it so the timing of the ratchets are consistent with the speed of trigs, but will never allow triplets to be programmed like the method I described above.

@csboling maybe it would be worth seeing what happens if the divider setting on the ratchet page itself is what determines the timing of the ratchets? I could see some potential problems with this but It seems like it could be a simple thing to test.


There is a shifted ghost image of the current note sequence appearing on the grid. I think I does not influence the actual behaviour but is a little distracting.

Ah okay, yes that could perfectly be and there is absolutely nothing wrong with your current implementation!

But what bothers me more at the moment is that the config page does not work anymore - it is not possible to disconnect tracks, notes and triggers anymore.

Hm, are the three sub trigs really occuring on the postion of a single step or in the space between two steps? I think that makes a difference for triplets being right. They should still be consistent with the main speed. Anyway, I don’t think one could get real triplets out of a ratchet, but it is also inconsistent and skips substeps every now and then at the moment.

Wait, what exactly are the greyed steps showing then? I though it was deviding the step into 1 to 5 even substeps that can be activated then. Three substeps should then give triplet speed, or what am I missing here? The triplets would just be shifted one third of a beat.

I’ll check this out. The intention is for all existing functionality to remain unchanged from 1.6.1 by default – new timing/sync options should all be opt-in to avoid interfering with any existing usage. The obvious exception to this is the change to ratcheting behavior, which I’ll definitely work on making less confusing. The default sync options ought to behave exactly as before but it’s entirely possible I broke something – the motivation for these features though is to make it easier to (optionally!) keep different components in time with each other if you want to, so that using different loop phases / lengths doesn’t get too chaotic.


It just became inactive as in not outputting gates anymore when I changed the note loop. I reinstalled and powercycled but still can not change config settings and the ratchet is more or less random in how many trigs it spits out per step.

Between is what I meant, thank you for clarifying.

You are correct, I was referring to the divider modifier of the ratchet parameter as a whole, not the subdivisions of an individual step. Sorry for the confusion!

Maybe this is a silly question, but is earthsea included in the most recent beta? Also, I’m wondering if there is going to be an updated official firmware on the new batch of ansibles, because theres a lot of new documentation on the monome official page that I don’t remember seeing before :thinking: