How does Ansible calculate note values for I2C?

User @Rassell is getting weirdly inconsistent off-by-one values when reading Kria via Teletype using KR.CV 4:

where they should be 0, 137, 273, 410, 546, 683, 819, 956, 1092, 1229, 1365... per libavr’s ET array.

The only smoking gun I see in the Ansible code is where calculate_note initializes a signed 32-bit note, does some math, then casts it as a signed 16-bit int for the returned value.

Any thoughts?

I’ll have to dig in a little more later but make sure that the Teletype and Ansible firmwares are both up to date (current beta probably? I think an official firmware patch keeps slipping our minds). Previously I believe the firmwares actually used different note lookup tables that I unified a while back when trying to figure out some tuning discrepancies with Ansible’s MIDI modes.

3 Likes

For me the problem is, more or less, solved. I spent some time with the tuning table of Ansible and corrected the values to the point, where they spit out the correct note numbers to be stored in Teletype variables, and saved that for one track of Ansible. This way I can use them to generate chords with the N OP´s in a perfect way. And to my ears, it sounds not, that I lost tuning accuracy, maybe it sounds even better?! Thanks for all your thoughts about that issue…

1 Like