The path towards Axoloti 2.0

#87

btw, I must honestly admit that I don't know the why's and how's about the new features.. perhaps I'm not understanding it and it's actually better for me.. dunno..
my "complaining" had more to do with the annoying crashes I'm experiencing ten times a day, which can't be good for my computer.

but if I understand you correctly lokki,
could I change filters and oscillators while being live, thus not needing to build them all into the same module?

I'm also still wondering whether I could put a header file onto my sdcard containing a set of oscillators and filters. Then somehow load them as text into a module while being live.. haven't been able to do anything like this yet..

#88


so what would be the benefit of using axoloti over lets say maxmsp or puredata then? it would be just another modular patching environment which offloads processing and audio i/o on what most likely is a worse platform than the computer/audio interface the patcher software runs on.

i guess we agree that the only standalone vision of this, a complete realtime live patcher running on the axoloti only, is absolutely unrealistic. unless you make an all new axoloti board on a raspberry CPU/RAM/complexity level.

and another thought i had on this last night while changing all my synth controls from CC to NRPN, entailing a whole lot of recompiling on axoloti, midibox and arduino: axoloti compile is such a breeze. a giant complex poly synth on axoloti takes about 1/10 of the time my pretty basic arduino script needs to compile and upload :man_shrugging:

#89

i mean one of the biggest appeals of axoloti is being able to easily build standalone devices, that you can run without a computer once you finished building it. so yeah as i said before i am also absolutely not bothered with the (relatively short) compiling and uploading time at all.
Perfectly Put. This I agree with 100%

#90

Having factory objects in the flash will free a lot of SRAM.
Most of the time my patches are limited by SRAM not by CPU.

#91

"Having factory objects in the flash".. but what about the community objects then?. some community objects became essentials for me (and sure for many people too also).. Like the Oled objects & DP saturator.. Thanks for them by the way.

#92

I guess there will be a process to pre compile them and upload them in SRAM.

#93

To be honest I rarely use any of the factory objects anymore, except the tables.

The factory library has become a tiny fraction of the ever growing and way larger and way more usable community library. Nothing in the factory library has been updated in years. So in a way it is kind of outdated.

So not sure how much of a difference it will do to have factory library in flash, cause I am not sure how much they are actually used anymore. But yeah, I don't know the math so I can easily be wrong here.

#94

really? i use mostly factory objects and create my own objects if i need something that is not possible with them. things like a sine oscillator don't really get outdated, so i don't see a need for an update there...

#95

It seems there is some activity on the github repo :smiley:

#96

If you embedd the object and make edits to the fac-lib objects they are not fac-lib objects anymore. I do too often start from a factory object, but in 99% of times I end up editing it and embedding it.

#97

A couple of build-related changes.

#98

Yes, but it shows that he is alive.

#99

Joel,
Just jumping in the thread.
Sorry to disappoint you about Raspberry PI but the Raspberry PI HW is very disappointing performance-wise.
It is a great platform for newbies and people wanting an easy out of the box experience but for more than that... a lot of other companies do a better job.

#100

A new branch "2.0.0" has appeared in the axo objects repositories (both factory and contrib). Not yet in the main axo repository though.

#101

Sorry, live patching did not make it into 2.0. It required to take three rather large steps at once.
One of them is dynamic loaded libraries and dynamically linking against firmware, and this made it into 2.0. The other steps are annotating dynamic loaded libraries so that they are patch-able objects, and then auto-generating and on-the-fly modifying binary glue-code that moves data and calling its functions. I wrote some test code for the latter, independent from Axoloti firmware, but still premature. The evil is in premature optimization, which I did far too much, and ran into a very hard wall. Efforts will resume after 2.0 reaches full stability.

Live patching Axoloti
#102

congratulations @johannes - great news, you've done so much hard work - great to see it out in the wild.

I think a very wise move :slight_smile:

#103

ehm, perhaps a bit late to note.. but I just thought of something that would be nice to have on the board:
Buffering the inputs independently so that two mics could be directly connected to the inputs without the need of an external buffering.
Atm, when you connect two mics/piezo's, they start influencing each other, so they both need to be buffered independently before you connect them to the inputs. So it would be nice if it would be possible to connect these without adding an extra buffer circuit, though I'm not sure this could be done with the current stereo input as it has the common ground, which is probably also the reason the signals should be buffered first.

#104

Please make axoloti 2.0 in form factor of Pocket operator:
Same size
Same set of the buttons
Same captions
2 or more endless (or cAtching) pots
2 aaa batteries
Big Oleg screen
Same tactile buttons
Addressable rgbs on buttons
And please small 3.5 jacks instead of full size midi

Any artist will pay you fortune (if application to emulate pocket operator in Ableton with sync to axoloti will be developed)

#105

Full size midi sockets were designed the way they were for a good reason! The mini jack midi sockets are a non sense.

MIDI has no acknoledge nor error detection system (put aside the sysexes).
The DIN socket offers robust tubular electrical contacts that are reliable mecanically and electrically.
Jacks have ponctual electrical contacts and mini jacks are not what i call mecanically robust.

#106

Axoloti 2.0 is not about new hardware, but about new software, a.k.a. Axoloti Patcher.
If you want an enclosure with knobs, oled screens, buttons, etc, you can build that yourself or buy an Axoctrl from HohumLabs or AxoControl from MusicThingModular.