Related to this, I see a lot of JUCE based projects that seem nice in principle but if the author has not updated between versions (say using older JUCE6) it becomes difficult to package and argue in their favour.
JUCE breaks their API quite a lot, even between minor versions. So projects that rely on older versions don't have e.g. fixes for high-dpi screen support or linux vst3.
Updating them to new JUCE versions can be quite complex sometimes.
Not good prospective for long-tern support...
Checking on the status of opensource audio apps and plugins (previously known to me) is quite the sad sight, quite a lot of them have been abandoned 😔
I am thinking of tagging anything that:
1. has no stable release in 10 years
AND
2. has no single dev commit/change in 5 years
as "abandoned".
Alternatively if the project owner publicly states it is no longer maintained.
The amount of projects that fit into this criteria is not small. And I feel 10 & 5 year thing is quite generous..
@hellocatfood no worries I will tell you.
For now it is only the ones that just can't run at all, the stuff from Nils that has abandoned them :(
See the note in https://hilbricht.net/projects/
KXStudio June 2025 project update
https://kx.studio/News/?action=view&url=kxstudio-project-update-june-2025
Very short this time, writing these always takes me way too long, so I will try to go with this more formal format for the moment and see how it goes...
Your favorite audio mastering plugin has a new release! 🎉
Mostly just keeping things updated with DPF (the plugin framework) but it now also allows to persistently save custom theme changes. Hint: click the master_me logo on the top-right to bring up the "theme editor".
https://github.com/trummerschlunk/master_me/releases/tag/1.3.0
@prokoudine not really in a new header but all just self-contained.
the asio sdk is C++ and wineasio is C, so the "conversion" already took care of not using most of the sdk. I didnt do any of that to be clear.
what I did now is remove any extra enum or custom values from the asio header (it only needed 1 header). then add only the structs that are actually needed, making sure to rename all members as to not share any API. so it becomes binary compatible, but uses none of the official API.
My big commit of the day: https://github.com/wineasio/wineasio/commit/8d0d748efd4db6fed0e97b59db0bb21210fca367
Remove ASIO dependency from WineASIO 😱
It was only a few definitions, and since the core codebase was unchanged for so long we can safely replace a few structs with API-incompatible but ABI-compatible variants.
Seems to work just as before
@tenacity @gperson Only after tenacity is well established.
Lead by example, show how it can be done with Tenacity first and others will follow for replicating the same with musescore.
I would love to help but I am already involved in far too many projects. I am willing to put it up on the KXStudio repos at least
@tenacity FYI I have a non-github-public-fork in https://github.com/falkTX/librescore-downloader just for posterity, in case the original goes offline
My biggest kernel patch so far: https://github.com/Darkglass-Electronics/radxa-kernel/commit/cc8f13b0504c290e3cb83a7334e9f1d4e3809c4e
Changing the Linux USB audio gadget to use a very-fast mmap vs the old virtual ALSA card approach, plus also sharing 1 clock for both playback and capture (default implementation uses 1 for playback and 1 for capture, which makes them appear as separate devices - very ugly)
Culmination of 1 month of work, but due to how hacky it is I will have to maintain it forever.
But it's cool, gives the Darkglass Anagram unit a more unique feel!
@falktx here you go. It is a simple random note generator used within bitwig.
I can use the touch screen to move modules but not to tweak module controls ... It's either the screen that is too small or my fingers that are too big 😆
It's not ideal but it works !
@CPasCroyab you're welcome!
any photos of it running you can share?
also, do you attempt at all to use touch-screen? I am guessing it works quite terrible and needs the mouse pad thing.
Cardinal 25.06 is out!
Just a few module updates, the main change being SVModular DrumKit being replaced by a community fork, as requested by its author.
@prokoudine hey seems much better compared to what I am used to on the 2.x series! like its almost there...
@ercanbrack huh no, its a requirement.
if an update from regular distro overrides the packages from kxstudio, they will be different in style, optimizations and features.
just as an example: debian has had some issues with vst3 support in some packages, preferring to leave it off from their builds.
(see https://packages.debian.org/stable/sound/dpf-plugins)
what if an update from debian/ubuntu repos makes the user lose vst3 format of a package?
the current versioning is intentional and will stay as it is.
Finally getting back to do some KXStudio repository updates.
First order of business, cleaning and updating the basic libraries
https://launchpad.net/~kxstudio-debian/+archive/ubuntu/libs/+builds?build_state=all
The LV2 stuff changed from waf to meson, the deps are very sequential so it takes a while to confirm successful builds. The stack is basically:
zix -> serd -> sord -> sratom -> lilv
Updating PawPaw project (for easy win/mac/wasm static builds) along the way to match
https://github.com/DISTRHO/PawPaw/commits/main/
That pretty much takes away my Sunday 😅
@prokoudine @MightyHealthy673 oh and yeah no custom drivers are needed whatsoever, the USB support is class compliant as it comes from a Linux OS, it uses 4 components:
- HID (communication with Suite app)
- Serial / CDC ACM (for big payloads, like updates and user files; HID is too slow)
- MIDI
- Audio (coming in v1.2 update very soon)
This is all Linux stuff based on https://www.kernel.org/doc/html/v6.1/usb/gadget-testing.html