I'll try to shine some light on my development plans:
When arriving closer to a fresh release, I was hitting a hard wall. One was getting a perfectly nice working undo-redo, the "live" switch barrier is not one that can be crossed nicely by undo-redo operations. Recompilation by launching gcc is not snappy enough. A second issue was sharing code along objects and avoiding name-conflicts, I was not really happy with the "modules" approach (in the experimental branch on github).
So I've been tinkering with a radically different approach to the Axoloti architecture: rather than generating c++ code from a patch and using gcc to generate a native binary, generating and uploading a binary (document, not arm code) representation of a patch to the Axoloti hardware, and "compiling" that binary document into native executable code on the Axoloti microcontroller. An interpreter approach would add too much overhead. It does not aim to be a full compiler, it only loads binary objects and generates native code to call functions, and passing data from outlets to inlets.
It's an approach I had dismissed in the past. Writing something that resembles a compiler is not a suitable one-man army project. It also locks the code strongly into the arm architecture.
It's large transition: the object library will need to turn into binary code, breaking current attributes. It affects the GUI, the object definition format, the patch file format, the usb communication protocol, the firmware... Hard to get there via incremental non-breaking changes.
I have not announced this effort before since I first wanted to proof its feasibility first. I have underestimated the complexity of the development, and has taken a far deeper and slower effort than I had imagined. Yet it is still my highest priority, believe it is the way to go, and addresses most griefs.
Please allow me till the end of this week to publish a first draft on github. Thanks for your patience and understanding!