Home KXStudio > News

KXStudio : News

> DPF-Plugins v1.5 released
On 2022-01-16 by falkTX

Hello everyone, a new release of DPF-Plugins is here.
DPF-Plugins is a collection of DPF-based plugins, including Kars, MVerb and Nekobi.
This is mostly a bugfix release, keeping up with the cool kids for regular releases.


  • Initial experimental VST3 support
  • Add bottom-right resize handle in glBars and ProM, needed in plugin formats that can't do host-side resizing
    (ProM resize handle is invisible but still works, known issue)
  • Some plugin GUIs can use Cairo instead of OpenGL, if OpenGL is not available at build time
  • Standalones no longer require JACK, instead detecting at runtime if it is available
  • Standalones will now use RtAudio for native audio device access in case JACK is not available
  • ProM now ships with (optional) vendored libprojectM in case it is not available as system library
  • ProM now sets up and uses OpenGL3 context instead of OpenGL2 forward compatibility mode, fixing usage on macOS and Windows
  • Fix modal about dialogs
  • Fix more High-DPI related issues
  • Fix OpenGL context swap on GUI deletion, needed on hosts using OpenGL


The source code plus Linux, macOS and Windows binaries can be downloaded at https://github.com/DISTRHO/DPF-Plugins/releases/tag/v1.5.
The plugins are released as LADSPA, DSSI, LV2, VST2, VST3 and JACK standalone.

> KXStudio Monthly Report (November + December 2021)
On 2021-12-31 by falkTX

Hello all, this is yet another one of those monthly reports about the KXStudio project.
There was no November monthly report, due to me being busy with moving to a new place and a few other personal things.
This month though there are a few things to report on.

DPF and VST3 work resumes

After a little break on the VST3 implementation in DPF, I went back and reworked a few things that were clearly done wrong.
It is still considered experimental, but already works much better than before.
For example, UI to DSP parameter changes works properly now, which was not the case before in some hosts (including reaper).

Once complete, DPF based plugins will be one of the few that implement the whole component vs edit-controller separation.
This might prove quite valuable in the future, specially after hosts also implement the same.
We need to come back to this after I natively implement VST3 support in Carla.

Just as before, I am keeping a TODO list of items near the top of the relevant source code file for VST3. The same also applies to the UI side.
The super short summary is that most common things already work, with only optional buses, MIDI CC handling and minor details missing.
We don't get VST3 support finalized in DPF during 2021, but it shouldn't take that much longer now.

Continuing: Separating JACK tools from JACK1 and JACK2

Mentioned last time was the effort of splitting the example-clients and tools from the JACK repositories into a new repository/project.
I have been working with David Runge on this (or better said, he has been doing most of the work) with me reviewing each set of changes to each file one by one.
We are nearly finished, with only 1 file remaining.

Afterwards there is still some work to be done on the build setup and testing the whole thing, but it is good to see things progressing on this area that was being sadly neglected for many years.
If everything goes well, no one will notice a thing!
Maintenance is a lot of work that goes unnoticed, fun stuff..

Python 3.10 and updated PyQt woes

I do not know exactly the change that triggered it, but with newer versions of python and PyQt, pretty much all my tools that use PyQt are broken.
The community was quite helpful on fixing some Carla issues themselves without my direct intervention (as I do not run a rolling-release Linux distribution, I am not directly affected).
With this a new release of Carla is needed, the same for Cadence but that remains unfixed for the time being.

Cardinal, the Rack!

A new project has been brewing behind the scenes for more or less 3 months now.
It was not in my plans when 2021 started, specially since quite a few other things needed more attention..
But this was one of these things that is just impossible to put down as an idea.
In fact, lack of attention in Carla and JACK lately are due to this project, it is simply too exciting.

