The path towards Axoloti 2.0

#21

of course!!

indeed, but it comes at the cost of performance (i hit the sram limit more often though as well), and since i don't want to do live patching on a pc, i would rather take the few extra cycles :slight_smile:

#22

Great to hear there is progress going on!

While I'm personally also more on @lokki s side, using as much of the the resources as possible and then rock axoloti in standalone I think better UI and workflow with the patcher + live patching will make axoloti much more attractive to a lot of people.

I could also imagine that if someone could ever get the patcher to run on like a raspberry pi live patching could really really great actually.

#23

Personally, I'm also kind of on @lokki's camp in using axoloti mostly without a PC, and to be honest, a perfect undo/redo is at the bottom of my list of issues with Axoloti.

That being said, looking at the current code that's generated, there doesn't seem much oportunity for avoiding function calls usually, so I wonder if this changes would have any practical impact over performance. Also, if objects are pre-compiled, I imagine that there would be some oportunity to do some function inlinining inside them, wouldn't it? specially if code sharing is implemented. So am I correct in thinking that most of the extra function calls would come from small objecs with small methods being connected to other objects? If that's so, I don't know, it doesn't seem like too much of a problem to me.

I wonder, if it results on being a significant problem, would it be too hard to add some kind of "freeze switch" to subpatches, so that they are precompiled as a whole, trading the ability to modify their insides for performance?

Even though I also don't really personally care about the issues this seems to solve, I applaud the decision to do it. I'm familiar with starting a big project, realizing a lot of time later that some desired features need it to have a significantly differente paradigm, but leaving those changes for later, because it's too much of a hassle. Then, the more time that passes, the harder it seems to make those changes, and any other development is affected by the ghost of those changes, because you know, once you change the paradigm, you'll have to redo a lot of that develpment. So I'm very happy with movement; any sign of life is better than a stale codebase.

#24

For what's it worth, I second lokki's/Oscar's point, too: standalone use with maximal performance for me is the most important thing with the axo.

#25

...me too,I'm with @lokki , @Oscar and @Captain_Burek,
though I get the point of what @johannes is after...

'live patching' as in Max/Msp or pureData is great for people who
have no clue or interest in things like a compiler or such,
and will be more than happy with a well-structured factory library.
so, stereotype, artists/musicians vs. coders/nerds.

personally, coming from Max/Msp, what made axoloti a 'game-changer'
for me was the possiblity of just Boom! opening the object editor and
modifying the code itself..which I guess is not possible in a 'live-patching'
environment.
coding and live-patching provide entirely different possiblities,and I'm
totally happy with having both, at the cost of the 'live-switch'.

I would rather like to see improvements to the firmware and the patcher
based on the current concept,like:
- better implementation of SD - card usage, for example being able to
load/save data 'in the background'
-improvements to the patcher , for example custom color scemes and
zooming (it's damn hard to read for older folks)
-some easy way to convert Max/Msp gen~ - patches to axo,which
probably includes floating-point math

maybe there's a possiblity for having both options, live and switched,
for axoloti 2.0?

cheers
Robert

#26

I dont value live switching at all, or very little.

I would put far greater value on making a switch to floating point away from fixed point.

That would make life a lot easier for me.

Also a more clear compatibility roadmap and portability to other more capable devices would be a literal game changer, not live loading.

#27

I am going to chime in and value the efficiency over live coding.

I feel the same as most others here, I prefer to has as much processing power as possible rather than live coding. As @SmashedTransistors says I hit the Ram/CPU limit in almost any patch I make, so getting less CPU is not good.

In the beginning I thought it was a bit annoying have to go live/unlive all the time, but one just have to get used to it. It really doesn't bother me anymore.

#28

I've worked a little with Johannes and he is obsessed with efficiency. To my surprise, he often takes the route of getting something working very efficiently first as opposed to my more conservative approach of getting it working then optimizing it. So, though I haven't seen any numbers, I am betting these changes will still be very efficient based on his personality.

Additionally, ST has been upgrading HW, so i'm antipating upgraded HW someday. Already the H7 is available with 400MHz and some other, faster chips are becoming available, too. We should also keep in mind some other aspects of these changes. IIUC, and it's a very technical matter so maybe so maybe not, there will be improvements in compatibility across different versions of the compiler. If true, this would make collaborating with others, such as customers, more compatible. For example, I may be able to send my customers updated firmware without having to worry if they have win/lin/mac and what version. Hopefully I'm not just thinking overly idealistically :slight_smile:

#29

Hey great to hear from the OG! Very excited about further developement. i am currently trying to gather a list of most requested featues from the forum and plan to put up a poll then. Personally, i also don't really have a problem with the patch/live switch situation right now. And i'm impressed with the number of people creeping out their holes just to say the same thing..

but yeah all hail @johannes i think people needed a little spark of light!

#30

Love to see some signs of life in the community.

I'm in the camp that quite likes live patching and thinks it would be worth it. I probably have some bias being an old school Nord Modular user. There is something about the flow, "jam" quality of patching live that is just wonderful. I don't think it's an all or nothing proposition. I'd like to see the possibility of live patching without imposing the cost on users that want to squeeze every last cycle of DSP performance out of the system. Like perhaps you live patch for a while to arrive at a design and then have the option to "freeze" it for more efficiency.

#31

that would indeed be a killer feature!

#32

I think that @SmashedTransistors said the opposite of what you're saying. I get your point, though.

#33

My point was that I always push it to the limit and go over it. And yes, it is the ram that is overloaded first, I agree.

#34

Oh, sorry. Ok. Yeah, me too.

#35

No worries I did write cpu.

I corrected it to ram/cpu now :wink:

#36

Live patching was one reason I didn't regret trading my Capybara 320 system for a Nord Modular and Nord Modular G2. The compile time, though only seconds, really started to be real annoying for simple edits to patches.

#37

I am not sure the toll for function call is high on the STM32F4.
Unlike higher clocked cpus that have to manage function calls side effects on cache and long pipeline.

#38

I'm on your as well side, man

#39

Thank you, please do! I backed you on the first kickstarter, keen to have a 2.0.

#40

Great to hear about the ongoing development. If the v2.0 could support an updated processor that would be fantastic.

I think the live mode would be more accessible and potentially broaden the audience. However a more comprehensive and free user guide than the current ebook would probably increase the audience customer base also.