The path towards Axoloti 2.0

#61

I feel like it's kinda derailing the thread to just add random feature requests, but i still agree with you so much @JoshuaACNewman the object browser is really painful. there should be a couple attributes you can search by, like author, function, also some kind of autocomplete/middle of the word search. what do i know but i feel like those common search/db aglorithms shouldn't be that hard to implement. also for my sanity please make it non-case-sensitive....

window management adds to this, the object browser comes up in the same tiny size and in the same position every time, it should save resizing and window position.

that being said i have to reinstate that even if all axoloti developement would halt forever today it would still be the most amazing thing in the digital diy world.

edit:
food for thought:
https://www.pjrc.com/teensy/gui/

#62

@weasel79 : How is the PJRC link relevant? It's a tool which helps you get started writing an audio app on Teensy, but other than being crudely graphical, there's little else in common with Axoloti.

#63

i thought its relevant as inspiration in two aspects:
- it has what seems a much more stable, modern and convenient patch editor including a really neat object browser. while it STILL looks a bit old and outdate, using it makes you at least feel like its 2018 and not 2003 axoloti. bonus - it even works seamless when web based, so probably super leightweight. i am aware this is not nearly as powerful as axo but has some definite upsides.
- teensy audio librbary has built in support for i2s and a lot of other hardware extensions, with teensy 3.6 being based on the same M4 chip.

#64

Yes, the Teensy Audio System Design Tool looks pretty nice, but it doesn't generate, compile, or upload code, and it handles a small number of statically defined objects. Yes, starting from scratch, somebody could rewrite Axoloti to be web-based. But there are very few developers (one, I think, probably not full-time ) working on Axoloti.

STM32F4 and Teensy both use Cortex-M4 CPU core, but that's really not as important as the fact that they're not using the same system-on-chip or system-on-module.

#65

yeah i am aware this is a completely different approach and merely scripting together a couple of defines and includes, not doing all the heavy load axoloti does.

to make sure my comment isn't misunderstood by others - i am in no way suggesting this teensy GUI is better than axoloti or is what axo should be. i just thought some parts of it can be used as inspiration for what departments axoloti should catch up on. and nobody really wants web based axoloti right now i think, i was only pointing out how nice the editor runs even in a limited surrounding like a browser.

#66

Hi everyone, I'd like to chime in and add that like everyone (I assume) I'd like to see any news regarding axoloti. I understand @johannes said there would be a commit at the beginning of april and delivered but since then, there has been no news about axoloti 2.0 and the github repo has been absolutely quiet.

I'm saying this because I believe that any news would be good, since development depends entirely on Johannes nowadays, I understand that it must be extremely stressful. It's probably not his main source of revenue and activity, and the price of the boards, probably don't pay for much dev time. Which can justify the lack of development.

With that being said, I think any insight about development would be interesting. And I personnaly would like to know what this kind of project entails and what it means if you're the only developper on an open source project.

#67

What it means: Axoloti hasnā€™t attracted enough SW and HW engineer interest to develop a life of its own.

I think itā€™s dying. I hope Iā€™m wrong.

#68

You guys are bumming me out with this negative talk!

The idea of doing audio DSP on cheap commodity hardware is not going anywhere. In fact it's only going to become more pervasive as the available hardware becomes cheaper and more powerful. Axoloti is a first step in what I see as a long line of future devices.

I think part of the problem of achieving Arduino or Pi - level market penetration and engineer interest is that there's already a huge ecosystem of plugins/apps/devices for music making. Arudino or Pi etc fill a niche that doesn't have a direct alternative on hardware people already have. There's also a huge ecosystem of more "engineering" level DSP dev boards and toolchains, etc. I don't think the musicians aren't going to go out of there way to hack around with hardware necessarily unless it's really straightforward or offers something different; they already have laptops full of plugins and apps. The pure engineers are going to gravitate toward stuff that isn't so focused on sound synthesis and processing; they might be doing DSP in some completely unrelated domain. Axoloti is in a bit of a gray area in between these two use cases. I think that makes it tough to turn it into more of a universal standard.

So part of the issue is usability. A musician needs to feel reasonably at home and not overwhelmed with technical detail. Another issue is communication. It needs to be clear what a board like this offers that is different from what people have already. The simplest thing I can think of is that it can be standalone. You can make a proper instrument that can be played away from a laptop.

TLDR: I'm an engineer. I'm interested. I'm going to do everything I can to make sure that the spirit of this project lives on.

BTW I'm sick of forum discussion all of the sudden. I think it would be interesting to try to get people together on IRC or Discord etc to discuss this stuff more actively. Ping me if that sounds interesting to you.

#69

same. i feel your frustration @tele_player but what's the point of coming on here and writing "axoloti is dying" that's just straight up destructive and negative.

