Ansible bug reports (official)

I have triggers out but not CVs. Is it an issue ?

If half of the outputs don’t work that seems like it could interfere with your usage of the module! Can you describe a bit more about how you’re using it? You may also want to try configuring Meadowphysics for 8 trigger voices, this should cause it to try to output the maximum voltage on the CV outputs when those trigger channels fire.

I use it for example with Kria. When I set the note there is nothing out from the CV out. Just triggers.
When I configure Meadowphysics to 8 triggers it’s don’t work, I have only 4 triggers out.

Having trouble getting the video to work, but do try checking that the PCBs are well-seated with each other. I believe the DAC chips for the CV outputs are on a separate board from the processor, whereas the trigger outputs are just routed from the processor’s GPIO pins. If that doesn’t fix it, contact

Yes I have check all the PCB and the ribbon. All is in the good place. It’s a new module freshly receive by Monome.
I have try reflash Ansible with the advice of the support.
I am in contact with the support. Hope it will can be fixed but I think the module have an issue.
Thanks a lot for your interest.


Today I used Ansible’s MIDI poly allocation mode (which led to this feature request) with an Akai LPK25 as the keyboard and a very simple four voice patch on the ER-301 (each voice was just a gated sine oscillator).

The whole thing didn’t sound quite in tune, so I noticed that the tuning of the four voices was noticably off. So I performed the Ansible tuning procedure as outlined here with the Grid connected. To make sure i really got as perfect well-tempered tuning, I tuned each key in each octave of each voice individually (still with the ER-301 patch, connected to an external tuner). I saved the resulting tuning table to flash as described, left the tuning mode, power-cycled Ansible, went to the tuning page again and checked if my tuning edits were retained (they were), powered down, connected my Akai LPK-25, powered up, played…

…and found out individual notes were still off as before. Being under the impression that there is only one tuning table for Ansible, regardless of the mode it is in, and given that there is only one tuning procedure, I guess it must be a bug that the MIDI poly mode does not respect the tuning table edits I made. Please, @csboling, would you be so kind and have a look into this? Thanks much in advance!

Note 1: When connecting a Grid and going into the tuning mode, all my edits are still there.
Note 2: I did not check the other MIDI modes, nor the arpeggiator.
Note 3: When starting Ansible with the Akai LPK25 connected, CV1 does not output a control voltage unless I press the Panic button Key 1.
Note 4: I am still on 3.0.0 from Apr 22.

1 Like

Oops, looks like the midi code does not use the tuning table at all. It also appears that this should send note on / note off events to ii followers but doesn’t send pitch values. I confess I’ve done very little testing with Ansible’s midi mode and have made very few modifications to the code so this slipped through, apologies. I’ve made a github issue to track.

1 Like

Thank you very much, looking forward to the fix!

Please let me know if I should perform any other tests, happy to help!

I noticed in the MIDI code that the pitch calculation uses the SEMI14[] lookup table, based on 16384 DAC ticks / (10 octaves * 12 notes). But other apps on Ansible use the ET[] table from libavr32, based on 4092 DAC ticks / (10 octaves * 12 notes), and always shifts left by 2 before sending a value from this pitch table to DACs. So the SEMI14 values are higher resolution, but since 16384 / 4092 = 4.00391… these values actually wind up drifting apart from each other by a good deal more than 2 bits:

Python 3.7.4 (tags/v3.7.4:e09359112e, Jul  8 2019, 19:29:22) [MSC v.1916 32 bit (Intel)] on win32
>>> semi14 = [int(n * 16384.0 / 120) for n in range(0, 128)]
>>> et = [int(n * 4092.0 / 120.0) << 2 for n in range(0, 120)]
>>> [(a - b) for (a, b) in zip(et, semi14)]
[0, 0, -1, -1, -2, -2, -3, -3, -4, -4, -1, -1, -2, -2, -3, -4, -4, -5, -5, -6, -2, -3, -3, -4, -4, -5, -5, -6, -6, -7, -4, -4, -5, -5, -6, -6, -7, -7, -8, -8, -5, -5, -6, -6, -7, -8, -8, -9, -9, -10, -6, -7, -7, -8, -8, -9, -9, -10, -10, -11, -8, -8, -9, -9, -10, -10, -1
1, -11, -12, -12, -9, -9, -10, -10, -11, -12, -12, -13, -13, -14, -10, -11, -11, -12, -12, -13, -13, -14, -14, -15, -12, -12, -13, -13, -14, -14, -15, -15, -16, -16, -13, -13, -14, -14, -15, -16, -16, -17, -17, -18, -14, -15, -15, -16, -16, -17, -17, -18, -18, -19]

Has anyone who uses both MIDI and other apps on Ansible noticed different pitch behavior in grid or arc apps vs. MIDI? Teletype, Aleph, and Trilogy don’t seem to use the ET table, just Ansible. Paging @ngwese, @tehn.

