Ansible Earthsea


Continuing the discussion from New module: ansible:

Spinning this off into a new thread to discuss the options and ideas for porting Earthsea to Ansible (or Ansible + TT + TELEX).

So far there is an idea to use the TXi as a knob input for Earthsea on Ansible. There was also a suggestion for the possibility to use Grid + Arc, which sounds amazing but might be techinically difficult. How could you plug both in at the same time?

New module: ansible

Two comments from @bpcmusic from the previous thread, for context.

@bpcmusic observed:

…the ES firmware (ported to Ansible) could be modded to (use) a TELEX input expander for the four hardware knobs. The i2c code is in the common library, so it would be fairly easy for an enterprising individual to wire up. (Note: my plate is totally full. I’m not volunteering to ever do this - but I’d be happy to help an interested party with the TXi integration - if they need it.)

After this, @GoneCaving wrote:

How would that work, as afaik there’s no way for Ansible to pull data via i2c? You could allow it to be set from a teletype command, and grab the value from TXi.

…to which @bpcmusic graciously (and perhaps tantalizingly) replied:

There are a number of ways it could be done - a little research would be required.

Right now, the expanders are slave devices. If the Ansible acted as a master, it could request the values of the four knobs at some reasonable frequency. i2c busses can support multiple masters - but I’m not sure offhand if the Ansible’s chip and underlying AVR library allows it to be both a master and a slave.

Another way would be to modify the TXi firmware to act as a Master and to send out values to Ansible when a knob changes position. This way the Ansible can stay as a slave and i2c chatter would be minimized. This would be a fairly trivial firmware modification for the TXi. I’d be happy to do it if someone was working on the ES port.


@scanner_darkly and I were discussing this a little over instagram.

to me, the main things that I would love would be a polyphonic note grid + a pattern recorder
so the note layout from earthsea but functioning the way ansible does in midi mode.
Personally I feel like the 3 CV outs and shape memory portion would be a secondary concern.


Yeah. The note grid, pattern recorder (and transposer/arpeggiator) would be amazing.

I don’t think it’s necessary to replicate the way that the shape memory worked specifically, but it would be nice to think about some way of including the slew and evolving patterns. It could be as simple as a modifier button and using the grid as a slider (like time scaling in Kria). A simplified version would be great.

For example, you could have a two track Earthsea on Ansible by using Gate/CV 1 + CV 2 for note and one parameter out, then Gate/CV3 + CV4 for a second track.

Edit: one more thought – It could also work like Meadowphysics, where in the settings you choose the output mode. i.e., 1 voice with 3 parameters, 2 voices with 1 param each, or 4 voices with no parameters.


yeah, my plan was to look into porting the note grid / pattern recorder portion to ansible after i finish a couple of smaller things that i’m working on right now. i have a month long trip coming up in a month too, so this will push things as well, likely it’ll be 2-3 months before anything happens (and orca port is lower in priority - still planning it but i really want to work on new things! having said that who knows, maybe i’ll get impatient and do a weekend porting marathon…)

i still don’t have earthsea so my understanding of it is limited, so correct me if this is wrong but in theory you’d only need ansible to communicate when a shape is triggered, and TXi/teletype could do the rest without any custom i2c code? the only problem is ansible not being a master - this can still be addressed with a super fast M script polling ansible, although it would be nice to find a way for ansible to trigger tt scripts without tying ansible gate outputs. this necessitates making ansible a 2nd master though, which might introduce more i2c issues.

edit: realized the previous paragraph doesn’t provide enough context - so i was thinking that you wouldn’t use ansible outputs for CV shapes, but instead you would use ansible/grid to play notes and trigger CV shapes and then use teletype to output CV shapes - this would give you 4 additional outputs and the flexibility on how to enter CV shapes - could be TXi, could be TT patterns, could be another ansible connected to TT in Levels or Cycles mode.


