falktx @falktx@mastodon.falktx.com

If you have not noticed, I have silently abandoned the Cadence project. It was one of my first projects so code quality was/is quite poor.

I do like the JACK configuration tool from it quite a lot and want to keep it, so I have "forked" my own old project, removed a bunch of stuff and made "J2SC" for "JACK 2 Simple Configurator".

https://github.com/falkTX/j2sc

No release just yet, but did a bunch of work on it today and it is close.
Requires PyQt6 to run.

Tentative first 0.0.1 release next week.

Anybody knows someone working at Ableton?

Ableton Live crashes when picking Darkglass Anagram as USB interface because of its odd-number of IO (3 capture, 9 playback).
It expects USB IO to be stereo, but there is no such restriction in the spec afaik

> error: Windows Exception: EXCEPTION_ACCESS_VIOLATION
> info: Exception: Fatal Error: Unhandled exception

Cubase and Reaper work ok with it.

#ableton #abletonlive #usb

I summarized my Wayland + audio plugin UI adventures in https://github.com/lv2/lv2/issues/70#issuecomment-3067304097

I think in general it looks good, subsurfaces are a real blessing and I am glad to see it being well supported in compositors.

Well nevermind, fixed it in https://github.com/falkTX/wayland-audio-plugin-test/commit/ff9bdd884cfaeea95dd7402199a7741c39b7a727

(with some other little cleanup too)

basically I need to call "eglMakeCurrent(display, NULL, NULL, NULL);" to invalidate the GL context before deleting it.

everything works fine if this is the last thing the app does. crash happens if we create a new context after we delete one without "clearing" it first.

Any wayland experienced developers can help out diagnose a crash in libwayland-client?

clone https://github.com/falkTX/wayland-audio-plugin-test
make && ./test-crash

(needs quite a few deps because its a test repo, should be obvious to any developer)

valgrind reports in the attached picture.

I suspect the load, unload and load again to be the issue.

Got gtk4 client-side window decoration size details dynamically now - https://github.com/falkTX/wayland-audio-plugin-test/blob/51b301ef46fc9d20d96716a3ce1c5589b66344cf/gtk4-host.c#L31-L62

No need for super hacky "render window offline and then fetch position based on pixels", instead it is just:
1. create dummy window
2. fetch its initial size (200x200 on my laptop)
3. add a title bar
4. get title bar size and updated window size
5. x,y offsets are (new size - old size) / 2

picture shows this working nicely, I have an intentional 20px padding around the yellow rectangle

For context: https://www.image-line.com/fl-studio-news/fl-studio-2025-whats-new-2

Never thought I would see a damn AI chatbot inside a DAW as an official feature 😕

This is not going to stop is it... 😞

Curious thing...
Font, window-title-bar and shadow size are different between gtk3 and gtk4.

This is on a stock Gnome desktop, installed today, no settings changed at all.

They look similar but have their inconsistencies.
Yay for client-side decorations! 🎉 😢

Lazily loading gtk4 symbols in order to create a dummy window seems to work.
Also on gtk3.

Bless be wayland subsurfaces! 🙏

I tried to plug into gtk4 just for it to create a dummy window for me, idea being that then I don't need to deal with any of this lack-of-server-side-decoration business.

Well that presents its own problems, the wayland surface from the gtk4 window includes the shadow and decorations, also the size requested on start includes those too?? so I always get a smaller "window area" than expected, and I guess I now need to find that offset too somehow 🤔

Many hoops just to have window controls 😡

Hmmm very usable yes...

Yeah I really hate client-side decorations 😡

From top to bottom:

1. Firefox is able to follow Gnome desktop settings, as it uses Gtk on the lower level 👏

2. Konsole being KDE and based on Qt is not Gtk related, just makes assumptions on what decorations should be used

3. Carla being Qt behaves the same

4. Steam does its own thing, but also assumes what decorations should be used

I really thought Qt&KDE apps would behave better 😔

PS: Yes I prefer my window buttons on the left side

I mean, the app can request the compositor to have "server-side decorations" but this is treated as optional protocol.
See https://wayland.app/protocols/xdg-decoration-unstable-v1

It is implemented on all major desktops except Gnome 😭

So now all apps need to implement their own decoration, user resizing, etc feels very backwards and wasteful.

The way some compositors implement some features and some not is a bit annoying, but the main features are well supported overall.

Now to get DPF to support wayland... 😁

2 / 2

After a few days writing code and running tests directly with wayland APIs... I like it! 👏

It is quite different from X11, but so is doing Windowing and events on macOS and Windows. So it is kinda like another platform altogether.

The way of dealing with "protocols" feels a little weird at first, but I can really appreciate the extensibility provided and a centralized place for them.

So far there is only 1 thing I hate - client-side decorations.

1/2