I had thought the SEMI14 table dated back to the original MIDI mode for earthsea but that does not appear to be the case. Roughly spot checking the git commit history the ET table does pre-date the SEMI14 table so I honestly don’t remember why I did what I did (a case of premature optimization perhaps?)

Without sitting down, thinking through the details, and reading the spec sheet for the DAC I’m not sure one is obviously more correct than the other. In my particular case the pitch tracking of any given oscillator could have potentially masked the difference. I only have analog oscillators across my various systems so I tend to just run with it until something seems off then tune to the range of whatever I’m doing at the moment.

Regardless consistency in expression of pitch across ansible modes seems most desirable in the long run so I’d probably advocate moving away from the SEMI14 table in the MIDI mode(s) in favor of the ET table used in the other modes.


Here’s a short example of the pitch deviation of Ansible in MIDI: in the first half of the recording, all the CVs for the 4 voices (digital oscillators put thru simple VCFs/VCAs) are put thru quantizers, in the second half the CVs are put directly to the 4 voices.

It would be great not having to use quantizers.

Here is a build which ought to use the programmable tuning table (based on ET[]) for MIDI, and be able to pass MIDI pitches to I2C followers.

ansible.hex (371.5 KB - 10677b4 - 2020/06/13)

Let me know if it works any better for you, and how the pitch tracking compares to previous builds using the SEMI14 table. I’m hesitant to add these changes to the Ansible beta thread until it’s been checked out by someone else, I have only done minimal testing so far and I don’t have a great ear for pitch.


Thanks very much, but unfortunately, I was still on 3.0.0, so while I was able to save to a USB stick, the .json file that was saved was empty (0kb size). Nevertheless I updated to the preliminary firmware you provided, but from initial experiments it sounds like the update not only erased the preset, but also the tuning table I made (by tuning each and every individual note on all four outputs with a tuner).

Is this expected behavior that a firmware update not only erases the presets, but also erases the tuning table (which is, at least to my understanding, the only way to correct the DACs’s outputs to get an equal-tempered scale)?

If it is expected behavior, is this tuning table stored inside the ansible presets .json file? If it is stored outside of this preset .json file, how do I save the tuning table to USB disk, as I could not find another file on my USB disk beside the preset .json after I executed a store to USB disk (after I updated to your new firmware).

In any case, I will need some time to repeat the tuning process, and as I will be out of town the next 3 days (unfortunately without my system :frowning: ), I won’t get to this before Thursday, sorry. Eager to return and check it out!

1 Like

Yes, the entire contents of module flash are overwritten.

Yes, they are supposed to be saved to the same file but there is a bug in the released 3.0.0 that prevents saving from working at all.

Very sorry about the broken preset saving behavior in 3.0.0. If you created a hex backup file it might still be possible for me to recover presets from this using some Python scripts I have. In addition to the fix for this there are a couple other small changes. If the midi changes work I think that would perhaps be a good time to do a new version.

I did not create a hex backup file, the save to USB disk was the only one I knew of. Out of curiosity: Is the hex backup file the procedure described here? If yes: Lesson learned, from now on I will read the entire page, because I stopped after reading this paragraph :crazy_face:.

Nevermind, recreating the tuning will be an excercise in “practice makes perfect” – and I will update my second Ansible (that recently arrived) to the preliminary firmware right NOW to make sure I will be able to make proper backups. :slight_smile:

@csboling: Today I tuned my Ansible’s CV outs again, this time with the latest firmware from 2020/06/13, but unfortunately the tuning table is still not being used by MIDI Allocation 1 “Poly”.
I did not test the other allocation styles, nor the i2c routing (as I don’t use i2c with Ansible).

Some additional comments:

1. Grid UI Bug when leaving Tuning page via KEY1
When leaving the Tuning page by pressing KEY1, the grid changes to display standard Kria user interface elements, but
(a) notes that were switched on while on the Tuning page continue to sound, and
(b) button presses are executed as if the Tuning page was still active.
While pressing KEY2 ends this rogue behavior, it can be quite unsettling to the novice user.

2. Question regarding leaving Tuning page via KEY2
Tuning changes made in the lowest row or in second lowest row are not discarded when leaving the Tuning page via KEY2. It is not clear from the Tuning page documentation whether or not this is the intended behavior or not. While I do understand that leaving the Tuning page without discarding the edits, but also without saving the edits to Flash, might be desireable in order to “test” the tuning edits before committing them to Flash, the current current behavior can be confusing for a novice user like me, as there is no easy way to leave the Tuning page and discard the potential mayhem I created accidentially.

Suggestion for items 1 and 2: Leave with the behavior of KEY2 unchanged, but turn KEY1 into a “panic” button, i.e. it discards all unsaved tuning edits, and returns the user to Kria. This way, the KEY1 behavior would also be aligned to its “Panic” button behavior in MIDI modes.

3. Bug in MIDI Poly Allocation mode
In Poly Allocation, keys actively held down on the keyboard are not excluded from voice stealing. So if I want to play a single note melody (say E-G-A-B) over a held bass note (“pedal point”, e.g. C), the fourth note of the melody steals the bass note, although I hold its key down. All other implementations of this rotate voice assignment I know from other instruments respect held notes.

