You put it in an interesting perspective and I’ll give it some reconsideration.
Also, I’d like to write, because I haven’t yet - if anyone is finding this topic, whether from the forum or the internet, and this feature important to you, please open an account here and vote on this topic and add a comment. This can help in pushing this feature to being developed.
I’ve switched to Linux-only way back in '95 (yes, 31 years ago). I’ve done live radioshows, recorded and edited myself and and some international acts using only Linux software with great results. I can even control my X32 mixer from Linux (X32-edit) and couple it to my Linux DAW.
And it would really like it if Cortex Control were ported to Linux. I’d offer to help but as an embedded Linux software designer, I can tell you that GUI application design is not my forte.
Actually, I think it would be great if maybe Cortex Control was a web app using the WebUSB API. Then it could support just about any OS through most browsers. I think someone is working on a Nano Cortex web editor which shows this could work. There’s a lot of mouse and keyboard config apps that are now moving to web app for this reason. Maybe then I could even run it on an iPad!
I’ve been using Morningstar’s web apps quite a lot lately. Works great.
After a lot of reconsideration (specifically of humpparitari’s suggestion) and a lot of planning, I reinstalled Windows on my PC on my smaller drives (for some extremely specific uses), and installed Fedora COSMIC on my main drives.
After setting up all of the basic things (and learning how Pipewire works) - it was time to try and get Cortex Control working.
I initially started with Winboat, it didn’t work for two reasons - the first is that application windows would open as unresponsive, empty windows (though the desktop RDP would work fine), and the USB passthrough experimental featrure didn’t work at all, so Cortex Control couldn’t find the Quad Cortex.
I then moved on to trying a regular Tiny10 VM on VirtualBox, and once I passed the Quad Cortex as a USB device, it worked:
It takes 2 CPU cores and 4GB of RAM, as well as 50GB of storage from my computer, waaay to much for such a simple program, I also didn’t like the finicking and the fact that I have to open a VM in order to open Cortex Control, though Tiny10 does boot pretty quickly, and it’s also quite responsive (though not as responsive as it would work natively).
So I don’t like it at all, but it is tolerable, I’ll give it some time to see if I can live with this.
But NDSP, I beg of you, don’t let us keep working like this, this process wasn’t simple.
For Linux users, the class-compliant USB path is a good baseline, but the practical gap is control rather than audio. A native control app would be most useful if it exposed preset browsing, routing, and firmware updates while leaving the audio device to ALSA/PipeWire. Even a documented protocol or a small cross-platform command-line tool would let the community prototype integrations without depending on a VM; meanwhile, collecting `lsusb`, kernel messages, and PipeWire node details when reporting issues should make the remaining edge cases easier to separate.
I hope you guys are upvoting because I see reply’s but the counter remaines the same!
A small practical addition for Linux users: keeping the USB audio path separate from control traffic makes troubleshooting much easier, especially when PipeWire is involved. I also keep a simple frequency reference handy when checking test tones: [frequency reference](KYMA369 | Professional Frequency Healing Systems).
