Ansible Earthsea


#325

I just dug into this firmware last night - awesome work!!
I never played the original Earthsea, but the very familiar note layout (I’m a reformed guitar player) and especially the pattern recording was super cool. I can’t say I got the hang of really playing the additional voices well, but, I got it going.


#326

Ansible 1.6.1 is the latest and greatest firmware, right? Just making sure I haven’t missed something.


#327

You are correct sir.


#328

Official 1.6.1 does not have Earthsea merged in unless I missed something (very possible). This is 1.6.1 + Earthsea: Ansible Earthsea


#329

yep @xenus_dad link is correct. there is also a new test version that fixes a small lag between trigger an CV updates (in earthsea specifically) in this thread but it hasn’t been tested yet.

@emenel - could you perhaps update the original post with a link to the post with the latest “official” ansible+earthsea firmware? Ansible Earthsea


#330

For some reason I don’t have access to edit the original post, even though it’s mine… Maybe it’s too old and I don’t have the right access level?


#331

yeah there is probably a time limit on editing…


#332

@scanner_darkly, Is there a version of ansible that includes both earthsea and @dewb’s 256 version of kria? and will these get merged into an official release eventually?


#333

256 kria has a couple of bugs still. I was planning on merging it to master after earthsea etc. lands. I could probably make a branch that incorporates both if someone has a pressing need.


#334

More of a desire than a need, and certainly not pressing. Let me know if I can help hunt down bugs.


#335

that’s a question for @tehn!

@Dewb - are you planning to pull in the latest changes from @freqout? if you do then i could just reapply earthsea to your branch.


#336

Yep, all of @freqout’s changes are in the 256 branch. I went ahead and merged your earthsea branch into a new 256-everything branch, under the theory that if I’m going to think about a small task for more than 10 minutes, I should just go ahead and do it. :slight_smile:

@jasonw22 I can still occasionally reproduce cases in kria 256 where some keys get “stuck” on a page and can only be modified from the other view. If you do or don’t see that happening, that could be a useful data point. Here’s a firmware with everything (from https://github.com/Dewb/ansible/tree/256all):

ansible.hex (263.7 KB)


#337

Great! I’ll see if I can reproduce.


#338

@scanner_darkly - Is it possible to force a retrigger? I’m usually playing with a single voice. My slow fingers have a hard time releasing buttons when I try to play quickly. :sweat_smile:


#339

sorry - with all the forest fire smoke we’ve been getting my brain isn’t functioning very well - could you explain a bit more?


#340

Same PNW boat. :laughing:

Is there a way to make it so pressing a new button forces the gate to include an “off” pulse, read a re-trigger?

When I’m playing live with 1 channel enabled, I end up having small overlaps in my presses which cause the gate to remain open, thereby causing any related envelopes to also continue responding as if only the first button had been pressed.

I might be wrong in what is happening in the box, so pardon my assumptions. The desired effect is to have my envelopes retrigger on each press when playing a single voice with less precise fingers. :blush:


#341

Tested and approved in my case :cowboy_hat_face:


#342

i just noticed the same thing yesterday!


#343

yep, seattle’s been just as bad as vancouver… hopefully it’ll rain this weekend!

it is possible, but there might be a problem with this approach… say, you press a button, the gate changes to high. now you press a second button. at this point it could set the gate low and then high again - but this means that the 2nd note will be delayed. the delay could be very short, 1-2ms, but i wonder if it would retrigger reliably with such a short off stage? in any case, might be worth a try, i’ll post a test version in a bit.

edit: it’s a bit more complicated to change than i thought, won’t be able to get to it until next week.


#344

thinking about it some more, i’m a bit reluctant to implement it in the way described above. mainly, because it would add a delay to some notes, but a delay that wouldn’t be consistent as it would only apply to notes that overlap.

also it does complicate the logic somewhat, so can potentially introduce new bugs. right now voice allocation is pretty straight forward. with this change it will need to account for notes that are playing and and the notes that are currently queued to be triggered after a delay.

what about an alternative option? i could add something so that for live playing you could choose between triggers and gates, and then you could just set it to triggers and control the note length using your envelopes.