The quick history of the project is that, after VCV Rack v2 source code was made public, I began wondering if that codebase could be used for building an open-source plugin (unlike the official product, which is closed-source and commercial).
After finding out that VCV's official plugin would only support VST2 and still only the same 3 base architectures (Linux, macOS and Windows 64bit), also how the whole thing would supposedly work - loading modules from the library just like in the standalone - I was quite disappointed with the whole thing.
Rack is something that always interested me, but I was put off from the (to put it mildly) abrasive attitude towards open-source ideas and Linux packaging.
Running as standalone was also not that fun for me, I personally want to create synths and have those integrated in a DAW/sequencer workflow.

There was a project called VeeSeeVSTRack that also attempted an open-source plugin version of Rack, but it had some serious drawbacks:

  • Needs heavy changes to Rack source, which would have to be regularly maintained in order to keep up with upstream
  • All included modules need to be patched a fair bit just to work with it
  • Custom written plugin format support (so it only supported VST2)
  • Custom written OS-level Window handling (only supporting Windows and Linux/X11)

While the idea in general great, there was a not insignificant amount of work needed to maintain it.
If attempting something like this, would be best to not make the same "mistakes", and think about the whole deal on the long term.
With that in mind, the Cardinal project:

  • Does not fork Rack's source code, instead it uses it as submodule, replacing only a few critical functions and files
  • Besides internal modules, 3rd-party ones can be linked as-is with only changes to not use osdialog due to its event-blocking nature
  • Relies on DPF for plugin format support, so we get JACK, LV2 and VST2 from the start, VST3 in progress
  • Also relies on DPF for OS-level Window handling, so it works on macOS too (and eventually Haiku)

Similar to VeeSeeVSTRack, Cardinal builds the entire module collection as part of one binary and uses the host audio thread to drive the engine.
This means no online library access or external module loading, which is quite intentional.
More information on the "why" section of Cardinal's README.

The obvious question that might be in the air is what to make of the official Rack Pro plugin.
To which I say - if you enjoy Cardinal, go buy Rack Pro!
Cardinal would not exist without VCV Rack, so it is for our best interest that Rack lives on for a long while.
Also they serve different purposes:
Cardinal is open-source modules only, all integrated into 1 binary.
Rack Pro is just like the standalone with online library access, commercial modules etc. And obviously the official product too.
The Cardinal project includes a table of differences between itself and Rack Pro, in case you want to go deeper into technical details.

Cardinal should be considered beta-state at the moment.
While it already works quite well (except for a few known bugs as typical), there are a few missing pieces and license situation to sort out in detail.
A lot of Rack module developers started coding because of it, so without fully understanding artwork and source code license implications quite a few of them just copied what others were doing.
And this is the problem, Rack itself contains non-commercial and even non-derivatives clauses for its artwork.
A lot of developers copied the non-commercial clause without thinking too much about it, which makes them quite tricky if not impossible to package in a Linux distribution.
Before tagging v1.0, I want to sort out these details first, to ensure everything is done not only legally but also respectfully.
Already started this on this document, which greatly helps in giving an overview of the used source code and artwork licenses.

Before moving on, here's a screenshot, because everyone likes those. :)


Many other DPF additions

While working on Cardinal, DPF got a real stress-test for some of its features.
Some were missing and needed to be added in order to make Cardinal work proper, some were found to be broken.
In no particular order, these changes were made in DPF to accommodate for Cardinal:

  • Add clipboard (copy & paste) support
  • Add cursor support
  • Add file dialog save support (used to be only loading allowed)
  • Add "desktop portal" DBus service support for providing native file browser dialogs on Linux
  • Add APIs around finding the bundle path of the plugin
  • Allow LTO (Link-Time-Optimization) build
  • Auto-creating macOS VST2 bundle from build step, instead of needing to run a script
  • Many fixes around file browser dialog support
  • Many fixes around VST2 keyboard input (WIP)

The only missing feature at the moment is drag&drop support, but that needs an implementation on pugl's side first.
Once that side is done, I already have a plugin in which to test it the functionality, so it should be pretty quick.


