(kria) ratcheting + alt note + glide


probability for all parameters in Kria gets used only when the parameter step advances.

So for ratcheting, say you’ve got your ratchets at a clock division 4 times slower than the trigger parameter. When the ratchet step advances, if the probability allows it to change to a 2 ratchet value, you’re going to hear those two ratchets for the next 4 triggers until the next step in the ratchet parameters loop.

Does that make sense?


that makes sense, but i think i didn’t ask specifically enough, sorry!

i will install when i’m home later tonight, but was wondering about a scenario like this:

  • parameters are all loop synced
  • i set an octave shift for a step
  • i set 25% probability that the octave shift will occur
  • i set a ratchet to repeat that step

when the step is hit the first time, let’s say the octave shift doesn’t happen.

when the step is repeated with the ratchet, does the first nonevent carry over to the repeat (ie: the parameter wasn’t changed when the step first advanced, so it absolutely won’t change on subsequent ratchet retriggers)? or would the re-trigger roll the dice again and possibly results in the octave change for the repeat?

apologies if this is muddy. i think i’m hoping that this version of kria will bring in some of my favorite aspects of the early-days app parc, namely that all parameter probabilities for a single step are re-thrown when that step repeats. creates really lively sequences.


Nope, as it stands, it doesn’t work this way. Probability is only taken into account when a parameter step actually advances.

And ratchet re-triggers do not send clocks to any other parameters… i.e. won’t advance the notes sequence for individual repeats.


needed it twice to get it fully, thank you! super excited to try it out tonight. alt note + glide have been wishlist features for me for a long while.


Cool glad it makes sense. Next and last “alt parameter” I’m going to add will be a gate delay so our Kria sequences can swing… though I probably won’t get around to that for at least a week or so.


@tehn has rightly pointed out this needs a corresponding documentation update. Does anyone have any plans to work on that? Would anybody like a hand with it? I’m a reasonably good docs writer. I would, however, wait until there’s a more locked featureset - is alt note definitely sticking around, for instance?


I’m new to all this Github stuff but watching this and the Earthsea thread with great interest. The contribution and the work being put in by members of the community is amazing.

Could someone verify my understanding below - would be really helpful for a non-technical person;

  • there are now two alternative versions of the Ansible firmware - the one linked to on this thread and the one on the earthsea thread
  • the plan is to merge these both back into the official version on Github, but in order to do this, quite sensibly, we’re waiting for some documentation to be written?

I’m in no particular hurry, just trying to understand the process…



The one on here is additional features for the Kria on the Ansible,

The one on the Earthsea page is a version with earthsea ported on to the ansible, now as beta version


here is an idea, what about dividing a note ? /2 /3 /4 ? just a concept to think about?


Yes, thanks. As it is all alternative firmware for the ansible, it was a question about process.


what about duplicating current pattern? thought it would be a good feature so you can make variations of the same pattern. :slight_smile:


you can already do this. hold the key of the pattern you want to copy the current pattern to.


wow! This is amazing work. Thanks to all who contribute.


hi. any chance we could get this ansible firmware combined with the new one so we can have awesome ratcheting kria, meadowphysics, and polyphonic earthsea?
i just don’t wanna have to not play with the new earthsea…

thanks, this is so fun!!!


i submitted a pull request and @tehn has said that he’ll merge it once someone updates the documentation to include the new params, which it would be great if someone would volunteer to do! :slight_smile:

Teletype 3.0

any word on the documentation updates?


I would also love to see this get released. Unfortunately I don’t have time to help with documentation for a month or so due to work…


Is there a template or specific format that the documentation needs to be in? I assume the html for the document page is stored somewhere. Is it auto generated?


Found 'em. Ill dig into the @freqout pull request and see if I can start to get something written up. No promises, but it will help me get my feet under me with my new Ansible.


it would be cool to have a swing range similar to the OP-1 sequencers 20% -> 80%, but i think that having anything happen before a track receives a clock would require a non-trivial restructuring of how everything works in there.

at the same time, the interface will likely just be 7 vertical steps so its probably for the best to have as much granularity from that as possible for the 50%->80% range.