Poll: Feature Requests/Wishes for Axoloti

#1

Hey so after Johannes recent announcement i thought it might make sense to get a feeling for what most of the axoloti users really and most urgently want, as obviously everybody is having their own vision. So here we go, pick the 3 most important to you.

  • GUI/Patcher improvements (stability & convenience)
  • Realtime re-compiling/re-patching (get rid of the LIVE button solution)
  • Better audio hardware
  • Make Axoloti portable to other hardware ie. bigger ARM cortex MCUs, more RAM
  • Architecture overhaul
  • Digital audio & clock (USB-Audio, I2S, syncing, slave modes)
  • Better/more fully developed patches
  • Better/more fully developed objects

0voters

Choose up to 3 options

Vote now!Show results

I am aware these are very vague and sometimes overlap, and i am sure there's a lot features people wish for that i didn't include. So feel free to post and discuss those below and if needed we'll do another poll.

Also it might help if @johannes could chime in with his long term goals for axoloti, because most of us, especially active people on the forum, lean heavily to a more tech-savvy diy/developer side while i recently realised maybe a more consumer friendly version of axoloti is really the endgoal? Referencing the Nord g2 again...

#2

13 voters so far, i am sure nobody minds if i bump this up every couple days for visibility.

#3

Honestly there is nothing in here that I currently need, so I'm not going to vote for any of these options.

Things that would be greatly appreciated on my side:

  • USB-hub support
  • Sysex support

Also options like "better audio hardware" and "architecture overhaul" are way too vague, what do you even mean by them?

#4

Missing from the list but my #1 desire. Better documentation, user manuals, tutorials so its easier to learn how to create patches.

#5

of course they are vague, this is just meant to get a general overview and give people like you an opportunity for feedback on the poll/polling options. there were a couple people in the forums complaining about the output of the converters not having enough level, people asking for 96khz converters, or simply more I/O. i though anybody with a little imagination who wants anything like that would have found themselves in the "better audio hardware" category :slight_smile:

anyways, thanks to both of you for the input, as stated in the first post if needed we can add all these options in another poll. also i am sure @johannes will notice any comments in this thread at some point and thereby hear your wishes.

#6

Sure all those sounds nice ...
but I'm more into having Axoloti being usable as an instrument.

I was astonished that sucha project was made by mostly one person guessing the level of complexity of the whole thing, it's nuts !

And that in the end, it lacks of very very basic features that are essential to making music:

-The absence of a preset system (load,save,name) makes it almost impossible to compose with it (unless you just sample). You can't reliably save a preset unless you edit each parameter in the patcher which I did once or twice but it's not worth it.

-A patch/preset browser UI to navigate on a screen is direly needed to load patches, load/save presets

Using it is impractical and time consuming because of those two points.

Looking at the forum in itself we can see that the Patch/Preset management and UI problem occupy a lot of us all, sometimes more that making music with it

That's why it ended up on my shelf taking dust even though it's so promising and frustrating at the same time.

#7

Thanks, i never tried it myself yet but i was under the impression that @DrJustice's preset manager works pretty flawless by now? Granted i think it does not save preset names but that would be kind of easy to add with an extra table written on SD. Personally i am doing preset management externally on my midi controller, and have every axo parameter i need midi-controlled w nrpns.

But yeah i agree, a more convenient stock implementation would be very helpful, especially for consumer-oriented users.

#8

DrJustice has made a preset system, but it doesn't hand polyphonic patches or subpatches.
IMHO managing patches AND presets shouldn't take the form of an objet in a patch the axoloti at a ROOT level should manage that. Let's imagine being able to load a preset from another patch directly without having to load the patch first and then the preset, or even using program change program/subprogram messages, that would make it really great , fast, effective and usable.

Otherwise it's going to remain tedious to use it if you're not a developper.

I'm a developper and I know a bit about C & C++ but I don't want to spend days, weeks to have a reliable preset system, I prefer resuming doing music and use another machine (or buy another one if necessary) to do the job. I can imagine consumer users frustration with it

It's great that people can write their own objects, but I think that this should be handled at the root level of the axoloti because it would help everyone to keep the axoloti organised and usable.

I have a 64Gb card and it could be filled with hundreds of patchs/presets but it's not
And I guessing that most of don't either, that's a pity this thing is so close to being a Nord Modular G3!

(I'm gonna have a look at your NRPNs object that could solve one of my problem)

#9

I quite agree with suburb, the lack of a load /save preset (or snapshot) system is why (for me) Axoloti has never left the stompbox/noise toy territory and has never become the synth/sampler thing I would want to use live.

... while i also respect and support the decision to keep Axo as open and customizable as possible and let people contribute objects that take care of those desired 'higher level' features.

But the fact that I've been searching the forum for how to implement load and save preset functions, but only hear of DrJustice's preset system here and now, sort of makes a point.

#10

The "digital audio and clock", does that mean syncing 2 boards and stream audio and controller from one to the other, like they were one board?

#11

@Suburb_Animal
I feel your pain man. What follows is just my honest opinion about how to move the project forward; I have nothing but respect for Johannes and his work.

Most of what you're talking about feels like "usability" stuff to me. There is way too much complexity exposed to the end user right now. Object/patch/firmware versioning is not intuitive. The average user should not be forced to deal with git directly or even version numbers in the ideal case. The normal use cases should "just work" in an obvious way. The harder power user use cases should be possible but not exposed unless the user wishes.

There is definitely some low-hanging fruit in this area. But really there are fundamental architectural problems. The patcher is too tightly coupled to the hardware. We need to create a clean API at the firmware level. Decoupling the firmware and patcher as much as possible will make rapid iteration on high-level usability issues much easier. That stuff is harder than it needs to be right now because the patcher is so fundamentally responsible for making the entire thing work. A first milestone would be a version that can be driven entirely programatically, i.e. purely from code without the need for the patcher at all. The code generator needs to be completely extracted from the patcher. Additionally, loading a patch should not always require a compilation cycle (unless new custom object code is being added). The object library should be compiled ahead of time as much as possible.

#12

would love to have more MIDI DIN ports, or at least to choose whether certain DIN socket works as MIDI In or MIDI Out.

#13

@jaffasplaffa well my ideal idea of this was to get a stereo i2s connection going, either between axoloti as master and other i2s slaves (think more audio in.outs) or digital streaming between axolotis. ideally bidirectional but not sure if the STM32F7 supports i2s slave mode.

alternatively i thought some way of serially syncing the audio clocks of two axolotis would be a start to get sample accurate sync.

#14

@chaocrator i also need more DIN in my system, but i just added a midibox system. also you could send midi over additional serial lines to a very small and basic arduino setup with a DIN shield. but yeah i agree, a simpler solution would be nice, ie. more accesible serial lines on the axo board and simple breakout/shield boards with additional connectors. going towards the hardware modularity concept @axoman once proposed.

#15

i'm already using additional serial lines for MIDI exchange between two Axolotis.

#16

In the patcher: It would be great to get the possibility to use Patch as SubPatch.
So we will need an object 'Auto-Out' that become Outlet if patch is used as SubPatch or become Out if patch is used as mainPatch. (idem for In/Inlets).

#17

The only thing that concerns me about using other hardware, is I don't want to take away from the great work that has already been done, but if there was a way for me to have more audio inputs and outputs controlled by the Axo software, I really need to explore it, as it is fundamental with some of my goals, any other option I have been able to come up with well outside my experience, so will likely to take me a couple of years to do.