KXStudio : News

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

Other

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!