#123

Yes I have seen it before, was just surprised at the difference in Channels, my Channel 4 which is the least used hence never noticed, was off by 1-2 semitones the higher up it went.

#124

I can confirm that the latest version you posted works well on my 4-step varibright.
Still have to dig it in depth but all seems to show on the monome.

Thanks for the work!!!

#125

Thank you very much for the videos @theelectricyouth , this is quite bizarre. Moving this discussion over here since this seems like a broader Ansible problem rather than being Kria specific. I’m combing over the code today to try and spot anything that could account for this. I have uploaded a new version 141ab03 which contains probably just a couple minor bug fixes from the version you’re on, but the nature of weird glitches like this on firmware is often that they’re caused or exacerbated by unrelated changes, and I have yet to encounter this behavior.

Looking for previous reports of crashes I found this post, which sounds like possibly something similar occurring in 1.6.1? Since you’ve hit this 3 times while beta testing and not before it kinda seems like something has made it happen more often, I’ll be paying special attention to all changes from 1.6.1 to the present. I’m also going to try using ANS.G ops to simulate a bunch of random grid interactions looking for crashes, though it sounds like this actually typically occurs on its own, so the glitch must be something the app causes on its own when just operating normally.

  • It seems you get no response to grid keys at all, for any app, but the grid is still refreshing LEDs. After you re-plugged the grid, your video shows no keys lighting, but the app is still running – you get pitches changing, just no gates. You said that after 20-30 seconds the grid display appears again? After that, do the keys respond like normal? Or is the grid still just showing the display without accepting any input? All this seems to me to speak to something going haywire with Ansible/Grid communication, like polling for key presses is not working.
  • In the videos where you change apps, it looks like changing to Meadowphysics changes the trigger outputs, but they’re still not firing when they should, is that correct? And that you only tap the mode key once to cycle Kria -> MP or MP -> ES, but you tap it 3 times to cycle ES -> Kria? Of course none of these should change apps, you should need a long-press for that, so this seems like something going wrong with the timer for the front key.
  • That clock display is wild! I can’t see how the clock position in the top row would run backwards like that, the counter for that only ever increases. This seems like it has to mean the clock handler is getting called way more frequently than it ever should be, like faster than the LED refresh handler for the grid. But the grid display and the CV outputs seem to be advancing normally, and those should be driven by this clock timer as well.

All taken together this seems to me like it indicates something going wrong with the software timers. Like their state suddenly gets corrupted during normal operation.

  • The clock timer is possibly misbehaving, causing backwards/random looking clock positions on the clock page. However the clock does appear to be running based on the behavior of Kria and Meadowphysics.
  • The mode key long-press timer is misbehaving, so you always get a long press, but from Earthsea this is not registering – possibly because Earthsea uses more timers for managing pattern playback etc.
  • The DAC update timer and Grid refresh timer seem to be working correctly, since the CV outputs are changing and the grid is being redrawn.
  • The Grid input polling timer is possibly misbehaving, or possibly has been disabled entirely, since all apps appear to be unresponsive to grid input.
  • The auxiliary timers may be misbehaving, because Kria does not turn off notes. It appears that the timer used to blink the bottom-left track select keys when a trigger fires is also not working.

Here’s a video of the random Grid interactions because I think it’s cool:

The Teletype script here is:

# M
L 1 3: $ I

# I
M 500

# 1
I RRAND 0 15; J RRAND 0 7
ANS.G I J 1
K % + I RRAND 0 15 16
DEL 1000: ANS.G.P K J

# 2
I RRAND 0 15; J RRAND 0 7
ANS.G.P I J

# 3
EVERY 2: BREAK
I RRAND 0 15; J RRAND 0 7
ANS.G I J 1
K % + I RRAND 0 15 16
DEL 1000: ANS.G.P K J

So just doing a bunch of random button presses and 2-key gestures anywhere on the grid with some staggered timing.

