Hey, I just saw this post about this new initiative and I think it's awesome. It fills me with hope for Axoloti. I can't wait to get myself one of these new boards. I think an additional aux in is very useful and the option to switch to balanced mode can be very useful for using them live on stage. I don't know if it would also have optional balanced out, but that could also be useful: I always have to use too many DIboxes with Axoloti, though it is more an inconvenience than a real problem.
I wanted to make kind of a request: what excites me the most about an optional hardware balanced input is the possibility of adding a microphone. The thing is, it doesn't sound good enough with the onboard gain. I have to add a preamp and that's too much trouble. I've ended up just using a laptop with an audio interface. I made the famous $5 preamp and it sounds awesome with batteries, but it needs a noiseless bipolar power source, which is too complicated for me to make from the dc source of the Axoloti. I bet you know how to do that kind of thing. I'd gladly pay some extra if the board had a microphone preamp in one input, or I'd buy a hat for it, surely.
Having a mic preamp option in the Axoloti would make it a lot more interesting to do sample-based stuff, it would give it a lot more use for a different kind of people. Also, and I know that is not that hard to DIY, but it still would be very useful for the same reason to have an impedance switch in an input, so that people could connect their guitars better. I thought I would float you those ideas, for whatever use they might have.
I'm also very happy that you are aware of the SD Card issues. That is the only hardware problem that I can think of. I think you're right on the money about using some already made code and adapting it. First, I believe an M7 core is a lot better with floats and doubles, so adapting code might be of less urgency on it. Second, gee, I keep seeing a lot of stuff that is not done or committed because it could be better, but then it's never done. In the case of objects, if an object is added to the base repository, and it doesn't have the best performance, I still would rather have it, it still might be enough to solve an issue, and maybe I or someone else can look at it's code and fix it, then make a pull request.
So I wanted to say, if this new board comes with an initiative to rejuvenate the software, maybe it would benefit from having a development protocol that took more advantage of the community. I mean, I haven't been very integrated here, but I'm pretty sure that this is one of the most geeky communities I've ever seen. There's lots of very smart people. Yet the development environment seems designed so that every one works on his/her own solutions while leaving the base program alone. I've solved myself some very simple but bothersome issues that I would rather have done as a pull request; I've uploaded some of my workarounds to the community library, but it's not the same because they are not extra features, they are weird solutions. So, in case there's new software, I'd like to advise, from a very humble place, this things:
It'd be nice if there was a public road map with some detail. That way people could actually know what work needs to be done and offer themselves to do some of it, all the while knowing that their work won't conflict with something else. Making a public road map also let's programmers listen to the priorities of people, which doesn't mean everything is suddenly a direct democracy, but it can help realize that, for example, no one really cares about something that is very hard to do.
It'd be nice if there was some kind of board with tasks to be done that no one is doing. Like Trello or something like that, I've seen that helps a lot with small boring tasks, because someone probably needs to do them; that little bug that everyone keeps leaving for later is bothering some one too much and when he/she sees that no one is working on it right now, he/she will take care of it.
It'd be nice if we had a shorter release cycle. I understand that right now the software might need a very large revamp, because it's been still for a very long time. My point is that right now though, there are some issues that have been solved but then were made incompatible (like your zoom for the editor), there are some issues that have been solved but are waiting for a release to see the light (like support for usb-hubs), and there are are lots of small issues that are easy to solve, but it's pointless to do a PR, because a new release will change everything and there won't be minor releases in-between. I think a shorter release cycle both means that solutions that will be obsolete in a year can still be useful, and that we try to separate big tasks into smaller ones. That way, there's less stepping on toes, and if something doesn't work, it is revealed before wasting too much time, and everyone feels more inclined to contribute.
I realize that luck, chance and life have a lot to do with this, but still, it'd be nice if when the maintainer of the software feels like she/he needs a rest, the software development of the project is structured enough and immersed enough in the community, that the path without her/him is clear, and maybe another maintainer has been left in his place.
Cause, gee, for every little problem i could have had with the hardware, I've had many more with the software. I think this community keeps being alive because of the community library and I wonder where it'd be if some of the energy put into it could have been put onto the patcher and the runtime.
