Home KXStudio > News
RSS

KXStudio : News

> Cardinal 22.02 is now released
On 2022-02-14 by falkTX

It is finally here, the first release of Cardinal.
Has been slowly brewing behind the scenes, and now ready for the masses.
First, some introductions...

cardinal

Cardinal is a free and open-source virtual modular synthesizer plugin.
It is based on the popular VCV Rack but with a focus on being a fully self-contained plugin version.

Cardinal was created first and foremost as a way to have Rack as a proper open-source audio plugin.
A proper audio plugin should be self-contained as much as possible, as to not interfere with the DAW/Host. Loading external modules clearly goes against this idea.
Not to mention being open-source, otherwise we are at the mercy of the wishes of a company for what we can and cannot do, which is not that great...
(in case you were not aware, VCV's Rack plugin version, called "Rack Pro", is a commercial closed-source product)

It needs to be said that Cardinal project and its authors do not wish anything bad to the original/official Rack project.
In fact, Cardinal wouldn't exist if not for Rack v2 release. (which has many needed things to make a plugin version work)
Cardinal and Rack should be able to co-exist friendly and peacefully, as they clearly have different targets.
It is likely most people will prefer to use Rack Pro for its official support and its big module collection (including commercial ones).
A feature comparison between Cardinal and Rack Pro can be seen here.

With that out of the way, let's go through a quick overview.

Plugin variants

Cardinal provides 3 plugin variants - Main, Synth and FX.
They are all equivalent in performance and behaviour, with only the IO and metadata that changes.
This is because some hosts are very strict on which plugins are allowed as instruments vs FX, so separate variants of the same plugin are needed.

FX and Synth variants both have 2 audio outputs, while Main has 8.
All variants have MIDI input and output support.

Main provides 8 audio inputs and outputs and 10 CV inputs and outputs.
Note that due to VST2 format not supporting CV ports, this variant is not available for VST2.

Synth provides 2 audio outputs but no audio inputs or CV ports.
Plugin type is set as "instrument".

And finally FX provides 2 audio inputs and outputs, but no CV ports.
Plugin type is set as regular "effect".

Included modules

At the moment the following 3rd-party modules are provided:

Additionally Cardinal provides its own modules for DAW/Host automation, time position and internal plugin hosting.

Current status and future plans

With the exception of a few bugs, Cardinal can be considered stable.
Though currently the following should be noted:

  • Keyboard input does not always work in some hosts #24
  • VST3 support incomplete/experimental #41
  • Windows 32bit builds do not work well #80

A parameter expander module was not ready on time for this release, but will come soon in a future release.
Fundamental is on a similar situation, there are some artwork license issues that prevent us from using Fundamental exactly as we want.
We plan to redo Fundamental's panel graphics in a more liberal license, so it then can be included in Cardinal.

There are a few modules we want to add, but they are being evaluated carefully as going forward anything we add in Cardinal needs to remain there forever, for backwards compatibility.
They must also have a GPLv3+ compatible license, which not all of them do.
Not to mention a clear artwork/graphics license... it is amazing how many of these projects do not care or understand about software licenses :(
Overall it makes packaging quite difficult, so it is natural that new modules are not added as fast as we wished for.

Something I hope to try soon is an alternative way to handle MIDI to CV conversion, as I don't like the way Rack does it at the moment.
The current Cardinal "core" modules follow the same exact approach as the official Rack, to make the transition easier, but some kind of "MIDI v2" modules will be done eventually.

Contributing

If you like the project and want to help out, there are basic building instructions here,
And an overview of the source code is available here.

Currently we are all on #cardinal IRC room in irc.libera.chat server.
Come join us in your favorite IRC client or through a Matrix bridge.

Installing new modules on an existing Cardinal binary is not possible at run-time, but we can add new modules to the build.
Details on this are available here.
Also check this wiki page where we discuss possible modules to include.

Installing and using

Install instructions are available on this wiki page.
If you are using the KXStudio repositories you can simply install cardinal-lv2, cardinal-vst2 or cardinal-vst3 packages as usual.
Consult the wiki page linked above for details on other distributions, or otherwise use the prebuilt binaries on the Cardinal releases page.

There is no Cardinal official media content as of yet, but if you are looking for tutorials just look for "VCV Rack" stuff which pretty much applies to Cardinal unchanged.
Some modules will appear slightly different, or not be available, but the overall idea on how to use it is the same.

A few CC-0 / public domain Cardinal patches are present directly in the source code.
You can use those as your starting point, they are fully free to do what you want with.

And that is it, go download, install and have fun!
If you find an issue or want to request a potentially useful feature, please use the Cardinal issue tracker.
And happy Valentine's day too. \o/

> 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.

Changelog:

  • 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

Downloads

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. :)

cardinal

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.

ildaeil

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.

Changelog

  • 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

Downloads

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.

← PreviousNext →