Linux: gain example has no GUI

[chairbender]

Hi, I've followed the instructions and built the gain example, both vst3 and CLAP. I'm on PopOS 24 (Wayland DE).

In both CARLA and REAPER, the plugin shows no GUI, it's just a black window. Below screenshot is from REAPER. Same thing happens with CLAP and VST3. BTW, I am running reaper under x11 (via xwayland) which is supposedly less buggy.

CARLA (VST3)

Wondering what I can do to help troubleshoot / debug this.

[micahrj]

My first guess is that this would be caused by the frame event not firing. An easy way to check that would be to add a dbg!(event); to the top of ViewState::handle_event.

[chairbender]

Indeed, ViewState.handle_event never gets called.

[chairbender]

It looks like there's quite a few changes between portlight fff171e9f3f70a9604102e1e1877ad67d0c2badd (what the build I was trying uses) and portlight master - could that be the issue? Maybe you've already fixed this but I'm just on too old of a version. It looks like the gain example isn't up to date though - when I switch to portlight/master I have quite a few compile errors.

Is there a branch or something with a version of the gain example updated I should try?

EDIT: oh yeah, that commit is ancient at this point.
Maybe I should try updating gain example for the latest portlight, if that hasn't been done yet?

I'll give that a try, should be educational nonetheless.

[micahrj]

Indeed, ViewState.handle_event never gets called.

Oh, the callback never gets called at all! That's different; I was guessing that the other events were still getting called and just the Event::Frame wasn't being triggered. In that case, my guess is that the initial window creation is failing, and I would try adding some debug logging to GainView::open.

It looks like there's quite a few changes between portlight fff171e9f3f70a9604102e1e1877ad67d0c2badd (what the build I was trying uses) and portlight master - could that be the issue? Maybe you've already fixed this but I'm just on too old of a version.

Oh yeah, it's definitely possible that the issue has been fixed already. I can probably take care of upgrading the gain example to the latest portlight version sometime this weekend, but you're welcome to give it a try as well if you'd like.

[chairbender]

I'll keep going with the portlight version upgrade for the gain example, it's been a good exercise and good progress so far. It's cool how coupler itself has no dependency on portlight (afaict).

[micahrj]

#8 updates the gain example to the most recent portlight version, if you want to give it a try.

[chairbender]

#8 updates the gain example to the most recent portlight version, if you want to give it a try.

Same problem still, surprisingly - handle event (well, now it's just called event) is never called!

I will look at what's going on in open.

[chairbender]

so far, it seems like the event loop is never getting started in the first place for the x11 backend (portlight). It's being created (new is called) but EventLoopState::run is never being called. I'm not sure what is actually supposed to be calling run in the first place (find usages in rustrover is saying nothing, but I think RR is confused by the backend switching stuff).

I did notice in the "basic" example in portlight the event loop is explicitly started, but in the gain example that doesn't happen. (and the stupid newbie thing I immediately tried of course was calling it directly in .open in the gain example, which, predictably, freezes the entire daw 😄 )

Maybe the issue is just that run is never being called in the x11 case, to start up the event loop?

[chairbender]

Haven't managed to figure out how I'm meant to spawn the "event loop thread" using the library...naively, I considered in open() just spawning a new thread and calling event_loop.run inside there, but that doesn't work because EventLoop doesn't implement Send. If I wanted to us an approach like that I'd have to instantiate the EventLoop and all the logic inside the .spawn() lambda, and then wouldn't be able to return the event_loop / task in the GainView that the open() method needs to return (since that data isn't Send-able).

I assume I've overlooked the intended mechanism for doing this.

I should admit I'm quite new to Rust multithreading.

EDIT: I guess for X11, we're supposed to use timers or fd (at least for CLAP) for polling for events ? Struggling to find where that's being done. I assume it would be in portlight's x11 backend in window.rs or event_loop.rs, but it doesn't look like either of those mechanisms are being set up (not to be confused with the timers.rs stuff or the usage of fd in the run() loop, which won't do anything if the loop isn't getting called in the first place).

[micahrj]

Oh whoops, I feel silly now. Yeah, you're correct that on Linux it's necessary either to hook into the host's event loop using the file descriptor and timer APIs (both VST 3 and CLAP support this) or to spawn a separate thread for running the event loop. I did actually have the file descriptor approach fully implemented and working in an earlier version of Coupler (see this old version of the gain example), but I've done some major restructuring of the codebase since then, and I guess I just never got around to reimplementing it since I've been primarily developing on Windows and macOS.

The relevant functionality still exists on the Portlight side of things (EventLoop implements AsRawFd and has a poll method), so it will just be a matter of exposing the host file descriptor and timer APIs on the Coupler side.

Sorry for sending you on a wild goose chase!

[chairbender]

Just looking at the vst3 case, it looks like we'll need to store an IPlugFrame somewhere (for the setFrame hook) in order to register the fd. Previously, it lived under View -> state (PluginState) -> editor_state (EditorState) -> plug_frame (IPlugFrame).

Where in the hierarchy do you think makes sense to store that? I could see a few possible places:

• New field directly on PlugView
• Within a new, to-be-named struct, as a new field under PlugView
• New field on Vst3ViewHost (since in the old code, IComponentHandler lived together with the IPlugFrame on EditorState, and Vst3ViewHost is now where IComponentHandler lives, putting IPlugFrame on Vst3ViewHost would make it live together with IComponentHandler as well)
• New field on MainThreadState

It seemed like Vst3ViewHost might be the most likely place for this considering the parity with the older codebase I mentioned. I will admit this is a rather backwards way of trying to decide where something should go (trying to match the old code) but it's just my stopgap measure for not fully grasping the organizing principles for the current code.

(as an aside, not sure whether you prefer to discuss these things on GH or the Zulip instance.)

[chairbender]

Well, I gave it a try for VST3 as a starting point, see #9