Andrew is super protective over VCV.... EVEN the stuff he has no rights over. He once got mad a me cause I made a copy of the filter he made for vcv..... Which he didnt even write himself, he copied it from somewhere else..... That's just too much.
So I am not surprised that he opposes making a Pi release. Maybe he should not have made it open source then, if he wants that amount of control. It just doesn't go hand in hand with open source, imo.
My first post, but after discovering Axoloti last week while searching for something else, I’ve got two on the way...
STM makes much about software and hardware compatibility- I wonder if we’ll be seeing F7 Axoloti?
-Robert
A port to other STM devices or even other MCU platforms entirely is definitely possible. My feeling is that the DSP code itself would be reasonably portable to other ARM devices that support the CMSIS DSP library. Chibios, the realtime os Axoloti uses, supports many other devices, so in theory much of the Chibios code could be reused.
I think the basic approach of having the patcher generate firmware source which is then compiled could be improved upon. That approach is very tied to the particular hardware target we have right now. The patcher is very coupled to hardware and the toolchain for that hardware. In the future, I'd like to do something that is more like a proper API, i.e. future hardware targets expose a common API and various clients (one of which would be the visual patcher) could make calls to it. Supercollider's architecure is like this (https://en.wikipedia.org/wiki/SuperCollider#Architecture), there is a clear distinction between the low-level synthesis server and the high-level client language.
What you describe definitely requires a large effort.
Upgrading to the F7 chip might require very little effort, if STM claims of compatibility are true.
what if we get some crowdfunding going for @johannes, @urklang, @thetechnobear or whichever seasoned developer so he can allocate some more time to this project? Me personally and i'm sure quite a lot of the owners leaning more to the "user" side would happily spend some extra money for improved software, given how affordable everything is in the first place. Someone could come up with a guesstimate goal/money list?
obviously this won't come up with a proper developer salary for the thousands of hours probably needed for this but it might help a bit?
Hey @weasel79
I appreciate the sentiment. If there are specific small features that users want to crowdfund, I'm available to get those done, but have limited time for it overall. Some of my opinions about the future direction of the Axoloti codebase require bigger time commitments that I'm not prepared to make at the moment. The good news is that I've been busy with some other hardware/software projects that will definitely be of interest to Axoloti users. When that stuff is fully public, that will be a way to support me doing further development of projects like this and more open source work. I'll post more on the forums here to keep everyone updated as that progresses.
That sounds exciting. Granted i am kinda easy to get excited over anything related to my synth build these days haha.
Seriously though, i think inter-axo sync and communication should be a pretty high priority. It would make the platform exponentially more powerful, imagine, for 60EUR per stereo 24/48 pair people could build a modular audio interface. I saw a couple people asking for this. While i have no use for more parallel analog I/O myself, with the same sync i could build the flagship synth i want, with all the great OSC modules, best filters and effects, 16 voice poly, use the full 8mb SDRAM per single sampler OSC.... or just link 3 axos for the perfect hifi loopxbox with the best effects and the third one controlling your lightshow (while clearly possible that last part might still better be outsourced to a dedicated arduino or whatever. but yall get it).
So i have no real experience in developing (aside from the turbo pascal/assemler 3d engine i wrote 25 years ago lol), i can see this is a big task already and just my personal favourite. @urklang what do you expect how much time that would take if you think of it from a 9-5 5 days a week perspective? i know this is impossible to precisely estimate, so just a rough guess. i know it can take me up to a full day to find the missing +1 that was fucking up my code...
Are you asking specifically about inter-axo communication? Like how long that would take to implement? I need more to go on with respect to what you think that feature looks like. I haven't reviewed the status of that feature or any of the past discussions. There are a few different ways to achieve it I think. Are you thinking that there is some mechanism in the patcher that basically represents an "output" that targets some "input" running in a second patch but that that second patch is actually on some other Axo device? That's kind of the most general thing I can think of. That all of the usual data streams that exist in the patcher can be communicated across the channel and into a "remote" patch context. It would help me to understand if there are sub goals there that would be valuable to have alone. Like is being able to send audio back and forth alone worth doing as a starting point?
Then there is the question of exactly how the devices are connected. I'm not sure what people were discussing in the past. The second Axo could be a USB slave to the master for example. That seems like probably the most user friendly way to do it. Make it possible to just chain as many as you like together via USB.
i thought the consensus was (from prior discussions) that usb-audio is not going to be possible, since axoloti only has usb-1. the connection to use would be the spi port...
@lokki
That's interesting. SPI is definitely possible but would be irritating for a lot of users I think. Just glancing at the data sheet again for the MCU, the hardware supports USB 2.0 both full and high speed (one interface is full speed only which should still be able to handle basic stereo usb audio). Axo implements both a usb device and a usb host. Maybe people were referring to some limitation coming from the current firmware. Or perhaps it's forced to run more slowly when both interfaces are in use, etc.
Also, what do we mean by usb audio exactly? One meaning to me is something like Axo being able to act like a standard usb audio interface when plugged into a host pc. Another meaning is exchanging audio data over usb between host and slave Axos (either in a linear chain or connected via a hub to the master)
I'll need to do a deeper dive into the usb stack again to figure out where the limitations might be for audio. I'm skeptical that it's outright impossible for a hardware reason.