This looks really interesting. STM32F4-based engine, PC-based Java GUI that emits C++, compiled by gcc and uploaded to run standalone on the engine. Plus an STM32F1-based knobs-n-buttons controller. Software all open-source. Not sure about the hardware. Either way, very interesting. Well, the infrastructure and framework are interesting. The actual synthesis components provided so far are pretty dull - but it is an open framework, and more interesting components could be implemented or ported to it. Two instances of enhanced Braids code could run on it simultaneously, for example.
what’s with that name? is it some kind of pun that i’m not getting?
i know what an axolotl is, but what’s that ‘i’ doing at the end?
āxōlōmeh is the correct plural, according to WP, so it can’t be that. Maybe it’s a pun in Flemish?
maybe they just wanted to avoid a product name that ens with ‘meh’.
I still think that if it’s Flemish they should have gone with Vakov. So there
Well, it does look promising!
@sneak-thief has examined its source code a bit more closely, and I think isn’t quite so excited.
It is a mash-up of C (not C++) code borrowed from various places. That’s not necessarily bad, but it looks like a quick hack. Still, beautiful swans can grow from ugly hacked-together Frankengoslings.
@BennelongBicyclist I am aware that it is not elegant code yet, there is a lot of room for improvement. In the meantime it does a few things though.
I did use chibios rtos/hal, fatfs, gnu tools/gcc, dfu-util, java/swing… they are solid foundations and writing such components from scratch for this project would be insane.
My contribution are the Java gui (45k lines of code), firmware/patch interfacing, the object library (~400 objects), getting the thing to talk, board design, prototyping, testing… Not in this order, because every part was needed to develop and test every other part. I think this is a substantial effort.
If any borrowed code is not or incorrectly attributed, please point me to it, and I will stand corrected.
Yes, I hope it grows into a beautiful swan^H^H^H^Haxoloti, and I’m committed to continue efforts.
I looked at the code. It achieves a lot with a very simple infrastructure - I think the overall approach (everything is compiled) is a good idea for this platform.
C++ is the exception rather than the norm for this kind of projects. And there aren’t that many ways of implementing a biquad anyway. So I’m not surprised the code is C and looks like something seen somewhere else.
However, what puzzled me was the use of fixed point over float point. I’ve coded quite a few audio objects in recent projects (oscillators, filters, effects) for the F4, and rarely saw improvements in rewriting to fixed point from single precision floats. I believe the availability of 32 extra registers for FPU operations helps a lot. My code tends to do things in blocks of 16 or 32 samples, and within a block loop everything fits into registers - book-keeping variables (sample counters…) in standard registers and state variables of the DSP algorithm in floating point registers. And there are a few places when not having to care about saturation/rounding issues helps a lot!
Well from a user perspective it seems like a nice addition and I’m very much interested to see where it’ll go. The videos sure make it look like it can reach interesting heights and I’d love to see what new objects will be added (maybe stuff that can mess with MIDI in the path of a G2?). The size is small enough to make it a tease, so if the selling price follows suite I don’t see why it won’t be a success (other than being yet another OS hardware synth; yes I’ve read the answer to that on the site but I wasn’t convinced).
It’s definitely good to see that someone heard the call for a new version of Micromodular and answered it.
Yes, sorry, I didn’t mean to disparage or dismiss Axoloti, and I certainly didn’t mean to criticise it for using components and code from elsewhere - that’s a good thing! So instead of a “mash-up”, I should have said “a clever assemblage”, perhaps. And yes, there is a hell of a lot of new code in there. I just meant that it didn’t appear to be a project that is ready for contributed plug-ins quite yet. But I honestly didn’t spend much time looking at it, which is unfair. Apologies.
C and floating point is ideal playground for DSP. Old dogs like me don’t do C++ well. And having floating point is … liberating. If I can set up a scenario of a simple, single block with stereo input and stereo output, with handling of asynchronous events (MIDI) for control, I’ll be very pleased to buy one.
I think this is an awesome project. Sort of like an Arduino for DSP.
Quick question: Can the patcher UI handle more than one connected board at a time?
aaaaand it’s at 25011 euros – congratulations!
@niklasni1 The site states “Pricing yet unknown.”
Totally stupid of me, didn’t know there was a indiegogo for it!
@johannes: welcome to the m.i. forums - it’s nice to have you around!
i’m toying with backing your project on indiegogo.
but i’d love to learn more about the control panel. how exactly will it interact with the core module? will it make it possible to store and choose between several patches - which doesn’t seem to be possible with the core module alone (or is it)? also, a rough estimate re price and availabilty would be much appreciated.
[edit:] also, of course: what’s with that strange name?
I had to fund Axoloti even if I’d just backed Phenol. The possibilities of customizing firmware and/or modules in an open source “Nord Modular cousin” were just to tempting. The code seems quite approachable, even if it isn’t quite as elegant as the MI code IMHO.
Float vs. fixed: anyone has benchmarks of, say, biquads? I thought fixed was faster because there are more tricks you can do with fixed. Examples where I believe fixed has an advantage are: the phase accumulator in an oscillator, table lookup, saturation. Adding a float inlet/outlet type and conversions to the framework would be easy if needed. But also could cause confusion for users who don’t know float/fixed.
@BennelongBicyclist : I totally agree that the plug-in format needs revision, it grew incrementally over time. I preferred transparency, publishing it in its current imperfect state over keeping it closed and announcing fuzz that cannot be verified.
@min_phase : apart of the uglyness of the plugin format, yes, it is easy to do. You’ll currently need to convert int to float yourself. What makes it nice is that other objects in the patcher can work as “lab equipment” during development. If you use the parameter system rather than receiving midi CC’s yourself, they can be mapped by the user to CC’s, adjusted on the screen, used in presets etc…
@niklasni1 : The patcher UI currently does not handle more than one board at a time. You can run two patchers simultaneously, but it can get confusing. Multi-board support is not a release feature, but I guess it can develop over time.
@mic.w : Axoloti Core takes first priority in development. Control will need to go through a few more design iterations before I can freeze its features, making a schedule, or announcing a price.
Core can load compiled patches from sdcard. There is an object that can be triggered to load a new patch. This could be hooked up to midi pgm change for instance. The current Axoloti Control prototype allows to navigate through the contents of the sdcard and load a patch.
The name, well, maybe I should rename it to “elements”, I think that would fit very well with the product since the patcher allows the user to combine different elements? (runs for shelter now)