Home KXStudio > News

KXStudio : News

> KXStudio Monthly Report (July 2021)
On 2021-07-31 by falkTX

Hello all, another monthly report about the KXStudio project is here.
First, in case you missed it, Carla v2.3.1 and JACK2 v1.9.19 have been released.
A few issues were reported against this latest Carla release (regressions) so expect a v2.3.2 very soon.
Due to travis-ci.org shutting down (and the replacement travis-ci.com being absolutely terrible) the binaries for these releases were not automated.
Which brings me to this month's first topic.

Automated builds & artifacts

Since travis became unusable, and manually doing builds everytime is a bit of a pain, I began looking for alternatives.
GitHub Actions seems to be what most developers have run to, but I am not really happy putting yet more stuff into GitHub.
While there are some alternatives, even self-hosting, in the end being pragmatic I threw the towel and just let GitHub handle it.
For projects that already have a presence on GitHub, the integration just makes sense.

One of the issues with travis was the lack of daily/latest build binaries.
While it was possible to setup, it usually required creating a tag or release to upload the binaries into.
GitHub Actions can have "artifacts" associated with any build, with no special setup required from contributors.
This was the main thing that pushed me to just stick with GitHub for this.
If someone external to a project submits a pull-request, there will be automated builds with the proposed changes ready for testing.
The fact that builds start immediately (instead of sometimes having to wait several hours like in other services) is super nice to see.

But are there any benefits to users, you may ask.
Well, take for the example JACK, for which I already added automated builds.
If you open the JACK2 GitHub Actions page, there will be macOS and Windows installers for each build going forwards.
When there comes a time where a change requires testing, there is no longer a need to build things manually.

Automated builds via GitHub Actions (and the resulting artifacts) also fit nicely for DPF.
I was able to create a "workflow" file (that is, a file that describes what to build and how) for DPF-based plugins, where it builds and publishes linux-armhf, linux-arm64, linux-x64, macOS (universal), win32 and win64 binaries, all in a single file.
So you can basically take this file, place it in your own repository, and directly have all those linux, macOS and windows builds right away.
I already have this setup for pretty all of DPF-based plugins under the DISTRHO GitHub organization.
As an experiment, I added the same support to dragonfly-reverb project.
So now if you go to its GitHub Actions page and click on the latest commit, you will be able to download and install/use the build artifacts.

This is extremely valuable, as not everyone has a macOS or Windows machine in order to do builds for those.
Or maybe the other way around, someone on macOS or Windows without a Linux machine, etc etc.
I also think of the situation of people wanting to try out a change in the code but don't have the developer tools needed to build the project themselves.
While maybe not a big issue for DPF/Plugin projects (as they tend to be small in size), for things like Carla where build dependencies are a lot more involved, almost no one will have everything needed to make binaries alike the official ones.
With these automated builds, you can basically create a pull request and just enjoy the build - which will follow the same exact conventions as official builds.

Now, this is not in place for Carla just yet, but it is in progress.
Currently DPF (plus the plugins made with them under DISTRHO) and JACK2 have automated builds via GitHub Actions.
More will follow soon.


There are no updates regarding packages in the KXStudio repositories at this time.
Even though some packaged plugins are out-of-date, yes..

Thinking of packages, I might just do a whole month focused on them soon.
There has been quite some nice releases of open-source audio plugins lately that would be great to have packaged, but lack of proper time for them is a problem.
As the last details on DPF new release are being resolved, packaging might be the next thing to focus on.

Special attention is needed on JUCE things though, because the LV2 wrapper is still somewhat of a pain for external developers to integrate properly.
(If only JUCE devs made the LV2 wrapper official! errr...)

Anyway, this packaging thing is not so much of news but more of wishes.
Before new JUCE-based plugins get packaged, I want to sort out the LV2 wrapper mess, make it as easy as possible for developers to have official LV2 variants.
Only me building LV2 versions (for the KXStudio repositories) is not something I want to push for anymore, rather it would be best for everyone to have said LV2 versions.


That is all for now.
If you appreciate the kind of work I do, please consider a donation.
Thank you in advance for your support, and stay safe out there!

> Carla 2.3.1 has been released
On 2021-07-16 by falkTX

This is a bugfix for Carla version v2.3 series, fixing many bug reports and stuff I found along the way.