Update – I ran this for a couple hours, played with it while it was doing this, cranked up the metro rate, read the code a bunch. I did see one complete freeze of both Ansible and TT when I cranked the metro rate up further (~100 I think?) which I’m inclined to guess was I2C flooding, it didn’t look at all like the videos but more like what you’ll see when running TT remote ops with a bad I2C bus connection. I have read a couple times over everything I could think of timer related and have seen nothing wrong, I’m about to start directly corrupting timer memory to see if it acts like this, but I had a thought – are you powering the Grid directly from Ansible? I have always powered the Grid with an Offworld-1 and an (allegedly) 2A USB power adapter. If you are powering the Grid off Ansible directly, what is the power budget of your rack like? Seems like a long shot, and this still smells like a software issue to me, I’m just trying to figure out any setup differences that could make this more likely to appear. I’ll retry some experiments where I power the Grid off Ansible, might have to unrack some other stuff.

2 Likes
#126

Thank you for taking the time to check so throughly through this!

After the lights come back on, it is still very unresponsive. Trying to do a crazy amount of presses, I managed to only move the octave up on one step :smiley:

Though something weird happened that wasn’t on the video. When trying to press the preset button again, for some random reason, maybe the press was so short it registered as a preset press and not change app press, I managed to see the preset page. And even though nothing was responding properly, I managed to save the patch somehow because upon power cycle, it was running the same patch before the crash! And I managed to use it for the next couple of hours without it crashing again.

I didn’t pay attention to whether the triggers where firing while shortly in Meadowphysics. And yes it takes more presses to get from Earthsea back to Kria.

It went a bit mad and didn’t make much sense. But somehow depending on whether it was on the left side or right that I pressed on the grid, it seemed to affect the clock display.

I’m powering directly as I have a very strong power supply. I am using at maximum 50% of its power supply values even with the Grid plugged in and running with maximum LEDs. Hence I don’t know if it could be power related. I will reconnect Ansible today to another plug as it is on a flying bus at the moment and see if the crash occurs again.

Have we ruled out any hardware issues with this crash?

#127

If you can make a JSON or hex backup of this and send it to me I will load it up to see if that makes any difference, and if I can detect anything weird. At this point I am down to suspecting a) a hardware issue or b) an unrelated bug fixed by the new firmware that you never see again, fingers crossed. Neither terribly satisfying, we’ll hope for c) bizarre buffer overrun bug corrupting timers that is fixable in software somehow.

1 Like
#128

I have sent you the file in a direct message, really hope we can get to the bottom of this!

#129

I have not seen this partial crash behavior where the Grid stops responding under a fair amount of stress testing, feeding in audio rate square waves to clock/reset, sending tons of I2C traffic including random grid interactions for hours. I have seen a couple times where a really high frequency of I2C commands has frozen every module on the I2C bus, but nothing like the unresponsive grid/key press and erratic clock display behavior. I did find this and this discussion where similar problems were investigated in depth. If this type of issue affects anyone on recent betas please share any details you can about your I2C setup and how you’re clocking Ansible, I have added some info about this to the top post as well.

The new build 0969ac4 has a prototype implementation of this, which I have tested on a TXo, but don’t have a Just Friends or ER301 to confirm with. To access this function, short press the mode key to go to the preset page. The third column from the left has 5 new keys lit:

  • The four keys in the center are toggles for 4 I2C follower slots. Toggling any of these on will enter I2C leader mode, turning them all off will return to I2C follower mode. Ansible will be unresponsive to I2C commands from Teletype while in leader mode, however from what I’ve tried it seems to work okay to send Teletype commands to your output module while Ansible is also a bus leader. All leader mode settings are saved at once when you leave the preset page.
  • The default settings are, from top to bottom, Just Friends, TELEXo 0 (address 0x60), TELEXo 1, (address 0x61), ER-301.
  • The bottom key on this column is a mod key, hold it and touch any follower toggle to go to follower select mode. Now the follower keys in the third column are instead radio buttons to pick a single follower, until you touch the mod key again to go back to follower toggle mode. The right side of the Grid in follower select mode is for reprogramming I2C functionality. Each column is a byte, most significant bit at the top. You can use this to change the address targeted by a given follower slot, or to reprogram which command byte is sent for “trigger” or “note”. The address is the first column on the right half. The command byte values can be found here and here. The fifth column from the left enables sending extra bytes after the pitch value is sent to a follower, I believe this is only meaningful for Just Friends, see below.

