Ansible Earthsea


Really glad these ideas are getting a lot of attention, but I feel I’m getting a bit lost with the note/key options listed here.

Maybe I’m off track, but wouldn’t a note priority (and maybe even legato) option solve these issues (like what’s available on most monophonic moog synths)?

Oh…and for the record, my main hopes/requests are (in order of importance):

1-Quantized, lit keyboard layout (as mentioned previously (I know my guitar fretboard, but it would be nice not to think about where I am on the grid constantly).

2-Multi-channel mono sequencers (how amazing would that be)

3-Fix note “issue” (currently being discussed).

Thanks in advance to @scanner_darkly for even considering it (and the time needed to do so).


glad im not the only one who’d really like to have multi channel mono ansibles :slight_smile:


@scanner_darkly is your source for this anywhere? I couldn’t spot a link but was reading on my phone which isn’t ideal

I’m vaguely poking away at porting ansible grid stuff to PD for the organelle in the background and earthsea poly might be quite interesting on that platform


Personally I like the simplicity in the voice allocation already implemented and would prefer that to not change. I do like the thought of switching gates<->triggers for both recorded and live play, that would certainly free up a lot of expression control and I think keeps in theme with having bare and laid-out options, letting the performer decide rather than the code.

I’m not sure if note priority options would necessarily fix anything, and might be more of a clutter than a boon, but maybe that’s just how I’ve adapted to using AEarthsea so far.


One small issue slightly associated with these that I’ve come across is getting some notes stuck when I’m trying to play and select voice allocation simultaneously. If I enter the voice allocation and select new voices while holding down a note that I’m playing live, that note will get stuck on—I have to toggle it off if I’ve made a selection and then exited the voice allocation page.


this script can be a good start: > teletype: grid # code exchange

can you explain a bit more? how does note priority apply in mono case?

re: scales - yes, that’s on to do list. likely just using kria scales.

will take a look - if it’s an easy change i’ll fix it (if it requires more work will have to wait for new version).

yeah, need to think if it’s possible to combine the old and the new way…


Kria scales would be perfect; thanks!

As for note priority in the case of mono:

I just thought that AEarthsea notes might stop “glitching” for some folks if the program can recognize when you have one key pressed and you subsequently press another key (while still holding the first key).

It seems as though (whatever the circumstances/playing styles), if two or more keys are held in mono mode, AEarthsea doesn’t decide which note should take priority and you may get nothing.

On a monophonic synth/keybed, you can depress multiple keys and only one note will sound (by virtue of mono), but because of the note priority settings you’ve chosen in a menu (last note, highest note, legato), the result is predictable to the user and consistent in the program (e.g. each key released in a group of held keys will ungate the next key according to chosen rules).

Maybe, I’m going too deep here; not sure…


currently, this is how voice allocation works: when a new note is played it will check if there are any unused voices available. if all allocated voices are taken it will take over the earliest note.

it will always play the latest notes. if you have only a single voice allocated, and you press and hold a note, then press another note, the pitch will be changed to the 2nd note. but the gate will stay high since there was no release.

now, one thing to remember is that mono synth keyboards can retrigger envelopes if you overlay 2 notes, and ansible earthsea can’t (unless we use a hack with inserted gap). the reason for that is that such keyboards actually have access to both the trigger at the beginning of a note and the gate that is held high while a note is pressed.

it would be possible to replicate such behaviour if in addition to the gate output there was also a trigger output per voice, and you had an envelope that had a separate input for retriggering. then you would patch the gate into the envelope itself, and the trigger output would go into the retrigger input.


Got it now…thanks for taking the time to explain the situation again. Not sure why the trigger/envelope concept didn’t click with me the first time, but it’s clear now.

It that case, I vote to leave the current gate programming exactly as is considering gate delays and/or additional outputs allocated to triggers would cause more issues (seen and unforeseen) imo.


I’m probably in the minority, but at least for live performance, I’d like to experiment with option 1 if we can come up with a way to make it available. Option 3 is also workable, but the way I’ve been playing, gates would be nice to maintain.

this comes down to whether the voice selection buttons act as toggles or radio buttons - i was thinking the latter as it would make switching faster. could perhaps allow multiple buttons to be selected while held?

That sounds good. When one is held, pressing another would allow multiple selection, but pressing one remains radio button.

I’m not enamored with any particular multi-sequence implementation. Multiple mono sequences would certainly be lovely, as many have been saying. However it has to work is fine by me. Just looking forward to being able to layer. :black_heart: :sparkles:

1-Quantized, lit keyboard layout (as mentioned previously (I know my guitar fretboard, but it would be nice not to think about where I am on the grid constantly).

I’d also love to see the keyboard guide. I’ve gotten pretty good at finding my way spacially from practicing scales, but more visual reference points would be lovely.


after more consideration i’m afraid option 1 is not possible after all… the main reason is that it would complicate several other features i’m considering adding. hopefully they’ll more than compensate!


Sorry to hear, but obviously you know the inner workings so I completely understand.

Any chance you could at least re-implement the code that @tehn added to the original Earthsea module which allowed you to light up individual keys of your choice and (I believe) save those lit keys with each pattern?

It’s been awhile since I’ve used an actual Earthsea module, so anyone who has feel free to iron out my ideas here…

Looking forward to the other features you have planned :grin:


Just ordered my first Ansible and I’m already looking forward to installing Earthsea.

Any word on i2c ops?


so, we’re at the point where i’d rather spend time working on a new version. as i planned from the start the new version will be a complete rewrite, so adding features to the existing one doesn’t make sense i’m afraid.

with one exception: as the new version will take some time i will consider still adding things that are: 1) quick to implement and 2) are a common use case.

so, displaying scales and/or keyboard guide - might happen.
i2c ops - likely new version.

now might be a good time to mention the new version will likely have a somewhat different UI. again, i hope the benefits of new features will outweigh having to learn a new UI!


If you’re totally rebuilding can I ask for opinions on brightness levels. Just wondering whether many people are having earthsea make the output of their case much noisier (high pitched) the more buttons are lit and the higher their brightness. I’m just worried an even brighter ui will make my problems worse. I haven’t seen much feedback on this though so maybe it’s rare, in which case ignore me. Thanks again for all the attention your giving earthsea, it’s my most used ansible mode.


Awesome news about a new version. Looking forward to watching its development.


Are you looking at significant changes to the UI? Any thoughts on how hard that might be to back port to the original Earthsea?


I’ve solved this problem by externally powering grids.


i can lower the brightness of the progress bar in the current version, as discussed - it’s a super simple change. but need to consider non vb users as well, as anything lower than 8 in brightness won’t show up. but in general i’d say it would be impractical to make a new UI dimmer - it would limit the expressiveness of the UI without fully solving the noise issue. the noise issue really need to be fixed at the source.

mostly changes in the left column, rearranging some of the modes. re: porting - for any new dev my plan is to have a clear separation of hardware specific bits to make potential ports easier.


I actually installed the tool chain, though I need to order the debugging cable. I had an idea for an Ansible app, so I was reading over the source code. Speaking at a high level, how are you considering changing your approach?


couple of things:

  • separating code into 3 main components - hardware interface / UI controller / the engine
  • having clear separation in the engine between patterns and what is being played back (basically, having a separate data structure for what is being played with patterns being just sources for that data - should clear up some issues with hanging notes and allow for more non destructive runes and simultaneous pattern playback)