The path towards Axoloti 2.0

SirSickSik 2019-07-03 12:32:05 UTC #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..

weasel79 2019-07-03 14:07:28 UTC #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

bambrose 2019-07-04 11:17:31 UTC #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%

SmashedTransistors 2019-07-06 13:16:34 UTC #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.

servandisco 2019-07-07 08:53:32 UTC #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.

SmashedTransistors 2019-07-07 18:52:06 UTC #92

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

jaffasplaffa 2019-07-07 20:15:27 UTC #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.

lokki 2019-07-07 22:11:32 UTC #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...

SmashedTransistors 2019-07-07 22:15:38 UTC #95

It seems there is some activity on the github repo

jaffasplaffa 2019-07-08 04:13:26 UTC #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.

tele_player 2019-07-08 04:58:05 UTC #97

A couple of build-related changes.

SmashedTransistors 2019-07-10 16:28:47 UTC #98

Yes, but it shows that he is alive.

bcalleb 2019-08-11 14:16:29 UTC #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.

Jens_Groh 2019-12-06 10:21:28 UTC #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.

johannes 2019-12-19 02:38:59 UTC #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

thetechnobear 2019-12-19 12:37:16 UTC #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

SirSickSik 2020-02-18 14:42:09 UTC #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.

Nbdarvin 2020-07-02 08:03:37 UTC #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)

SmashedTransistors 2020-07-03 05:39:52 UTC #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.

mrdrbobo 2020-07-04 19:12:45 UTC #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.