This is just a straight mapping from note values sent by each app to notes on the output device. In the case of TXo TO.ENV and TO.OSC.SLEW can be used to achieve sustain and glide. In the case of Just Friends, since JF.VOX takes a velocity value, I tried to map the Kria duration value to the velocity, but have no idea if this works. Sending a velocity value as an extra 2 bytes after the note value is configured by an extra row of toggles on the follower select page. I have also not tested any Arc apps so the control mappings might feel weird. My limited midi testing seems to be okay.

4 Likes
#130

EDIT 03:

I have successfully managed to reproduce this Kria/Ansible crash multiple times in the last couple of hours. Sometimes it takes a minute for it to crash other times upto 20 minutes. All I did was send a M 25 KR.CLK from TT to Kria. Kria’s clock is set to its fastest. Not sending anything else on i2c, no cables connected to TT or Ansible. The time it takes to crash is arbitrary and sometimes when it crashes, only 3 Gate LEDs remain lit usually its all 4. Sometimes the grid and preset button remain responsive, other times not.

Edit 04: I reinstalled 1.6.1 official to check if this issue persists and I can report that after an hour of sending M 25 kr.clk, no crash has happened.

Video Reproducing Kria crash (takes a couple of minutes)

Preset Button Response Issue

Also something for testers to maybe check, if the Preset Button starts to behave weirdly after an or or so of heavy use but where the module doesn’t crash and functions as expected - short pressing it would change apps instead of bringing you to the preset screen as in this video.

EDIT 02: Notice in the video below that when the Meadowphysics app comes on, it is going at an extremely fast clock that is even faster than when its internally clocked to the fastest setting? I am not sending any TT commands to Meadowphysics, hence something maybe happened with the internal clock?

EDIT 01: I have tried to reproduce this and after about 20 minutes of using Kria, I was having the issues with the preset button being unresponsive, short presses would change apps sometimes, this was mostly happening with Meadowphysics to Earthsea. And the preset page on Meadowphysics is very difficult to use, short grid presses in trying to scroll through the presets would almost always return me to the app making it impossible to save and load presets. On Earthsea and Kria, this seems to work ok, but feels a bit unstable.

Here is the second video of the preset page issue (@csboling):

1 Like
#131

This sounds excellent!
I’m trying to wrap my head around it before I flash my ansible.
Is it possible to assign the 4 Kria tracks to say:
Track 1 - Ansible out 1
Track 2 - Ansible out 2
Track 3 - JF single voice
Track 4 - ER-301

Thanks for all the amazing work your putting into this! :raised_hands:

2 Likes
#132

All tracks will go to the Ansible outputs as well as to the selected follower(s). You can turn on multiple followers at once but it makes a ton of sense to map them across tracks, I’m a little flabbergasted I didn’t think to implement that. I think it makes sense to always keep the main Ansible outputs active though.

Sorry, to clarify: The existing implementation maps the 4 tracks across the first 4 voices of each selected follower. It is not currently possible to assign specific tracks to only send to specific followers.

1 Like
#133

Thanks for all the detailed info and videos.

I ran this for the past hour before work and have not seen it. I cranked it up to M 10 and my setup (Ansible, TT, TXo all right next to each other, daisy chained) still seems stable. I’ve also patched an audio rate square wave to the ext clock input at the same time without a crash. When I crank the ext clock frequency the gates on tracks that are internally clocked all go high, but the TT clocked track keeps running and if I reduce the frequency they go back to normal. Edit: After running for 15 minutes or so with M 10 and an audio rate external clock I did get a complete Ansible lockup, where all gates were stuck high and the grid was frozen (not refreshing or responding). Replugging the grid it was just blank + no trigger or CV output until a power cycle, TT was still working in this case.

This definitely should never happen regardless but I’m down to thinking some kind of hardware difference must account for making it more likely. Do you mean TT and Ansible are the only things on the I2C bus in this test? If not I realize it’s a pain to mess with a working I2C configuration but I’m curious if the extra bus load makes this more likely. Other things to maybe look at: are the Ansible PCBs well seated with each other, is the I2C connection well seated, does a different USB cable make any difference? It can be pretty awful to try and experiment with this kind of thing when you don’t know when it will strike though. Lots of people have pretty complex I2C setups though so if that’s the problem it would be a pretty major deal breaker.

