Ansible Arc Rhythm Generator

Is it possible to adapt the Arc Rhythm Generator (the maxforlive device) to run on the Ansible? None of the CV outputs would necessarily be utilized, just triggers.

This is just a thought that came to mind today, sorry if I’m being a bit of a nuances (this is my second thread in two days, the last thread was about something else).


I’d love this as well. I think the interface is a little tricky to fit into Ansible (stretta is using the m4l device on the screen in this demo as well), but the basics should barely fit. Something like

turn encoder = change density
hold left button and turn encoder = reseed pattern for that encoder
hold right button and turn encoder = change speed for that encoder

Not sure about the specifics. Also, I think it would be nice to find some use for the CV outputs, even if its just the density or speed of that output expressed as a voltage. Or they could output a gate on every step that the pattern doesn’t generate a step on, such that you get both the pattern of gates you set up with the encoder as well as the inverse of that pattern. That’s usually very useful for logic operations.


@x2mirko I think you’re spot on for the interface! I also really like your idea of having the CV outs as voltage representations of the density-- you’re right the basic features would just fit but I think this shows what a good fit the Ansible is for this program

I’m beginning an attempt to modify the existing Ansible Arc code to include a Hello World program as a warm up to adding a Rhythym Generator program, but there’s some basic information I’m missing that I hope someone could provide me with. Firstly, I see that the Ansible uses a 32-bit AVR Atmel microcontroller, will it have enough room to handle an additional program? Also, besides the source code on Github, is there any existing very basic code for the Ansible/Arc?


there should be plenty of room still!

there isn’t anything else for ansible but if you just need to see how interaction with arc is programmed you could take a look at the following white whale examples:

  • this was meant to be a template for somebody developing an arc firmware for white whale. it really needs to be updated but might be a good starting point, check the comments throughout the code.

  • this is orca code before grid support was added, so just arc. this is also for white whale, so you have to be aware of hardware differences.


I really really hope you succeed at this!

1 Like

@scanner_darkly , thanks!! That first link you provided is great, the comments help a lot!! I’ll be looking at both of these the next couple days

@jasper_ryder , I definitely can’t promise anything but I’ll see what I can do :slightly_smiling_face: if I’m unsuccessful and enough people want it I’m sure we can look for community development


no problem, will be happy to help with any specific questions once you get started.

1 Like

So I started a Hello World program by modifying the ansible_arc.c file, I’ve uploaded my code here:

Unfortunately I hit some snags when compiling

Do I have to declare the functions I’m adding in another file besides ansible_arc.c?
Maybe I’m biting off a bit more than I can chew here.

I’ll maybe have some more time this week to look into this a little more
@scanner_darkly would you have any advice on how to proceed?

sorry, was away, having a look now.

you do need to declare functions in either ansible_arc.h (or if you declare in ansible_arc.c do it before they are called or assigned). i tried a quick fix but there are other valid compilation errors - where do you define mArcLevels? that should go to main.h (see where mArcLevels is defined).

a good way to approach this might be making smaller changes and then trying to compile after each step.

1 Like

I’ll declare my functions in ansible_arc.h and maybe see what is unnecessary of my code and delete that, incrementing slowly, thanks!

this is kind of a tangent, but it would be really awesome if the Ansible firmware was structured a little more flexibly so that additional apps could be added, but as it is, its sort of hard-coded for two apps in either hardware mode.

Is it? Taking a look at the code where it switches modes it looks to just be calling a case

What I attempted to do was to add another case

I’m not actually sure if this will work/ if it’s proper

ah… maybe its not as hard-coded as i thought… i guess what would be really killer is if there was like a boilerplate template for a grid or arc app on ansible that lived in its own .c/.h files and you could just start modding it to begin building your own app.


That would be really nice!

i don’t think there is a specific limitation on number of apps, it’s just a matter of adding all the appropriate handlers, grid press/encoder rotation processing and LED rendering. a boilerplate template would be great! (would love to do it if i had the time).

1 Like

So I’ve worked on it a bit more and I’ve gotten less compile errors with quite a bit of clean up

If anyone else wants to jump in at this point to help development that would be greatly appreciated, I’ve uploaded my changed files here:

you need to declare hello_state structure in ansible_arc.h and uncomment

it’s basically a structure that should hold any state variables you want to persist in flash (including presets). take a look at levels_state_t and cycles_state_t as an example. there are other errors but let’s start with this one.

another thing that might be helpful - i’m working on porting earthsea to ansible, and this commit shows you everything you need to do in order to add a new app. it’s for grid but might still be useful (and it includes a support for presets). once something like that is set up you basically just need to write code to process key presses and update LEDs.


Thanks!! I’ll be looking into your earthsea/ansible port. On a side I was getting main.h compile errors when hello_state was uncommented and it was due to something regarding the i2c address, but I’ll look at your port and see how you handle this-- I really appreciate your help with this!

1 Like