The path towards Axoloti 2.0

#81

Very good and valid point. My computers fan tend to spin a lot and then computer gets hot when loading heavier patches.

Agree, an IC socket would be awesome, so one can update as one likes. MUCH more flexibility would be great.

#82

I don't mind the live button at all, actually kind of like the 'play with some code/patching, hit the live button and check it works' workflow. If I'm making actual music I don't have the patcher running. I can see the appeal of not having it though.

I am concerned about custom objects, they've become a big part of my setup, at times only to replace a whole bunch of messy logic objects I've patched together (to save sram) but also important stuff, like my sequencers, etc.

There's maybe some buggy behavior in the patcher I'd like to see fixed, and the problems people are having with the move a dial, crash a computer thing could be addressed... Though I've not had that issue it worries me that people who are obviously experienced with the axoloti are.

I get concerned about stock levels, its always in and out of stock, which I don't mind, it's just I'm always worried it'll never be in stock again. I've invested a lot of time into axoloti, and I'll need more/spares when I have the money.

But, on the whole I'm happy with axoloti just as it is right now. I don't need constant updates about what's going on, when something new is ready it'll come. We were told it was being worked only a few months ago.

It's an amazing thing, the axoloti. it has totally revolutionised the way I make music.

#83

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. it's actually a great time for me usually to re-light my spliff. i think building a live patchable modular environment on axoloti connected to a computer is kinda defeating its purpose?

But yeh this all has been said 50 times before and either way i am excited what johannes comes up with next, but i also would wish for some kind of more regular communication on the status..

#85

These are points on which we agree completely.

#86

as @SmashedTransistors pointed out already, a "always live" axoloti would be the ultimate modular system. you could build an UI that controls patch generation if you want, not just changing parameters of an existing patch

#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