Even with hardware differences I’m completely puzzled how this would be more of a problem in the beta firmware than in 1.6.1, there have been no changes I’m aware of that account for something like this. Earthsea introduces a few of its own timers but nothing has really changed with how clocking etc work. Here’s an idea that may or may not be less painful than messing with your I2C interconnect: I will build several different firmwares that revert different changes, like a build that takes Earthsea out, a build that removes the Kria ratchet and note div sync related changes to note timing, etc, and we can try and systematically narrow down what firmware changes could be responsible. Will follow up with you in PM tonight.

1 Like
#134

Just as a point of reference, I’m still on an older build, but Kria has been stable for me so far, no issues at all, both with internal and external clock.
I’ll update later this week and use it some more/run some more tests and report back.

1 Like
#135

Quick update: Since my last post, I have installed the last firmware from 01/07/2019, ran the same test setup with only TT sending clock to Kria and managed to go on for 2 hours without a crash and without having the issues with the Preset button! I am really clueless as to what could be the issue with the previous version, or my sequences but so far so good. Will report if anything happens again.

1 Like
#136

Hello,
Just to say that I have been playing extensively with the previous build and I am going to perform tomorrow with it as well.
No freezing or leds problems.
I have also used very fast clocks and very slow ones as well as internal clock.

It seems very responsive to me.
Finger crossed for tomorrow, I will try the new build after the gig.

2 Likes
#138

Two days ago I finally found the time to install the latest Ansible beta (2019/07/03). The update went flawlessly, so the the reason for the problems I mentioned earlier in this thread was in fact a wrong cable. Buying a new USB A-A cable did the trick.

The new Kria features are awesome. Thanks a lot for the hard work on this! (And no crashes yet: very stable so far.)

I have one issue though: I’m clocking Ansible externally (Pam’s -> In 1) and I don’t manage to activate independent time divisions on the TIME page. I switched the left and the right Glyph off (according to the manual) and tried various other settings, but when I change the note time division the trigger time division follows automatically and vice versa.

The middle Glyph (Division Cueing) doesn’t work either: Even when it’s lit, all time division changes are happening immediately.

I didn’t use the TIME page much in V. 1.6, so apologies if this is just a user error.

1 Like
#139

Are other parameter divisions also changing in sync? If either of the glyphs on the right side of the bottom half of the clock config page (key 1) are lit, divisions will also be synced even if the left-hand glyph is off.

Seems okay to me on this build in all modes I tried, with or without external clock. It’s a little more evident what it’s doing at slower clock speeds? Can you post or PM a video?

#140

All glyphs on the TIME page are off, all parameters I tried are linked. I PM’d you two videos (a second one for the cueing). If it works for you I’m probably doing something completely wrong.

Thanks!

#141

@csboling thinking i’ll tag 2.0.0 and post a release? we can do point fixes if needed. same with tt 3.1.0

#142

Teletype 3.1.0 I’m not aware of any issues or outstanding features, should be good to go.

Ansible is I think also stable enough to tag 2.0.0, think this will do a lot to reduce confusion. The following work is ongoing:

  • Investigating this weird crash which I think must have to do with specific I2C configurations or something else that makes it hard for me to reproduce. Sounds like most users have not encountered this.
  • I2C leader mode. This I think will need to wait for the next version: it has not been confirmed to work with JF or ER-301, and if you patch in a super fast external clock it will crash after a couple seconds.
3 Likes
#143

@csboling just replied to my PM regarding my time division problems, and of course it was just a user error: I changed the divisions on the CLOCK CONFIG page instead of the TIME MOD page. Sorry about that. Everything works as intended.

One related question though: The standard TIME MOD has the leftmost key activated, so I can only divide the tempo. What if I want to speed up (multiply the clock) of a parameter though? I could start with sending a 16x clock instead of a 1x or 2x clock to the Clock In, but then I would have to initialise the TIME MOD to a higher (division) value for each single parameter to start with a neutral timing. How are you using TIME MOD? Is there an easier way to achieve individual clock multiplications?