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.

Packaging

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!