[BUG] GUI window is not displayed correctly

[maxigaz]

Describe the bug Under Arch Linux and i3, when I try to open the GUI of BYOD inside Ardour or Carla, inside the window, only a part of the plugin host can be seen, not the actual interface of BYOD. (See the screencast below for clarity.)

When I try the same with Sway and Carla, the window doesn't even appear.

This happens with both the LV2 and VST3 versions.

To Reproduce Steps to reproduce the behavior:

1. Load BYOD in an empty Ardour or Carla session.
2. Notice the content inside BYOD (or the lack thereof).

Expected behavior BYOD's window is shown with actual content.

Screenshots https://user-images.githubusercontent.com/10419911/203429846-213ba830-9e2c-459c-b99d-7578379545f4.mp4

Desktop (please complete the following information):

• OS: Arch Linux
• DAW: Ardour v7.1, Carla v2.5.2
• Version: 1.1.0

Additional context BYOD v1.0.9 doesn't have this issue.

[jatinchowdhury18]

Thanks for the bug report! Unfortunately, I don't have an Arch Linux setup to test with at the moment, but I'll ask around to see what I can do.

First, I wanted to ask if you're currently building the plugin from source, or if you're using a build provided by a package manager? (I don't think the .deb installer provided in the official release would work on Arch, but I may be wrong about that)

One other thing that might be helpful is sharing a log file from an instance of running the plugin, just to see if there's anything in the logs that might give some clues as to what is going on.

I have seen a similar issue in the past on Windows, where the plugin was trying to use OpenGL, but the host machine did not support a high enough version of OpenGL to actually render graphics in the plugin window. By default, OpenGL support is turned off when building the plugin on Linux, but I suppose a package manager build may have overridden that option.

One other thing that's a bit curious is that the UI was rendering properly in version 1.0.9... from version 1.0.1 to 1.0.9 we re-worked much of the UI implementation, but from 1.0.9 to 1.1.0 very little was changed.

[maxigaz]

First, I wanted to ask if you're currently building the plugin from source, or if you're using a build provided by a package manager? (I don't think the .deb installer provided in the official release would work on Arch, but I may be wrong about that)

I installed BYOD through the AUR package chowbyod-bin, which downloads the .deb package from GitHub releases and unpacks it. Although now I have both v1.1.0 and v1.0.9 manually unpacked to a directory, and one of them is symlinked to ~/.lv2 ~/.vst3. (The reason for this is being easy to jump between the two versions.)

One other thing that might be helpful is sharing a log file from an instance of running the plugin, just to see if there's anything in the logs that might give some clues as to what is going on.

Oh, right. I was looking at the output of Ardour, but nothing about BYOD was printed. Anyway, here's a log file generated in ~/.config/ChowdhuryDSP/BYOD/Logs: BYOD_Log_2022-11-24_11-19-46.log

I have seen a similar issue in the past on Windows, where the plugin was trying to use OpenGL, but the host machine did not support a high enough version of OpenGL to actually render graphics in the plugin window. By default, OpenGL support is turned off when building the plugin on Linux, but I suppose a package manager build may have overridden that option.

I don't know, but the log file says OpenGL is not available (although it works in other applications).

[melonlm]

Similar behavior in Debian Sid - irrespective if run standalone or in Carla host (both LV2 and VST tested) Only small difference is that with OpenGL enabled via config file no window shows up at all, and with OpenGL turned off a blank window appears. No errors show up in the log file.

[KottV]

No problems in openSUSE TW with deb from here or with OBS build. Could it be due ubuntu-latest CI environment? @maxigaz This is strange that Arch hasn't native BYOD package and just downloaded pre-build binaries,

[maxigaz]

This is strange that Arch hasn't native BYOD package and just downloaded pre-build binaries,

I'm not sure what you mean by 'native'. When an AUR package is being installed, makepkg is run that creates a .tar.zst package compatible with pacman, Arch's own package manager.

Also, I don't know why you consider using pre-built binaries 'strange'. (Again, this is the AUR, not the official Arch repositories.)

[KottV]

"Strange" because Arch is source-based distro afaik, and by "native" I mean that packages has to be built of sources. BYOD is quite simple to build. I think it's worth you try to do that, built from source and check if the bug persist.

[maxigaz]

"Strange" because Arch is source-based distro afaik, and by "native" I mean that packages has to be built of sources

No, Arch is a binary-based distro. Perhaps you're mixing it up with Gentoo (which is source-based)?

[KottV]

Yeah, Arch is binary indeed. But there is no BYOD PKGBUILD for building from sources.

[jatinchowdhury18]

Thanks for continuing the discussion while I was out for American Thanksgiving :).

I'm not sure I have enough knowledge of the Linux distributions being discussed to provide much insight, but I agree that it seems like trying to build from source might give us some clues as to what exactly is going on.

I don't know, but the log file says OpenGL is not available (although it works in other applications).

Right, so the log file would previously show the same message regardless of whether the plugin was compiled without linking to OpenGL or whether the host machine did not support the required OpenGL version. I've made a little change so at least now the log message will show something different.

I also took a minute to check out what changed between version 1.0.9 and version 1.1.0. I didn't see anything in the BYOD source code that looked like it could be causing the issue, but I did update the JUCE dependency, so it's possible that something changed in there which could be causing the issue.

[melonlm]

Regarding potential JUCE changes affecting the GUI behavior. I'm happy to provide more feedback on behavior on my systems, but since i'm not a developer could you, jatinchowdhury18, plase provide:

1. Instructions on how to build the package in more "chatty" mode - so potential debug messages can be shown, both from BYOD and JUCE.
2. Instruction (if feasible) how to build BYOD against disto-provided JUCE library - as those should in theory be more compatible than the fresh upstream version.

Thanks!

[jatinchowdhury18]

Regarding potential JUCE changes affecting the GUI behavior. I'm happy to provide more feedback on behavior on my systems, but since i'm not a developer could you, jatinchowdhury18, plase provide:

1. Instructions on how to build the package in more "chatty" mode - so potential debug messages can be shown, both from BYOD and JUCE.
2. Instruction (if feasible) how to build BYOD against disto-provided JUCE library - as those should in theory be more compatible than the fresh upstream version.

Thanks!

Sure thing! Probably the best thing to do is to follow these commands in your terminal (this is assuming your machine has CMake and some C++ compiler installed):

# Clone the repository and initiaqlize submodules
$ git clone https://github.com/Chowdhury-DSP/BYOD
$ cd BYOD
$ git submodule update --init --recursive

# Configure and build with CMake
$ cmake -Bbuild -DCMAKE_BUILD_TYPE=Debug -DBYOD_BUILD_CLAP=OFF
$ cmake --build build --parallel 4

# Run the standalone app from the command line
$ ./build/BYOD_artefacts/Debug/Standalone/BYOD

This will run the plugin as a standalone app in debug mode. So generally things in the app will probably run a bit slower, but the log file should show more information if things are going wrong.

Alternatively, you could try running the plugin as a standalone app under a debugger like gdb.

$ gdb ./build/BYOD_artefacts/Debug/Standalone/BYOD

It's probably possible to attach a debugger to a plugin host like Carla or Ardour, but I haven't tried doing that on Linux before.

[maxigaz]

# Clone the repository and initiaqlize submodules
$ git clone https://github.com/Chowdhury-DSP/BYOD
$ cd BYOD
$ git submodule update --init --recursive

# Configure and build with CMake
$ cmake -Bbuild -DCMAKE_BUILD_TYPE=Debug -DCMAKE_BUILD_TYPE=Release
$ cmake --build build --parallel 4

# Run the standalone app from the command line
$ ./build/BYOD_artefacts/Debug/Standalone/BYOD

@jatinchowdhury18 I've just tried running these commands in a VM (also running Arch Linux). After the build process ends, there's no such directory as Debug. Only the directories JuceLibraryCode and Release exist under ./build/BYOD_artefacts.

[KottV]

CMAKE_BUILD_TYPE=Release will override Debug

@maxigaz just run standalone binary from the Release folder

[jatinchowdhury18]

# Clone the repository and initiaqlize submodules
$ git clone https://github.com/Chowdhury-DSP/BYOD
$ cd BYOD
$ git submodule update --init --recursive

# Configure and build with CMake
$ cmake -Bbuild -DCMAKE_BUILD_TYPE=Debug -DCMAKE_BUILD_TYPE=Release
$ cmake --build build --parallel 4

# Run the standalone app from the command line
$ ./build/BYOD_artefacts/Debug/Standalone/BYOD

@jatinchowdhury18 I've just tried running these commands in a VM (also running Arch Linux). After the build process ends, there's no such directory as Debug. Only the directories JuceLibraryCode and Release exist under ./build/BYOD_artefacts.

Ah, that's a rather embarrassing typo! The first CMake command should have been cmake -Bbuild -DCMAKE_BUILD_TYPE=Debug -DBYOD_BUILD_CLAP=OFF.

[maxigaz]

Thank you, @jatinchowdhury18! I've compiled it again and here are my findings:

• The standalone version from the Debug directory crashes after a few seconds without any windows shown. Here's the terminal output (with a backtrace): byod-debug-log.txt
• The standalone version from the Release directory also crashes after a few seconds, but an empty window appears (with solid black). The output is a lot less verbose this time:

  FATAL: exception not rethrown
  [1]    12360 killed     ./BYOD

• The LV2 version from either directory behave the same as I wrote in my original post when I run them in Carla. (The window appears without any meaningful content.) The output log is also the same, even for the Debug version.

[melonlm]

Okay... plot thickens a bit.

So I did a build with DCMAKE_BUILD_TYPE=Debug set - on my Debian Sid box. Only difference was pretty much that the log contents were also written to stdout, and few assertion failures shown : JUCE Assertion failure in juce_AudioProcessor.cpp:349 JUCE Assertion failure in juce_AudioProcessor.cpp:355 JUCE Assertion failure in juce_AudioProcessor.cpp:359 JUCE Assertion failure in juce_AudioProcessor.cpp:362

No matter if I built against your pinned JUCE revision or the master branch; also nothing in system logs I could find pointing to errors - just blank window showing up after running BOYD, with audio processing running underneath.

Then I had an idea that the display sever is the problem, so I logged out of my daily driver i3 session on X11 and opened a GNOME wayland session. And there BYOD just run.... It happily displayed a working GUI, albeit not native Wayland, but Xwayland.

So looks like BYOD 1.1.0 (and git version run from source) will run on Xwayland and not on "bare metal" X11 server. Anyone has an idea why???

Oh, I use Nvidia propertiary drivers, that may be significant in this context.

[jatinchowdhury18]

Interesting, thanks for the updates everyone!

From the debug log that @maxigaz shared, it looks like the primary issue has something to do with starting/stopping threads (specifically this assertion is getting hit. I'd definitely be curious what sort of information you might get from running the debug build under GDB.

For @melonlm, the wayland vs X11 difference is definitely interesting, although I'm not really sure what to make of that. The assertions that were getting hit are mostly specific to the Standalone build (basically the plugin wants stereo in/stereo out, but if your sound card has too many or too few inputs and outputs, those assertions might get hit).

[maxigaz]

I'd definitely be curious what sort of information you might get from running the debug build under GDB.

Here's the output I'm getting: byod-gdb.txt

[jatinchowdhury18]

Thanks for sharing! I was hoping to get a more descriptive stack trace out of gdb, but I guess that's what it is. Anyway, I'll see if I can get some sort of testing setup worked out on a friend's computer later this week.

[maxigaz]

I've just tried the newly released v1.1.3. While the VST3 version still has the issue, the GUI now works in the LV2 version. Thank you!