Carla is an audio plugin host, with support for many audio drivers and plugin formats.
It has some nice features like automation of parameters via MIDI CC (and send output back as MIDI too) and full OSC control.


  • Add NSLocalNetworkUsageDescription and NSMicrophoneUsageDescription in macOS builds
  • Allow canvas eyecandy for Qt >= 5.12
  • Alternative approach to deal with JACK postponed events (improves PipeWire usage)
  • Implement parameter groups for VST2 plugins
  • Ignore hosts calling Carla-VST effOpen twice (don't print errors)
  • Listen to Windows and X11 plugin UI resize events (without extensions)
  • Make some macOS dialogs modal
  • Remove favorite plugins from list when they fail to load
  • Update JUCE plugin code to new APIs, hook into VST2 for feature parity with native implementation
  • Use new tick_double for JACK transport
  • Use posix_spawn to launch macOS bridges
  • Fix available decimal points on a few dialogs being incorrect
  • Fix bridged plugin UIs appearing behind main carla window on macOS
  • Fix canvas auto-refreshing on exit, potentially leading to crash
  • Fix canvas split/join action
  • Fix carla-vst-wine symbol visibility
  • Fix default rack "skin" for a few plugins
  • Fix initial size for LV2 UIs with no UI resize extension (all OSes)
  • Fix loading state of Windows/macOS VST2 plugins without chunk
  • Fix macOS binaries not being debug/symbol stripped
  • Fix midi-pattern plugin having double notes on transport reposition
  • Fix race condition (and potential crash) around postponed RT events
  • Fix Qt >= 5.10 version checks
  • Fix unused JACK latency callbacks (removed)
  • Fix X11 UIs not having keyboard focus


To download Carla binaries or source code, jump on over to the KXStudio downloads section.
If you're using the KXStudio repositories, you can simply install "carla".
Bug reports and feature requests are welcome! Jump on over to the Carla's Github project page for those.

Notes for users

This was already the case for v2.2 and v2.3 but it is worth reiterating:
When using JACK2, the canvas - plugin integrations requires at least JACK2 v1.9.13.
This is because Carla relies on JACK meta-data in order to store information about each plugin/client, and meta-data was only added to JACK2 in version 1.9.13.
Alternatively, you can use JACK1 instead of JACK2, which has meta-data support since a long time.
Note that the "extras" KXStudio repository (which provides an updated JACK2) supports both Ubuntu 18.04 and 20.04.
The UbuntuStudio backports PPA also provides updated JACK2 packages.

There are no official Linux binary builds for v2.3.1 at this point.
Carla v2.3.1 is provided in the KXStudio repositories and in many official Linux distribution repositories too anyway.

> Changes in the extra KXStudio repositories regarding JACK2
On 2021-07-05 by falkTX

This is a small notice to everyone using JACK2 with the extra KXStudio repositories. (those for Ubuntu 18.04 and 20.04)

A change in the JACK2 code has made it so a restart of the server is required after the update.
The technical reason for this is an internal ABI change due to forced-alignment in a few struct/classes.
This change is required for some ARM platforms where non-aligned access results in a bus error.

If you use jackdbus (likely with KXStudio stuff), you will need to actually kill it. (or use the usual cadence-session-start -s command)
If that does not work, good old restart is your friend. :)

This small update brings JACK2 v1.9.19 early, as a way to get a little more testing before official release.
That said release is planned for July 15.

> KXStudio Monthly Report (June 2021) and a Little Personal Note
On 2021-07-02 by falkTX

Hello all, another monthly report about the KXStudio project is here.
A bit late this time, but let's ignore that. :)

DPF updates

DPF got most of the attention again.
Things are progressing, not as fast as I hoped, but there is progress. (I really underestimated the amount of time DPF would take)
The main reason for the DPF attention and rework - updating its pugl graphics backend to latest upstream with no patches - is complete.
Only 1 small change is still custom, related to using sofd as a fallback file browser dialog on Linux.
After some discussion with the author, I realized such a change/patch doesn't belong in pugl. I will change this part of DPF at a later time.
There are some small additions made on DPF-side of the code for pugl, but nothing that requires changing pugl itself.

New stuff was added in DPF of course, first we have a complete port groups implementation, based on an initial PR from Jean Pierre Cimalando.
It is supported on LV2, VST2 and JACK targets, wherever is possible on those anyway.
For LV2, port groups are set in the meta-data for both audio/CV ports and parameters.
For VST2, parameter groups are supported (named categories in VST world)
For JACK, lv2-like meta-data is set on the audio and CV ports.

Next, the JACK target can now always be built, by including jackbridge code from Carla (adapted to make fit DPF better, also liberally licensed).
This makes it so that:

  1. JACK headers and libraries are not needed at build-time
  2. Compiled binaries to not link to libjack
  3. libjack is loaded dynamically at runtime, printing an error if not found

As a 2nd step on top of this, RtAudio is used as fallback in case JACK is not available or connecting to the JACK server fails (usually because it is simply not running)
This has been requested a few times, and it is finally here.
DPF will setup RtAudio so it opens the default audio input and output as needed. MIDI is not supported yet.
In any case, such fallback makes testing of DPF plugins much easier, specially on systems that do not have JACK.

