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?
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.
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.
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.
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).
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!