Last year I worked on a feature sort of related to this. It was a per-track toggle that would only advance any of the parameters when a trigger fired: (Kria) Feature(?) trigger-step params
Wouldn’t that be the same as the implemented synchronize / standard sequencer function?
What I meant was, that the CV parameter is happily moving on but only gets read when a trigger occurs.
EDIT: Wait…no it’s not the same…sort of…
The config page I’m talking about is the one from holding down key 2 on the Ansible panel, the one where note sync/loop sync are configured. On that page it should be a single toggle toward the left side of the bottom row.
I think probably it makes sense to group as many features together as possible before cutting a new release. In particular the preset saving feature is important for making updates make sense for people who’ve been using an older firmware version, but this is a big and error-prone addition that needs a lot of testing to be confident in its correctness before it goes in the official firmware. I’ve also worked on Ansible support for some new Teletype remote ops that would be nice to include, and would like to see if I can chip away at some of the known bugs in addition to adding and polishing features. So I think it might be a little while before an official update makes sense. However, the preset feature is implemented in such a way that you should be able to keep updating to new betas as often as you’d like without losing presets if you want to stay on the bleeding edge.
This makes sense. Delaying the CV change I think is pretty straightforward (basically set the DAC value when the trigger output is set high, rather than immediately when reaching an active trigger step) but keeping the previous CV value if it has already changed when the trigger happens seems trickier. I won’t have time to prototype this for the next several days but I can give it a whirl. Not sure if this is always the desired behavior or if it should be configurable, in which case it needs some UI.
This seems very useful, and may not be too hard to implement. In addition to off-panel configuration by Teletype, the USB save feature should also give us the ability to do some more persistent configuration by tweaking the JSON file, so that’s also an option for introducing some settings without cluttering the grid UI, though these would be a bit more of a pain to tweak. In particular I’ve been thinking that you could use this to load up a custom scale table if you want to use something other than equal temperament. Glide customization could also be done this way. Going this route would benefit a lot from some kind of PC program that would let you load up a preset file and graphically tweak it, rather than having to sift through >300KB of unindented JSON to find the setting you want.
This is awesome, hadn’t seen this thread. I would use it all the time. From the video (without looking at the code yet) am I understanding right that each trigger in a ratchet will clock the track? In combination with the ability to toggle gates on and off when ratcheting this seems super powerful. We would need to figure out where to put the UI. There is one extra column available in the section of the scale page that’s now used for TT clock enables + step direction settings, which seems like definitely the place that makes sense, but it seems like it might get kind of confusing with several different settings clustered in that corner.
Big thanks to everyone for all the testing and discussion so far!
Tbh I don’t remember. I’m pretty sure I implemented it so that it was actual trigger steps and not ratchets that would trigger it, but it wouldn’t be hard to modify it to use the individual ratchet triggers too.
Yea that is where I put it.
Is this commit part of the 1.61 FW? or a totally different branch?
These commits are in master now but an official (2.0.0) release has not been made yet (soon!). 1.6.1 was released April 2018. For the latest betas, changelog, and ongoing dev discussion see Ansible Development and Beta Firmware Discussion.
Hey @csboling, hope you’re well! Wanted to update on the latest firmware testing, my Kria/Ansible crashed again today, second time this happened on the latest and also one of the previous firmwares.
It would freeze up, all the gate lights would light up, none of the CV lights light up, but the sequence keeps playing though without outputing gates.
I tried to short press the preset button but it would change apps instead.
I took a video but didn’t upload as it’s too big for here, if you want to see, I could upload somewhere else.
That’s really interesting, especially that the sequence keeps playing instead of the app freezing completely – so the CV outputs are changing, but the gates aren’t? Or the sequence appears to be running on the grid but the outputs are all constant? Do you know what you were doing when this happened, like what page you were on or what parameter you were changing, were you working with a fast or slow master clock, did you have external clock or reset patched, was there I2C stuff involved in your patch? Definitely would like to fix this before release, I have some hazy ideas of what would cause this but it sounds like it might be a bit tricky to reproduce (and therefore to be confident that it’s fixed). @Leverkusen it sounded like you had experienced something similar?
The CV outputs kept outputting the melody, but the Lights stopped responding (maybe the pitch was too low? Don’t know) and all the gate lights went on super bright but none of the gates were actually opened.
If I remember right, the grid was looking pretty normal.
Unfortunately I don’t remember doing anything with Ansible when this happened, think I was adjusting another module.
I was synced to TT clock, the internal clock was set to the fastest speed, no cables were connected to Ansible, and the only thing in i2c was the clock from Ansible which wasn’t very fast.
It was quite arbitrary, when it happened the first time, I thought it was an issue with that specific Beta and didn’t report as I soon installed a newer version (not the current version) and the issue went away until today on the latest Beta.
I’ve posted the video for reference, though it only shows my trying to do short presses on the preset button. But you’l be able to see the 4 gate lights on when Ansible is on I think. Hope it helps!
The info about TT clocking is super helpful, thanks – are you clocking all tracks at once? It looks like the mode is changing correctly also, when you press the preset button you’re getting the preset keys lit on the left side of the Grid? Curious also if the Kria pages can be changed. Also this is fine again after a reset? Although if you’ve still got it running, I’m sure I can think of other stuff to quiz you on before you reboot Just trying to get an idea of exactly what’s working and not, if the one thing broken is the gate outputs then that helps a lot with where to look. The CV output LEDs I believe are not controlled from software but part of the actual output circuit, so if pitches were still changing I expect that part is okay.
The mode is changing correctly but I am only short pressing the button, which should give me the preset page, instead it changes modes. I am not pressing any preset buttons on the left cos the preset page never presented itself.
Immediately after a power cycle, it acted a but strange - it loaded to a 6-step sequence, but the sequencer played all 16 steps on the immediate restart. After that, it was repeating at 6 steps.
My memory of this is hazy, I didn’t keep the crashed Kria on for too long afraid that something might fry lol.
This is really weird, I’m not understanding in the code how this would happen, it seems like both the short and the long press happen through the same handler function. I set the internal clock to maximum and am using
L 1 4: KR.CLK I in the metro script, with
M 100, and have run it for an hour or so, then at
M 50 for a while without seeing the gates stop working, so I’m wondering if the problem is something else completely unrelated that happens randomly :c
What all is on your I2C bus? I see Ansible, TT, ER301 in the video – I’ve got Ansible, TT, TXo. Really a bit baffled here, it would also be interesting to see if turning off TT clocking and going back to the internal clock would cause the gates to start firing again. Any other notes you can share about your Kria configuration or TT scene might also be helpful, but I realize it’s happened pretty much randomly and so might be hard to recall. You shouldn’t be in danger of damaging anything from a glitch like this since it’s almost certainly just a software issue.
This is my first time trying to update an Ansible.
I’m struggling with finding and installing a dfu-programmer. Can anyone help out or point me in the right direction? I’m on a Mac, and I have both High Sierra and Mojave at my disposal if that helps.
Is this the right link? https://github.com/dfu-programmer/dfu-programmer
I struggled getting that installed regardless but hopefully I’m on the right track.
firmware update instructions: https://monome.org/docs/modular/update/
Perfect, thank you! That’s the link I was missing somehow. doh.
Yes, that sounds similar to what I experienced. I had no chance to dig deeper into it by now though. All I can say is that I did not use i2c or any external clocking when it happened. i2c is connected though and I sometimes use the reset all command in tt live mode to get everything back in line. But that did not cause the lockup.
I’ve not had any freezing issue but my Ansible is clocked internally with no i2c connection.
I have 301, JF and Ansible connected to TT on the i2c.
I’m sending 7 channels of triggers from TT to the 301 using sc.tr.
I was only using 2 channels of Kria when the crash happened.
Meaning on i2c, it was just this and the kr.clk command being sent, though only kr.clk was being received as the 301 wasn’t setup to receive the triggers in this patch.
But as it happened also as @Leverkusen expressed without any i2c communication is surprising.
Hope we can get to the bottom of this as it will be a disaster if it happens during an actual performance!
@csboling: Ok crashed again today. I still have it on in case you’re online and want me to try things out.
This time I had 4 channels of Kria running. I was on the Octave page of the second sequencer channel when this happened, I played around with some Octaves, then left the grid to tweak modules - this is when it crashed. Again it didn’t crash when I was directly working with Ansible or TT (except the clock).
- Kria still responds to i2c commands (see video for kr.res command), and speeding up the metro or reducing it affects Kria (didn’t managed to video this).
- Removing the grid and reconnecting it - at first there is no response, then it comes back on after about 10-20 seconds.
- No alt-notes, glide, ratcheting were used, only Octaves and pulse length.
- each sequence had a different loop length.
does anyone experiment with using kria as a modulation source instead of a melodic source? i suppose you could clock function generators / LFOs with the gate outs and run the cv outputs through slews (unless kria has slew now and i just completely missed that - edit: i just looked at the docs and yes, there is glide! yaya!).
i’ve been imagining an feature where kria can be switched into modulation mode. instead of programming scales you can select waveforms and map how they are scaled to the clock (in the spirt of the 4ms PEG).
i’m aware that this presents so many UI riddles. perhaps it’s better as a completely separate ansible mode…