Moving on, I started some classes that simply do event handling, split off from the ImageButton and ImageKnob into something generic.
The idea here is to make it easier for developers to get a working widget from scratch.
Maybe this will help DPF based plugins to be more consistent on their behaviour too.
Note that this work is not yet finalized, so these classes are not yet documented.
I am using them on a new set of plugins, coding on a as-needed basis, so this will keep evolving over time.

More stuff was added too, though not as substantial, including (in no particular order):

  • Allow UI_TYPE = generic, so UI can be opengl or cairo, whichever is available
  • Initial work for VST3 compatible plugins, lots to do.. (nothing to see just yet)
  • Implemented Window::openFileBrowser() fallback for state files, so you always get a file browser

DPF is now at a point where I want to focus on stability and testing.
Out of all feature requests, only SVG support is deemed important and "breakage-worthy" (if that makes sense).
Once SVG support is in, there will be a feature freeze and then getting everything to work at least as good as before.

One-Knob Series

As a way to stress-test the new DPF and also start having some usable DPF-Widgets I began a new project called One-Knob Series that is going to be slowly brewing for the upcoming months.
I am not taking a rush on this one, its initial purpose is to test DPF but it so happens that it is also a nice, fun and useful project.
The idea here is to make a collection of stupidly simple but well-polished and visually pleasing audio plugins, with as little controls as possible, often just one knob and a few options.
Eventually they will be not just as a test for DPF, but also as a show-case of what it can do, plus give an example of good practices within DPF.


The guidelines for the collection are:

  • Must have one main control/knob (linear or logarithmic), with one auxiliary slider/knob allowed but discouraged
  • Can have maximum 3 auxiliary options (list of values or toggles)
  • Parameter changes must be click-free
  • GUI must be cleanly scalable (no bitmaps allowed or blurred resources when scaled)
  • GUI must follow the same style

I have a few ideas for useful one-knob style of plugins, to slowly be put into action throughout the year.
Before you ask, you can already build and use them yes.
I don't recommend doing so right now though.


A new Carla release is coming very soon, for the quarterly release pact once again.
It is going to be a bugfix release, I will write more details about it in 13 days for the 15th of July.
JACK2 will very likely see a new version too, pretty minimal but keeping with the spirit of doing regular releases.

Now, into some personal notes...
I am a little frustrated, perhaps disappointed, that pushing for donations doesn't work.
The number of subcriptions has been going down, not up.
While I want to keep doing these kinda of things, being realistic, it is really not sustainable.
All the free time is basically spent on this, but it does not pay off.
Perhaps that should have been expected..
It seems that (in my opinion), in order to make it really pay off, a whole lot more effort would be needed.
Not just with coding, but more regular interaction with community, basically a whole lot of reporting and being present.
The projects that really succeed in such funding pretty much always have someone very "present" and visible within their community.
It is tough, and maybe was just not feasible at all. We know audio development, specially on Linux or open-source, is very very niche.

So it is clear that keeping this up as-is is not possible, a lot of my life stuff was ignored or put on hold (it was lockdown anyway, so not much of a problem).
For the sake of sanity and balance, going forward for the next 6 months (so the rest of the year), plan is now:

  • no more new-feature developments, bugfixes only (the svg and vst3 support in dpf being the exception, I feel like they are essential)
  • will restrict time spent working on floss stuff to whatever is left from main job, no more weekends, max 40h/week
  • when bugfixes get boring, will do packaging, website updates or writting user manuals

And that's all for now.
Obviously I will still keep working on these things, don't worry.
Specially Carla and DPF have my main attention, but will be on a more reasonable pace from now on.
As always, if you appreciate the kind of work I do, please consider a donation.
Thank you in advance for your support, and stay safe out there! See you soon!

> KXStudio Monthly Report (May 2021)
On 2021-05-31 by falkTX

Hello all, another monthly report about the KXStudio project is here.
I skipped last month as there was not much to report.
Mainly there were new releases, but those had their own announcement (specifically, Carla v2.3 and JACK2 v1.9.18).
Afterwards there was a small personal situation (that is still unfolding) that took all my free time, so that was it.
There are a few updates related to the month of May though!

DPF updates

The main thing to report today is all the work that I've been putting in DPF recently.
This has been a long-time coming, but better late than never.
For those unaware, DPF is a very small C++ framework to create audio plugins with.
It has UI support, but it is intentionally not a fully-fledged UI toolkit, same for its DSP side.
It can export as LV2, VST2 and other plugin formats, but it does not try to do much more than that.
Native OS events is handled behind the scenes via pugl.

