Linux users: run platform_linux/add_udev_rules.sh to add permissions for the new Ksoloti USB device thing.
Mac users: Apple is coming up with ever new ways to ensure your safety out there. You may need to redo the steps described in Install - Ksoloti and/or also do the settings > privacy unlock thing. Additionally you may need to make Ksoloti.app executable using the chmod command in the terminal.
Let it re-flash the firmware and try out the new ksoloti/usbaudio objects that will have been downloaded automatically when you first started the v1.1.0 Patcher.
This package is non-destructive, meaning it will not mess with your existing 1.0.12 installation. However, once you save a patch in v1.1.0, you will obviously not be able to open it in 1.0.12 anymore (though there is a trick to restore it to 1.0.12 - let me know if you need help!)
Known issues:
The USBAudio firmware requires that a different USB PID be used, which the 1.0.12 Patcher will not be able to detect. Before you go back to 1.0.12, make sure to flash the default “Ksoloti” or “Axoloti” firmware on 1.1.0 first. Then 1.0.12 will be able to detect it and offer to flash its own compatible firmware.
A continous beep will remain in the usbaudio/in objects when the host deactivates audio (e.g. when you close yot DAW)
On Windows, go to the Device Manager and check if there is a yellow exclamation mark on the “Ksoloti Core” entry. If yes, right-click → “uninstall driver” then disconnect and reconnect Ksoloti. Windows will then fetch the correct driver or something.
OLED display or other special objects can be laggy. - Fix provided, testing.
You did read it right! Over here at Ksoloti Sound Business, we write Compatibility with a capital C.
With AndrewCapon’s USB kung-fu and my previous back-porting efforts, all firmware and Patcher updates should in theory work on Axoloti boards.
There is a Firmware Mode dropdown in 1.1.0 (what used to be “Axoloti Legacy Mode” in 1.0.12-8) where you, the proud owner of an original '14 Axoloti, can select one of the Axoloti firmware modes, including USBAudio, and enjoy the ride.
In fact USBaudio is still experimental and we need proud owners like you to go check if it works!
I believe that some issues about USB audio will come from the different drivers and whatnot, for example I couldn’t figure out how to set up ASIO4ALL on Windows to get low latency with Ksoloti. But that’s just me who hasn’t used USB audio in ages.
I haven’t tested it on Axoloti yet, might hook up my Axo later and give it a try.
Daaamn that is unbelievably AWESOME!!!
I’ll be testing it as soon as I can, thanks for the work guys! I’ll let you know how it goes, I understand this is still in beta and there will probably be some rough edges.
Thank you, you BEAUTIFUL people
No luck here so far with an Axoloti. Fairly new install of Debian 12 with Pipewire. Made a quick patch and I was expecting the Axoloti to appear somehow on qpwgraph either when connected or when pressing Live, but nothing happens.
I might be missing something, but I don’t know what.
Any ideas?
I am getting audio in and out of Axoloti Core on Ubuntu 22.04 with Pulseaudio. Have no realtime kernel thus not low-latency. But works the exact same as my Ksoloti Core as far as I can tell.
Ok as I said, the Debian installation was new and I had still not configured the pro audio profile. That is why I was not getting Axoloti Core to appear as an audio source and destination in qpwgraph.
Still not able to hear what the Axoloti is generating, but it is something I have to fight with pavucontrol on my system. The Axoloti seems to be sending the audio just fine :)))
I guess when using Axoloti Core you get different stuff. Check out this part of the screenshot, it shows it is using USB Audio. And I can confirm it is working
The current state is like a 2in, 2out Audio interface. Just like if you used a barebones Focusrite Scarlett 2i2, for example. But the difference is that the USB audio signals are objects in your patch, usbaudio/in and usbaudio/out. They behave just like audio/in and audio/out (but work independently from those).
So you can inject 2 channels of sound from your DAW (or other host) into Ksoloti, and/or 2 channels from Ksoloti (back) to your DAW (or other host).
Another example: During testing I connected my Gills running USBAudio firmware to my Windows 10 computer. I didn’t even have to do anything to set it up, and sound coming from Youtube in my browser was sent to my Ksoloti patch (available via the usbaudio/in stereo object). Hope this makes sense!
The other thing AndyCap (the author of this awesome firmware mod) mentioned is a plugin that can (ab)use the audio channels to transmit and receive lots of control data, kind of like digital CV.
Even if you don’t patch a lot, it is a USB audio interface, light and slim, with (arguable) noise rejection, MIDI, sound engine, EQ/effects, USB host port, SD card, and whatever else I forgot…
for 65 EUR plus case and jacks.
Big kudos to AndyCap for just showing up and doing the work!
In the new year I’m thinking of also upping it to 4 ins and 4 outs at 48K.
I have already tested it at 2x2 at 96K and that worked so it would be the same bandwidth so should be ok. Just needs a bit of work…
Also with the multiplexing/cv DAW plugin that is planned you can treat the signals as audio as well as cv. So if you are happy with say 12K audio you can have with the existing firmware 8 ins and 8 outs (via the plugin) to treat as CV or audio. If I get the 4x4 interface working that would be 16 ins and 16 outs at 12K.
I wanted to try the SPI link firmware in practice on my ksoloti today.
Somehow my launchpad objects didn’t work. the lpadpro/layout that sends out sysex for example didn’t have any effect, I only got a midi ring buffer overflow.
I switched back to the version I got before for now.