yes axoloti has flaws and yes johannes should communicate more but i looked around everywhere. there simply is no alternative. nothing comparable to what axoloti is capable of. it's the only platform that let's someone like me build the synth of my dreams. even with all the limitations right now it's an absolutely incredibly powerful and versatile tool.

#70

Hello @johannes,

where can i find this draft on the github ?

Have a great day.

#71

You literally just made up something negative to say in the face of evidence of the contrary.

Johannes is one guy, working on an independent project. Heā€™s not on your production schedule.

If you want to help, support him. Donā€™t just come here drooling self-indulgent negativity.

Hereā€™s the quite-active Git: https://github.com/axoloti/axoloti/issues

Go contribute if you want something. Otherwise, thank the developers (of which there are several) for working on this.

#72

That Github link shows very little activity.
Iā€™m not being negative, just realistic. Johannes wrote in April about the direction his development is taking, and that might prove to be interesting.

But there still doesnā€™t appear to be any current collaboration in either the firmware, patcher, or hardware. Such collaboration, to me, would constitute evidence of a living, thriving, not dying, open source project.

I like Axoloti as it is, I only comment in this thread because some people donā€™t seem to see that there hasnā€™t been anything new in years.

#73

I don't understand why we (Axoloti users and community contributors) don't have any information about what's going on.
And worse than that, i feel uncomfortable to have promoted the Axoloti at the SynthFest France as it is no more available (and for an unknown delay).

I think that Axoloti 2.0 is a big leap and that external perturbations can be difficult to deal with but... well

a monthly note from @johannes on the Axoloti webpage would be nice.

#74

Has anyone though of the possibility of switching to a browser-based WASM-driven backend for the editor software?

This would make updating the editor UI much easier. It's always struck me as strange to choose Java as the basis of the editor, when all the DSP code is written in C.

Using C/C++ compiled to Web-Assembly modules and HTML/CSS/JavaScript for the UI would make more sense, I think (provided access to the hardware could be made to work in this environment).

Separating the UI from the rest of the editor code would remove one of the biggest roadblocks to the much-needed overhaul of the look and feel of the editor, which ultimately, would probably do more to improve accessibility than removing the Live switch.

#75

I think that most people underestimate the advantage of a fully live running virtual modular synth.
Some here had (or still have) a clavia modular synth and can tell how this nasty "live" button affects the sound design workflow.

I think that the massive refactoring under progress (hard coded and live linked objects in flash ram) can help to have a live API.

Thus, given a protocol (for examplea good old Midi Sysex implementation :slight_smile: ) it will be possible to live control and program the Axoloti... in whatever language you want to.

#76

I have Nord G1 and G2s, and agree it is nicer to be able to hear what you're doing immediately.

On the other hand, I'd like to see long-overdue improvements to the Editor UI, and I have a suspicion that this new initiative is going to see that put on hold again.

#77

some other people are concerned about their custom objects and possible need to rewrite a lot of them much more than about ā€žnasty Live buttonā€œ ā€¦

#78

I still don't really see the problem with the live button.. if your synth is ready, don't you just play with the parameters while being live?
For me it isn't really needed to be able to hear my patch "right away". I'll just build something of which I know what it will do and just go live when I'm ready.. The fact that I can write my code inside the editor is a live saver, because you can more or less instantly detect mistakes in the code.

I'm more worried about the possibility that my computer won't be able to cope with it being live all the time. I see it with synthedit already, that when I'm editing while playing, it often crashes the program (and it's not the program..).

Currently I already have a problem with the editor, where my computer completely freezes now and then when changing a parameter and needs a hard reset with the off/on button (couple of times a day for the last couple of months...). I've been told this might be caused by overloading the memory that's available to java.
So for me, the preferences would also go to dropping java for the editor, more so as I've heard several ICT friends complaining about it and asking me why the hack it's used for the editor at all.

As for further "wishes" about an axoloti 2.0..
wouldn't it be nice if the memory had an IC socket, so you could put in a bigger memory if you'ld like (even if this would ask for some DIY construction on a second board for connecting an IC of a different size). Even better if we could swap the processor..
Also, "normalised/dedicated" communication over ic2 between axoloti's is still vƩry welcome..

#79

I'm inclined to agree. Makes no odds to me whether it's live while editing or not. The exciting bit is setting up a patch that works and then adjusting the parameters (you've spent time creating) live.

#80

Personally I do not mind how Axoloti works. I am just worried that having a "live" environment, will take away precious resources from us, that we could use for patching. I got both G1 and G2 and Axoloti and I really don't mind Axolotis workflow. It's different than G2, but to me it's fine.

I really prefer a non live environment, with more dsp/ram, rather than a live environment. I am worried that is gong to have an impact on that side if Axoloti. I think many people of this forum hits the ram wall very often, so doing anything that might have a negative impact on memory and so on is a bad move.