4. Question regarding Tuning page documentation
On this page it says:
The row above the bottom row displays and sets the absolute DAC value of the note slot. 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., with keys that have already been passed staying dimly lit, visualizing the full CV range of the track.
There is no visual indication happening anywhere on the grid when I press buttons in the second lowest row. The buttons in the second lowest row remain unlit, all they are doing is to switch the CV output voltage in intervals of roughly fifths. Is this intentional?

In general there is zero visual feedback of any button press I do on the Tuning page, I can press any button, but this does not change the visual pattern of the Tuning page at all. It is not clear to me from the documentation if this is expected.

5. Feature Request for additional MIDI Reset Allocation mode
It would be great to have an additional MIDI voice allocation mode, in addition to the existing Poly allocation. This Reset mode would also be four voice polyphonic, but it would assign a new incoming note to the first inactive CV/TR pair with the lowest index number. Here are some more details about this mode.

1 Like

The POLY mode does not track held notes. It simply assigns each incoming note to the next TR/CV pair in ascending order wrapping back to the first pair as of the fifth note. The documentation describes this as “a shift register” but that in retrospect doesn’t paint a very clear picture.

Based on the description it sounds like what you are after is some sort of priority mechanism. I have seen lower note priority, higher note priority, and various forms of stealing the oldest or newest note. The reason priority wasn’t implemented originally came down to UI - with only two buttons, no screen, and a midi device with arbitrary capability plugged in it wasn’t obvious how to allow much if any configuration.

I understand, but I fail to see the benefit of the current implementation, which is disregarding an essential information the performer gives to the instrument: “I am holding down these keys because I want them to sound for as long as I hold them.” Please help me understand the benefit of the current implementation.

No, I am not looking for some sort of low/high/oldest/newest note priority mechanism.

What I am looking for is that incoming MIDI Note On events are assigned to “free” TR/CV pairs only,
with a TR/CV pair being “freed up” the moment it has received the matching Note Off event for the Note On event is has been assigned to. If performers hold down four notes, then play a fifth, the oldest of the held note is stolen. That is the implementation of “rotate” voice allocation I’ve seen in all polyphonic synthesizers I’ve played in the past 35 years.

If rotate is implemented with respect for held notes, there is no need for a special configuration, as the behavior depends completely on the playing style: If performers want all voices to participate in the rotation, they play staccato; but if performers want certain notes to be excluded from the rotation, they hold down these notes.

looking at the source i think this is down to simple expedience, not a design decision.

it’s still not really a “bug,” its a known limitation; the firmware does exactly what the documentation says: sticks a shift register in front of the voices.

in any case i agree that the shift register is less obvious than voice stealing for keyboard input, and this is a good feature request. (aligns with some TODOs in the source.)

a full polyphonic keyboard mode would need other stuff too, like a reasonable interpretation of legato. it’s considerably more complex than the other modes.

1 Like


I don’t think this more advanced stuff you mention like polyphonic legato interpretation is needed to make Ansible’s current Polyphonic mode significantly more useful. I’d certainly rather see just my enhancement request [exclude held notes from voice stealing] being implemented, than waiting (potentially in vain) for a complete full polyphonic implementation with all bells and whistles – which would be “death by overspecification” in my book.

Talking about legato: I have not yet encountered any polyphonic synthesizer that offered a useful polyphonic legato mode. Instead you have to switch to monophonic operation to get legato behavior. From my experience, a really satisfactory polyphonic legato is best achieved with an MPE-capable “fretless keyboard” like the Continuum Fingerboard.

One last plea for an additional Reset polyphonic mode
Reg. my other enhancement request to implement an additional Polyphonic Reset assignment mode: I believe that when implementing polyphonic voices in an analogue modular synthesizer context, only a minority of these implementations will have identical modules across all voices (e.g. 4x Mangroves, 4x 3Sisters etc for a four voice system). Instead, the majority of the implementations will have non-identical modules across all voices (e.g. 1x Mangrove, 1x Plaids, 1x Doepfer VCO, 1x Loquelic Iteritas…just looking at the oscillators for a four voice system). So it will probably be more likely that each voice will a different sound, than that all voices will have exactly the same sound.

This means that an assignment mode that gives the performer precise real-time control over which note shall be played by which voice (aka sound) is preferable to a rotate implementation. The reset assignment mode offers exactly that: You can play a chord, and just by the order in which you press the keys, you can precisely control which note of the chord will be played with which sound.

Examples for such implementations are the “Poly-2” mode of the Roland 184 polyphonic keyboard from their 100m modular synthesizer series, the “Reset” mode of the Polyphonic Keyboard module of the Oberheim Four Voice, or the 225e MIDI Decoder / Preset Manager of the Buchla 200e (which only offered Reset when bundling multiple monophonic voices for polyphonic operation).