Silghtly OT. But I was wondering if porting the Game of Life stuff from the nw2s over to Ansible might be on the list at all… I was watching the demos the other night after discovering it, I’ve wanted to jam out Conway style foreverrrr.


haven’t thought of that - the main attraction of that implementation to me was to have CV control over the rules. it’s like circuit bending the game. and then you can have some of the outputs influence the rules, so then the game changes itself as it’s played. but this could be achieved with remote commands too, i’ll give this a thought!


Remote rule changes via Teletype would be super attractive, you could do nw2s style self patching from Ansible back through Teletype that way too.


yep, or via TXi.

another question would be how to translate the game to CV and triggers - it could be simply mapping number of live cells to voltage but i wonder if there is more interesting interpretation that would make it more playable.


Live cells to voltage seems like the best reflection of game state, but with multiple outputs and varibright, there are a lot of options. The way it was implemented on nw2s seemed fairly solid. Maybe extra features along the lines of ‘rune’ triggers could make it more playable. i.e set a trigger point, add a rune press, when the trigger is hit, it plays an arp, or rotates outputs etc.


trigger points is an interesting idea, and being able to assign different actions to them - food for thought… perhaps mapping different shapes to different notes.

it’s interesting to consider how to make an automaton device to be more of a performance instrument. this is one of the fascinating things about grid, it’s easy to map its structure to functions, breaking out of that is the interesting part (and to bring this back to the thread topic what makes earthsea so special). in the game of life you control evolution essentially, so perhaps the secret to making it into an instrument is by mapping the characteristics of evolution itself instead of direct mapping. so you could have voltage that corresponds to how fast evolution is or how static it is, its density, overall population, number of surviving cells or the oldest generation still alive etc etc.


Those all sound like aspects of “sound”… density, static vs evolving, decay, … you could map the different descriptive aspects of the game onto the same descriptive aspects of cv.

Could also integrate the Earthsea note grid and quantized scales. As the game evolves it creates cv that maps to those notes and the various parameters.

I.e. Density could change the rate that the cv changes, like a slew. Static vs evolving would change the notes that are being output.

Might be worth a separate thread for Game of Life and keep this one for Earthsea chatter.


I was thinking along the lines of each output representing a cv value based on life/death/decay rates of the population but couldn’t conceive of how that would actually sound musically, since the numbers wouldn’t necessarily reflect each other. I was also thinking of a two layered version, where the underlying game was the one generating the note data, constantly being reset or having its rules changed, and the top determined how it was played, one that wasn’t affected by rules but played out in a standard fashion and was seeded by hand. Also considered a variation where the top layer was solely populated by 4 gliders playing arps.

@emenel it would be interesting to have it share a scale system, like meadowphysics/kria on ansible, I’m not sure you could have the both run at the same time though and have it be a coherent instrument. I’d like to see them both tied together however, Earthsea/Conway alternate firmware.


i saw the title of this one and i have to say it’s exciting. I will read through the posts but is this happening?
I JUST moved my ansible into my performance case and the chance to run earthsea on it would be tight


i’ve been meaning to work on this but got sidetracked by other projects. it’s still on my list though, among a couple of much bigger projects, so this will likely be done in parallel with those at some point. but first i need to finish clock div/mult for white whale, it’s been driving me crazy…


There’s nothing wrong with taking a break from something that is driving you crazy to work on this for a bit :stuck_out_tongue_winking_eye:


indeed! and i have, been working on it on and off for several months now. at this point though it’s a final battle between us, either i make it work or i will have to admit defeat… either way will free me to work on other projects :slight_smile:

should probably clarify, it will not be an exact port of full earthsea, but a variation as discussed here.


Still fairly new to monome modules, just researched Earthsea and I am amazed by the concept. Would love to see a port of this over to Ansible, is that a realistic proposition? I was planning to buy another ansible (when next available), but am tempted now to look out for a used eathsea.


I am still dreaming of a polyphonic earthsea ported to ansible :crossed_fingers:t4:


this port for earthsea/just type is amazing! but lack of “sequencer/recorder”