And 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, happy holidays and a happy new year!

> KXStudio Monthly Report (October 2021)
On 2021-10-31 by falkTX

Hello all, another one of those monthly reports about the KXStudio project is here.
As you might have seen a few days ago we had v2.4.1 Carla release.
I was hoping to do a JACK2 release as well, but was busy with other things and did not have it ready on time. Next time then.

DPF + VST3 on pause

While VST3 support in DPF has advanced enough to load already in quite a few hosts, I got personally annoyed with it after finding out the way I did the UI/DSP separation is just completely wrong. :(
Working with the internals of VST3 has been quite frustrating, so just taking a little break from it.
Currently still going with the target of finalizing VST3 support in DPF (at least in beta-like status) by the end of the year.

I want to say, dealing with VST3 internals has made me appreciate LV2 even more.
VST3 has some good design choices and ideas, but parts of it are also just awful and nonsensical.
Hopefully after the initial implementation is done we do not have to change it much.

ImGui rendering issues fixed

Last month I reported about Dear ImGui being integrated as a DPF widget, with only some high-dpi rendering issues remaining.
Happy to report that this is finalized and tested to work on a couple of different configurations.
I might do a quick plugin set from porting existing audio software to DPF, as a way to 100% verify ImGui in DPF.
But for now Ildaeil (more on that below) has served as a nice test-case.

JSFX as plugin type in Carla

Jean Pierre Cimalando has started work on adding JSFX "plugin" support for Carla.
JSFX has nothing to do with JavaScript, but rather it originally comes from REAPER's extended audio processing capabilities.
They have defined a format for writing audio plugins that can be written and compiled on the fly.
This work from Jean is not yet complete, but great progress has already been made.
It is likely to end up on the next Carla release.

A little new test-project: Ildaeil

One crucial point for me accepting JSFX support in Carla was that it couldn't be limited to just Carla.
But this support being added directly in Carla doesn't help with that.. or does it?

Announcing Ildaeil! (sorta.. read on)
In case you do not know, Zrythm is using Carla as backend to deal with non-LV2 plugins.
Some of the things it uses were never properly tested in Carla or any other software, making it hard to fix bugs.
This combined with wanting JSFX on more hosts than just Carla and ImGui now fully working in DPF has given me enough motivation to try out a new project that would just combine everything into one.
This project is called "Ildaeil".

Ildaeil is basically Carla as a minified plugin, where instead of running the full GUI you have a super minimal GUI and set of features.
It uses DPF for the plugin-side (that is, to be an LV2, VST2 and VST3 plugin) and then Carla for the plugin hosting side. A bridge between the 2 worlds, basically.
For now I made it so that it lists the available LV2 plugins on the system and allows to load 1 from the list, embedding its custom GUI if possible.


This is not really an announcement because I have not yet decided the full scope of the project.
There are a LOT of things it could do, but then it becomes quite the work to maintain.
If you want to give it a try, feel free. But reports are welcome, feature requests are not (at this point).

Separating JACK tools from JACK1 and JACK2

For a very long time I have been meaning to merge back the changes done in JACK examples and tools from JACK2 back to JACK1.
Back in JACK2 v1.9.15 release I stated that help on this would be appreciated, but not much has happened since then.
Now that PipeWire is slowly becoming a thing, this is becoming crucial.

For distributions like Arch that do not typically split packages (hypothetically) installing pipewire-jack would remove jack2 and replace it with PipeWire's version.
But the tools like jack_connect, jack_wait, etc are part of the jack2 package, not pipewire-jack.
Installing pipewire-jack would (hypothetically) remove these tools.
There are quite a few set ups out there that rely on them, so a solution is needed here.

David Runge has started the effort of splitting these tools from the JACK repositories into a new one.
The idea is that JACK will no longer ship with them, and they become an extra set of tools to install separately.
This allows to switch between JACK versions (JACK1, JACK2 or PipeWire) and keep the same exact set of tools.

We will need to have new JACK1 and JACK2 versions that remove these tools before the new project can be officially tagged and released.
More news on this soon.


That is all for now.
There were a couple of other things done in DPF and a few other projects, but something I will cover in upcoming months.
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.4.1 has been released
On 2021-10-15 by falkTX

This is a bugfix for Carla version v2.4 series, bringing some improvements and fixing a few bugs.

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.


  • Better handling of VST3 parameters (hide as needed, number of steps, etc)
  • Fix compatibility with Python 3.10
  • Fix getting the proper X11 UIs size for more plugins
  • Fix plugin bridges not automatically closing if main Carla dies on macOS (similar to how it is done on Linux)
  • Fix unused parameters preventing real ones from showing up in the edit plugin dialog
  • Fix CarlaNativePlugin.h and CarlaPluginPtr.hpp header files not installed system-wide
  • Fix XY-Controller GUI missing on "make install" target
  • Fix VST2 plugins under macOS and High-DPI (by not reporting scale factor)
  • Replace -lpthread usage with -pthread, fixing RISC-V builds
  • Send keyboard and focus events as needed/possible to VST2 and VST3 UIs
  • Small tweaks to XY-Controller (make lines 1px thick, close UI with Esc key)
  • Special tweaks for static plugin target build (embeding carla statically in other applications/plugins)
  • Other minor fixes and tweaks


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.4.1 at this point.
Carla v2.4.1 is provided in the KXStudio repositories and in many official Linux distribution repositories too anyway.

> KXStudio Monthly Report (September 2021)
On 2021-09-30 by falkTX

Hello all, it is time for yet another one of those monthly reports about the KXStudio project.
In case you missed it last month, there are now dedicated KXStudio Board and KXStudio Development pages.
These serve to give a quick overview of the work being planned and the one actively being done.
Note that I typically remove stuff from the "done" column of the board a few days into the start of each month.

VST3 for DPF

The first new thing worth mentioning is the substantial work for VST3 in DPF made this month.
Though it is still in a state I consider alpha at the moment, everything that is crucial is implemented: from audio, midi, time position, parameters, programs, state, latency and gui.
Not recommended to release anything based on this yet, as there are memory leaks and the GUI only works on Linux at the moment (and known to break REAPER due to not plugging into the host runloop yet).

This VST3 implementation uses custom C-compatible API headers instead of the official SDK, so that we can have commercial plugins while not being tied to Steinberg and its restrictive licensing.
There is a lot of boilerplate code to implement for stuff that the SDK typically does for you, and it is still pretty unclean, but works for now for testing.

Worth noting that there is a clear DSP / UI separation for this VST3-compatible DPF implementation.
Instead of the UI having direct access to the DSP side and just calling functions, everything is passed through a VST3 "connection point" as messages.
There is something in place to support hosts that do not provide the "connection point" interfaces, so everything still works there too.

I expect to finalize the VST3 support already in October as there does not seem to be any technical limitation or blocker, it is just time needed to implement all the things.
Sadly VST3 only officially specifies support for Linux, macOS and Windows.
DPF can build for more systems than just these 3, so I made a question/request upstream for how to tackle the issue.

Other DPF updates

In other DPF news, I began experimenting with supporting Dear ImGui as a widget implementation.
Everything already works except drawing on the correct position with high-dpi, there are some weird quirks to figure out in regards to the OpenGL viewport.
The target is to allow to use ImGui for the full plugin gui or just as a subwidget.


Other worthy mentions on DPF world are the FEATURES and LICENSING table, which should help people decide if DPF is worthy for them or not.
As you might know, DPF is liberally licensed (under ISC) so that it can be used for commercial plugins without restrictions.
Hopefully clearing the license situation helps on that side of things.


That is all for now.
There are some bug-fix releases planned, but that will be something for October.
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 →