#52

i seem to recall there was a discussion about this somewhere on lines but can’t find it now. i think it’s related to this delay:

and i think i made an experimental firmware that had the delay removed - @jlmitch5 was it for you? not sure why the delay was added, and it’s possible that removing it will work for some grids but not for others. might be worth experimenting with it though.

1 Like
Ansible / Switch Bugs
#53

I remember there was some tempo stalling when switching grid between poly earth sea (white whale) and teletype using 2:1…there was also an issue of missed keystrokes on some mechanical keyboards. Could it be related to either of those by chance?

#54

yeah sounds like the first one (not related to the keyboard issue, that was a separate issue). do you remember by any chance where we discussed it?

#55

I went looking and can’t find anything, sorry! I will say I don’t remember installing an experimental firmware that wasn’t start/end updates on grid control mode, or the keyboard thing

1 Like
#56

And this is why we comment our code. :smiley: Thanks for your quick help, folks!

#57

found it! :slight_smile:

also see this reply and this reply

and the fix was indeed to comment out the delay_ms(200) line.

2 Likes
#58

indeed :wink:

3 Likes
#59

Hello.

Just got Ansible.
When I run Kria or the two other app, there is no Cv out from the outputs. Only a low static negative voltage.
Is there something wrong ?

Thanks

Jeremy

#60

hahaha… well done. :smiley:

Seems like an irksome value to change if I understand the implications. When you say responsiveness, you mean the Ansible essentially “missing” Grid button presses, right?

#61

no, this delay is related to initialization code when a grid is connected. so if this delay is removed, there is a risk that some grids will not get recognized or something like that. from the limited testing we did back then it worked fine but the delay was added for some reason, so possible that it’s needed for an older grid revision or when the library is used by other hardware (like aleph).

1 Like
#62

You can’t get triggers to fire either? But the grid does light up and respond? Maybe check that the pin headers connecting the PCBs are well-seated, could have got jostled in transit?

#63

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

#64

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.

#65

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.

#66

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 help@monome.org.

#67

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.

Jeremy

#69

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
#70

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
#71

Thank you very much, looking forward to the fix!

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

#72

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.