The path towards Axoloti 2.0

#41

Live patching is an interesting concept, and I could understand that it would increase the appeal of the Axoloti to people who are familiar with analog modular systems, where live patching can be a natural part of a performance. And as has been mentioned the Nord Modular (but isn't it only the G2 series?) for instance supports this.

However, I would also argue that the use case for the Axoloti and the typical Eurorack system is somewhat different. The Axoloti to me is a building block for building instruments; people build Axolotis into all sorts of enclosures with custom user interfaces, and the graphical patching environment means you can realize your ideas without having to write a single line of code, which is a huge step in allowing people with no programming or DSP experience to create musical devices. In contrast, a Eurorack or Nord Modular is an instrument in itself, albeit configurable. Sure, there are exceptions, such as Martin from the band Wintergatan and his 'Modulin' which is a Eurorack come electronic violin instrument, for instance featured in this video: https://www.youtube.com/watch?v=QaW5K85UDR0, but I think that is rather unusual.

Hence, the Live button I would say is not that much of a hurdle, as I think most users approach the Axoloti with an Arduino mindset, i.e. once it has been configured, the device is primarily used on its own.

The limitation I hit most often is RAM, the second is CPU. So from my very personal perspective, the first major feature I would like to see is the Live button uploading the code directly to flash and running it there, rather than taking precious RAM for this. (Even when flashing a patch to the Axoloti flash, it is still loaded from the flash to the RAM once the patch is started). I realize there may be issues with this primarily in the form of wearing out the flash, so some caution is necessary. Since the CPU time is the second most precious resource, anything that increases the CPU load I would consider to be detrimental.

Then again I would not want to deter @johannes from developing the Axoloti in the direction of his dreams. Any form of development to the Axoloti platform must be good, and can bring in a range of users which until now have avoided it for various reasons.

#42

I agree, anything that makes Axoloti use more resources(ram,cpu) than it does now, I dont think is a good idea. We hit that wall all the time.

#43

Hi everyone! I think this is an awesome thread.

I put a toe into the Axoloti waters when I borrowed a dev board from a friend. I compiled a few sketches, but nothing meaningful.

I have been doing development on the Raspberry Pi, the STM32/Blue Pill, and the Adafruit STM53 boards. As a java developer, I long for an environment with good sound fidelity, good realtime support, and a couple of options for programming / app development.

I find the 'Arduino' class machines to be too small for my needs. The larger Cortex M4 and M7 units I'm working with are on the right path, but are still very RAM constrained.

I like the new 'Compute Module' format for the Raspberry PI. I would like to see an Axoloti 'carrier board' for the CM3, which offers MIDI ports, dedicate USB port for MIDI usage; beautiful balanced TRS jacks like the Axoloti has now, and perhaps the same UI affordances (buttons, joypad, etc.).

If we go that way, we could use a more vanilla 'pd' or go with mobile Max/MSP patches...

I think the work that Adafruit is doing with hats, kippahs, and feather-boards is awesome. A stackable platform allows extensibility and customization.

I sure would like to have 8Gb or RAM; an SSD; and perhaps some on-board ARM chips for realtime help. And I'd particularly be open to adding FPGA to the mix. Go Signal Processing!

I'd easily pay $200 for such a platform (the carrier board) on the assumption that I would add the CM3, the SSD, or other off the shelf add ins. A $100 price point would be awesome for the base carrier board; with options for 'hats' to add functionality.

TL;dr I think the raspberry PI CM3 platform is the way to go. Keep the awesome audio I/O and leverage the larger community for 'hats' to add buttons, screens, etc.

Thanks!

-- Joel Dubiner

P.S. Check out Balena's carrier boards...


It's a good model for a potential starting place for an Axoloti carrier board.

PPS: I really need standard string concatenation commands, so I can make effective use of the file system. That was sort of a deal breaker when I was checking out Axoloti. As a Java developer, I don't need 'live' updating of the patch's 'code' but I do love being able to tweak the UI elements on the fly when the sketch is running.

#44

hey @jdubiner great input, we all want more CPU and RAM, but one thought i had - if your goal is vanilla PD or MaxMSP, why not just use raspberry or a mini-pc? there's plenty qulity audio shields available. and stripped from its own awesome-while-a-little-fiddly patching language, an axoloti raspberry thing as described by you would be reduced to a basic hardware shield extension. and that probably kinda defies @johannes idea of building a new, better standalone audio patching environment. i think a lot of people are attracted to axoloti because you don't have to use a full blown OS mini pc.

but i fully support the notion of moving the axoloti software to a raspberry-like M7 or M8 platform, GHz on multi cores and gigabytes of RAM...

#45

Seeing as there are very few people doing any development on the software (1?), and no evidence of any work on the hardware in several years, a wishlist seems inappropriate.

Practically speaking, and consistent with low cost/high value of the current Axoloti, Iā€™d like to see the STM32 F4 upgraded to the best compatible STM32 currently available at the right price (under 15-20ā‚¬), with some minor analog improvents on audio input and output levels and compatibility.

I expect this could be done without major investment in either hardware or software development. And the resulting board would still be under $100.

#46

I agree, seems like there are better STM32s that look compatible.

#47

I agree too, and maybe that would be something for johannes and the core contributors or other volunteers to group up on and start working on? since it is also the so far most requested feature on that poll i started. i'd be down to sponsor some stm32f7 boards for developement since i can't contribute to porting the code...

#48

Just chiming in to voice that I have no interest in live patching if it were to sacrifice even a small percentage of performance.

As @rbrt mentioned, zooming is something that I've wanted too.

The way the patcher exists now, placement of the objects affects performance. I'd love to see that eliminated. All of my patches are ridiculously long horizontal rows.

If there's going to new hardware, I'd like to see something FPGA based with the potential for processing video bandwidth signals, a native Eurorack footprint, and +/-5v CV inputs. @johannes, you asked the community at one point to help with promotion, etc. If you made these changes, Axoloti 2.0 would break the internet, and nobody would need to promote anything.

#49

Put aside the Axoloti 2.0,

I really would like to have an official release of the Axoloti 1.x with support for USB hubs :smiley:

It's a game changer as you will be able to connect a small keyboard along with a small knob board (think Korg nanos) to get a fully operational micro synth.

#50

wrt USB host support and hubs... I saw this interesting note from Greg Nutt on the forum for the NuttX OS. Perhaps it goes some ways as to explaining why we've yet to see full fledged hub support on an STM32 based host.

Yes, NuttX does support a USB hub.

It does not work well on the STM32 F4, however. STMicro makes great MCUs, but they always seem to cut corners on USB. The STM32 F4 device has only a minimal number of endpoints and the STM32 F4 host is next to useless for some types of devices.

In addition, when used with a hub, there are severe limitations in the number of "pipes" that are supported by the current STM32 F4 host driver. "Pipes" are the logical equivalent of endpoints on the host side. The hardware supports "channels" and the current drivers assigns one channel to each pipe.

The STM32 F4 supports 12 channels which is fine in most cases, but the needs one pipe and the typical USB devices needs three so that means that only 2-3 downstream devices can be supported.

Some of this might be alleviated with a design change: It might be possible to redesign the STM32 F4 OTGHS/OTGFS host driver so that channels are dynamically assigned to pipes as needed for individual transfers. Then you could have more "apparent" pipes and make better use of channels. Although there are only 12 channels, transfers are not active all of the time on all channels so it ought to be possible to have an unlimited number of "pipes but with no more than 12 active transfers.

If my product depended on world class USB host support, I would not recommend the STM32.

#51

Hub support exists in the 'experimental' Axoloti branch. I had it working with a keyboard and a BCR2000 fader box connected simultaneously. Doing a build with just hub support and ignoring the other stuff in that branch would be really straightfoward. I have a zoom implementation in that branch as well. There are various other goodies in there as well but it's been a while since I've taken a look at the code.

The bigger problem is that we have no reasonable release cycle right now. We probably need to just create a community fork and not rely on releases from the main repo. I'm happy to do this if people are interested but I'm short on spare time at the moment.

#52

That hub support would be most welcome...... And zoom too, especially if you can zoom out too, no only in :slight_smile:

Wish I could help with these things but they are a bit over my coding skills, atm.

#53

This is a very sensible suggestion.

#54

how would this help?

Johannes has been very willing to accept help and pull requests on the main repo,
so why not do any development there?

I hope your not suggesting that all that is needed is to just compile and release the experimental (or any other) branch - this code is not complete, nor fully tested, that is why its not released.
if it was suitable for general release, it would have been released...

the only reason I can see a fork, is if you have a different development direction in mind that is incompatible with Johanne's and wish to push forward with that development...but that requires development time, not just releasing a fork :wink:

note: ive no issues with community forks - I created one for the Eigenlabs/EigenD, because I needed to push development forward, but it was not a decision I took lightly, nor partly was happy to do initially.

#55

I clearly wasn't implying that things could just be directly released from those branches without any work. Working features would need to be extracted. There are certainly working features there for the taking.

We're in a situation where Johannes is basically the sole authority on what gets released and when it gets released. He's been largely absent for a while and hasn't really communicated his plans. And that's just fine; he's given us an amazing gift and doesn't have any obligation to do anything else for us. Forking is obviously a last resort; I'm not in favor of fragmentation if we can avoid it. In the past he's shown an unwillingness to maintain compatibility with community contributions if they don't agree with his exact vision, i.e. he's merged my stuff in and then proceeded to make incompatible changes in other areas. Again, there's nothing wrong with that style at all; it just makes me less inclined to spend time contributing or trying to ascertain what his vision is. I definitely disagree with his vision in certain areas and think that there are fundamental architectural problems that are holding the project back.

I think it's pretty obvious how forking would help: we (the community) would move development forward and release more rapidly without waiting for any approval from anyone. It doesn't really hurt anything. Those who wish to maintain allegiance to the vanilla distribution can do so and ignore any forks.

#56

To me, what really matters is to know that the Axoloti project is still alive whatever evolution is planned by @johannes.

Anyway, it would be great to have a yearly stable official release with all the nice features of the dev branch but i guess that it is not possible because of some nasty/tricky bugs and issues.

What i do really like with the current release is that it is reliable, more reliable than the clavia G2 modular last releases for example !

#57

Granted i am pretty new to axoloti but from what i experienced on this forum there is a lot of people frustrated/unsatisfied with said release cycle. Looking at that commit frequency graph i posted a while ago it looks like a lot of people potentially interested in developing for axoloti already gave up or are thinking about it. There's all these issues people been fighting with or wanting for a long time, the same questions keep coming up on the forum and there is evry little progress.

So yeah, axoloti as is is great and definetly pretty reliable, but i think if we want to keep it alive and not go the patchblocks route something needs to be done, rather sooner than later. Of course there's nothing i would wish for more than johannes being involved and on top of any developement, but i really really welcome and appreciate any efforts to try and better axoloti while the OG is busy with other things.

Ideally i would love to see the remaining veterans and motivated people to get together and discuss a road map and start working on it, and johannes could comment, chime in, take over at any time he feels like it. As you pointed out @SmashedTransistors this will be alot of work and of course there shouldn't be any hasty fork releases or other fragmentation. But i would be extremely excited if some if you professionals could get it started somehow and reignite some :fire:

#58

Yes @weasel79 , I agree with that.
@SmashedTransistors, It's true, hardware and software are reliable and it's really something that amazed me at the beginning.
But, over time, many people made small contributions. Johannes participated a lot at the beginning.
Then the community got bigger and more experienced contributors produced a lot patchs and objects.
As a result, I didn't see that commits decreasing and johannes's participation in the forum also.

I think, Axoloti have a bright future. Reliability, performance, usability and modularity are important features, thanks Johannes... and this is an open-source project ! If developers want to contribute, it would be unfortunate to discourage it, leaving contributions too long in dev trunk.

I think we all want one thing : this amazing project doesn't die.

#59

I think it would also help if there was some kind of roadmap easily visible. like, aside from what @johannes wrote in his first post of this thread, there are so many hints of great developement to be found throughout the forum. but without getting deep into github territories it's really hard to get a feeling for where the overall developement might go. which features are already around the corner, which ones are currently being worked on etc etc.

I feel like this might attract additional contributors to help or users to give feedback early on. At the very least it would give a lot of hope to people getting frustrated.

also i have to agree with this -


it would be awesome if somehow we could get the stuff that's already been added or fixed, additional SPi support, MAX11300 object, i don't even know what else is in there already. just grab the low hanging fruit and piggyback it on the current release until the big actual new commit comes.

I feel like there is a lot of great development and objects getting lost in the forums and expiremental branch, beacuse they are not easily available in the patcher yet.

just throw the dogs a bone. we need more bread and more games.

#60

Here's a weird feature request:

An ability to list blocks not by author, but by function, perhaps with a tag system. If an oscillator is an audio frequency oscillator that goes down to 1Hz, then list it under Oscillators and LFOs. If there's an attenuverter, list it under VCAs, Attenuators, Inverters, and Attenuverters. Of course, make clear the author of the patch, but when I'm trying to find a block, it's very rare that I'm looking by the author.

(Some of you are serious geniuses, though, and I actually do on occasion because someone is solving problems I'm trying to approach, but not usually. OK, it's usually @cpwitz becase I love the sound of ripping grains.)