Lost My Marbles in a fit of Peaks

Is there any further interest in porting Mutable Instruments open-source resources for Axoloti / Akso? I recognize that we have individual Braids osc objects, clds, and lmnts, but Marbles, Peaks, and perhaps a few others would be incredible additions.

Is there any desire for these? And is that desire matched by coding skill that I don’t possess?

1 Like

We’ve definitely discussed broad MI compatibility! The question is how much to add to the current patcher and how much to put that same energy into making a new one.

This kind of thing has been on my TODO list for a while. Basically allowing the hardware to run DSP code from various sources with as little manual intervention as possible.

The current MI ports needed a bit of massaging I think to get them to work.

There’s nothing stopping us from bringing in arbitrary open source DSP code, modules and so on. I want to make that as easy as possible. In the ideal case you can work in whatever source language you like and then “freeze” into a form that can run on the embedded hardware. So the firmware would have more “plugin host”-like functionality than it does now.

One way to pick up a bunch of these in one broad stroke would be to make it possible to run VCV Rack modules directly. I have a prototype of that lying around from a while back that I need to dust off.

Basically the “real way” is going to be to support APIs where we can pick up many modules or elements rather than doing it manually over and over.

1 Like

miRack port from VCV Rack is much more efficient on CPU and made for small machines, like Rberry pi3 etc.

@f33d miRack is super interesting for sure. I need to check in on its progress. I think I looked at building it for a Pi quite a while ago and it was still rough. I know that there was a bit of controversy about the source code there between Andrew and the miRack developer. VCV is now GPL, but I think previously it was under a more permissive license. I think miRack is derived from that older version. Maybe this has been resolved now?

The prototype I did was based on the latest GPL VCV code at the time and was prepared specifically for near bare metal ARM use. The challenge is that VCV is very much a desktop application so there are a bunch of things that have to be stripped away to get the core DSP engine going in an embedded environment.

By the way, I think this kind of code licensing controversy and in-fighting in our community overall is counterproductive but I understand it to some extent. Akso and Axoloti have the advantage of being mainly GPL. Any reuse of VCV code would be derived from the GPL version and compliant with licensing there. Things start to get weird when different people are using GPL code in ways that are ultimately monetizable; there are philosophical questions about fairness and ethics and so on that arise even if the user is complying with the license. The key is to only release code under a license you’re comfortable with. Once stuff is out there, it’s hard to control what the community will do with it beyond what is established in the license.

It’s an interesting thing to think about that comes up over and over: how do we make sure that open source developers can make money off of what they create? It’s a tough question.