One major task to do was updating to latest pugl, because it supports many more things compared to old versions.
pugl had its event system completely reworked though, so we can't just update and use it as-is.
In the end, this update work is something that took several weeks.
I took the chance to rework some core components of DPF UI handling together with this, as there were a few parts of the code that proved confusing to other developers.
Also added in testing units and demo applications to help test several parts of DPF, though this is still very much work-in-progress.
This was specially useful to ensure core parts were working before proceeding with the rework.
Related to pugl update and rework, the Cairo backend of DPF is now pretty much on-par with its OpenGL one.
The Demo tool (where we test images, events, resizing, etc) has consistent behaviour between the two.


Continuing with the rework, special attention was given to resizing.
Resizing in LV2 UIs has always been something very painful, which still does not work correctly in many hosts.
One culprit of this was the bad initial decision to use an LV2 extension to deal with UI resizing.
Turns out, we do not need this at all!
So the next version of DPF will no longer make use of LV2 UI resize extensions.
We will need to accommodate hosts to this, which is a breaking change.
But it is not like LV2 plugin-side resizing was working well in the first place anyway.
I already did this for Carla. Likely will do similar things to suil if no one else does.

On even more DPF news, I created a new open-source code repository meant for reusable DPF UI widgets.
It has come to my attention that developers struggle with DPF having very little common widgets they are used to.
I have made a few ones based on images for the DPF-Plugins collection, but some developers struggle to create individual widgets from scratch.
This code repository will evolve over time, obviously as a new project which is only a few days old there is not much to see.
One common request has been a resize handle, so that for plugin formats like VST2 which do not allow user-side resizing we still have a way for the user to resize the UI.
There is one generic resize handle in the repository now, usable for both Cairo and OpenGL backends.
The first real widgets I am contributing to the repository are a port of oui-blendish which provides blender-style looking widgets.
I am still setting up the whole thing, but initial impressions are very good. It even works with High-DPI / custom scale factors!
(ignore the bitmap icons on the screenshot below, those are only used in testing, I will later either replace them or remove them)


Finally on DPF side, as contributions by Jean Pierre Cimalando, CMake is now supported for building DPF and using it in plugins targeting DPF.
As a second step on top of CMake, it is now possible to build DPF with MSVC on Windows.
I tried this myself and was able to build a DPF VST2 plugin with MSVC and run the output binary inside Carla.
This is not my development workflow by any means (it was the first time I used MSVC!) but it opens up the process for many more people, which always great.


One last bit of news regarding DPF is that I started testing the waters for VST3 support.
There is almost nothing to see just yet, as there is enough to do in DPF regarding polishing, fixing bugs and handling requests so that VST3 work is not a priority.
It is something that I have took an interest on lately though, as a potential way to attract commercial developers/vendors to DPF.
(and perhaps some well needed funding? who knows..)

Work on DPF will continue, you can grab all these changes from its develop branch.
Expect more news about it next month.

Other updates

While most of my time and attention was given to DPF, a few other things happened.
There is the whole "Audacity was bought up by Muse Group and added CLA, plus telemetry coming soon" thing...
I did some tests with building Audacity with mingw, and succeeded in setting up scripts to build required dependencies and then build audacity itself.
From what I tested on Windows everything seems to work.
(screenshot below is from Wine, but I also tested on real Windows via Virtual Machine)

Most mingw needed fixes were submitted upstream, but them now requiring a CLA means the PR will likely stay open indefinitely.
Also did some tests with building Audacity with wxQt and while it kinda works, still has some obvious issues - the wxWidgets Qt backend is not feature complete so it is normal for those to happen.
It is very likely I will end up maintaining some custom builds for Audacity once more network features creep in (analytics is coming to Audacity for sure, it is just a matter of when and how).
I am not interested on a fork, only in a way for casual users to get similar builds to the official ones without user-data tracking.

There are some other random things too, for example adding a new "-w" argument to the new jack2 zalsa tools so that it waits until the requested soundcard is available instead of failing to start.
This is very handy when adding it as part of some boot process.

Carla has also seen some pipewire-related fixes.
It is still not working 100%, but already know of a solution for them, just need to put that into code.
Expect a v2.3.1 release soon with these fixes, and also the LV2 UI resize handling mentioned above.

Finally I added support for FFmpeg JACK output. Seems to work well from what I tested, but I no longer have a need for it.
Once I am done with DPF and other things, I will try to submit this upstream. Feel free to grab the code and submit it yourself

Regarding packages in the KXStudio repositories, there are some small updates. Those are:

  • Added bjumblr
  • Added bslizr-uwu (custom skin to bslizr)
  • bslizr updated to 1.2.14
  • lsp-plugins updated to 1.1.30


That is all for now.
If you appreciate the kind of work I do, please consider a donation.
Thank you in advance for your support, and stay safe out there!

Next →