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.
@johannes
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.ā
edit
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.
Cheers
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)