Embedding or not?

[Rossmaxx]

Overview

Embedding creates more problems than it solves. Also, we are introducing newer methods for lv2 and clap.

If it works properly, embedding is a nice to have feature, especially in the MDI setup that we have currently.

Dom often says we should fix stuff instead of removing, we can debate over here for this context to decide if it's worth fixing.

Qt6 support

The x11 embedding uses the qt5-x11embed submodule, which if we intend to use with qt6, needs to be patched up.

Cross platform support

We have a cross platform "qt embedding" method which is full of bugs, and the other platform specific methods ain't much better either. Win32 method for windows is somewhat bug free. And mac, we don't even have embedding support to begin with, and for linux vsts, embedding is disabled by default

LV2 and clap

For lv2, @JohannesLorenz plans to use a completely different method using suil package. @messmerd what's things like on clap?

detach windows (#7586)

Since the detach windows PR is nearing completion, once that's done, having no embedding wouldn't look much out of place.

There's some other points which @tresf discussed on discord, which I couldn't catch up on even after reading the convos. Can you post a summary here?

Is it really worth it to keep it?

[tresf]

I'm not sure why this matter is being turned into a vote. We'll likely need to disable embedding by default for technical reasons that are out of our control:

• VSTs not scaled properly on HiDPI displays #7683
• https://www.reddit.com/r/lmms/comments/1iibunh/comment/mboqxi8/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

@sakertooth mentioned a desire to remove it completely claiming:

"... it's holding the codebase hostage...."

@Rossmaxx there are many mistakes in your post.

we are introducing newer methods for lv2 and clap.

From what I recall, suil won't embed at all. If this is true, this doesn't explain that properly.

And mac, we don't even have embedding support

macOS has QT Embed like the others, I just don't think we utilize it yet due to lack of plugin support.

Win32 method for windows is somewhat bug free.

From my understanding VST scaling issues exist there too just like in #7683 but may be hidden by our DPI awareness flags.

and for linux vsts, embedding is disabled by default

Is this statement even true?

Since the detach windows PR is nearing completion, once that's done, having no embedding wouldn't look much out of place.

That feature is about detaching Qt widgets -- which Qt Embed would benefit from if it we kept it. These tasks may have adjacencies to each other, but I don't see how they're related.

There's some other points which @tresf discussed on discord, which I couldn't catch up on even after reading the convos. Can you post a summary here?

You have my permission to copy/paste what I write, I just asked for investigation into better Task Manager icons so we can distinguish them when switching between windows.

"Currently when an app is not embedded, the icon for it is a generic placeholder, which makes it hard to find when looking for it in the Task Manager. If we nuke embedding completely, I'd like to see some effort into helping identify it, if technically possible. "

[JohannesLorenz]

From what I recall, suil won't embed at all. If this is true, this doesn't explain that properly.

I use embedding with suil in #7201 on Linux and it never had any problems (except for letting the parent widgets calculate the correct size, but I think that can be solved).

From a user perspective, I don't like duplicate windows (like in our non-plugin-Zyn). But I don't see a reason why we should not let the user choose - Some might even prefer weirdly resized plugins if they can have embedding - and some don't.

[tresf]

except for letting the parent widgets calculate the correct size

This is the predominant issue with VSTs, but there are also issues where users have reported that they cannot interact with the plugins at all.

Although the lessening of additional windows is a nice option to have, attempts to fix what's broken have been unsuccessful, especially on hidpi displays.

[JohannesLorenz]

I am against taking VST too much as a reference. Most reports, like your mentioned (IIRC), are from using Wine (or not clear if they are), and Wine is a huge source for issues of all kinds.

The only good references here are Linux VST (if confirmed to be Linux) or Lv2. I never had graphic issues with these two.

[tresf]

Zyn doesn't embed either and from your own words you also having sizing issues. I beg you to try hidpi.

I also think it's unfair to assume issues are predominantly wine related. Several users have reported identical sizing issues with native VSTs as well.

Wine actually has a workaround we've established, but it requires rebooting the wine server. We haven't found a similar workaround for Windows or other native plug-ins..If embedding doesn't work reliably, it's getting turned off. The current state is unusable.

[messmerd]

Embedding is broken on Linux and this leads to new users regularly asking why their VSTs aren't displaying correctly. So I think we definitely need to change the default on Linux to no embedding, at least until it gets fixed (if it gets fixed). If embedding works fine on Windows, I think we should keep it the default there.

If we could get Linux embedding to work, I think it would be nice for users if all windows were embedded by default, because with the detachable windows feature from #3532 they then could easily be detached if desired. The embedding option in the settings probably wouldn't be needed if we could get it to work that way.

CLAP plugins with a GUI can support floating windows, embedded windows, or both. I've heard that Wayland doesn't have proper support for embedded windows yet, which is unfortunate. But for platforms where we can have embedded windows, I think that would provide the most functionality if we could default to using it - assuming we could get it to work.

Though as a disclaimer, I know very little about GUIs, so I'm not a great person to ask about GUI-related questions.

[tresf]

... and I forgot to mention, we don't even try to embed Zyn, so our plugins are not consistent in this regard.

[JohannesLorenz]

Embedding is broken on Linux

Do you have a reference? For me, except resizing issues (which might not be caused by embedding itself), it always worked...

[tresf]

There's references in the post you're replying to.

• Zyn's lack of embedding is an example where we don't strictly follow the 'plugins should be embedded' rule.
• VSTs not scaled properly on HiDPI displays #7683 explains -- in part -- the HiDPI issues
• Here's a reddit post where the user can't interact with the plugin at all: https://www.reddit.com/r/lmms/comments/1iibunh/comment/mboqxi8/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button (this advice to disable embedding is very common in discord as well)

The software works better and more reliably when embedding is off. If we can't fix the issues we have with em embedding, we can't let embedding be the default behavior.

[JohannesLorenz]

It seems that your last 2 points only show the issue with wine (which is a source of errors), and your first point does not state that Embedding is broken on Linux.

Though, the question might not be too important if it just happens with some kind of configuration.

[tresf]

It seems that your last 2 points only show the issue with wine (which is a source of errors), and your first point does not state that Embedding is broken on Linux.

It also mentions how inconsistent this is... that we DON'T do it on Zyn add we should offer a consistent experience, your response offers no feedback on the fact that there's no consistency here. BTW, Zyn works great!

Though, the question might not be too important if it just happens with some kind of configuration.

Disabling embedding is constantly being recommended on Discord, I just don't use Linux for music production (I don't even use Intel) so I don't really have what's being demanded, but Discord is full of comments about how broken this experience is on Linux, so I would really recommend to reconsider this "some kind of configuration" stance, since embedding is not "broken some of the time" because when this problem occurs, the plugins are so broken that it ruins the experience. This goes away when embedding it disabled, so embedding must be disabled by default to provide a better experience until someone fixes this. We can't "wish" this into existence, if we want to keep embedding, someone need to fix it. I've spent about a week on it and it's just so broken that I'm not convinced it CAN be fixed, but I'd love to be proven wrong with actions, not opinions and not demands.

[SpomJ]

We have a cross platform "qt embedding" method which is full of bugs, and the other platform specific methods ain't much better either. Win32 method for windows is somewhat bug free. And mac, we don't even have embedding support to begin with, and for linux vsts, embedding is disabled by default

So here's my stance on this. Qt embedding is supposed to be simple and straightforward. As far as I'm aware it takes up about 4 LoC, and does its job rather decently. Ideally most of the bugs we encounter should be dealt with by Qt team, at least as far as I'm concerned. Scaling is one of those issues.

As far as other embed methods go, AFAIK it's pretty much what Qt does, but without abstractions -- I don't really know why are they present in the first place.

My suggestion would be disable embeds by default and leave at least Qt embedding in case it gets better.

[Rossmaxx]

Qt embedding is supposed to be simple and straightforward. As far as I'm aware it takes up about 4 LoC, and does its job rather decently. Ideally most of the bugs we encounter should be dealt with by Qt team, at least as far as I'm concerned. Scaling is one of those issues.

Exactly. That's my gripe too, something which should be dealt by the qt team isn't handled by them.

leave at least Qt embedding in case it gets better.

I don't think so, as even for qt6 in the testing branch, the same bugs persist, or it might have gotten better which I missed from my brief testing.

[tresf]

should be dealt by the qt team

Unless someone wants to pay for Qt support, this finger pointing gets us nowhere.

Qt owes us nothing. Even if Qt was receptive to this issue, the fix won't land on a version that we'll ship with for the foreseeable future, embedding decision needs to be handled BY US. Please stop this "pass-the-buck" rhetoric, it does not lead to decisions.

[JohannesLorenz]

Can anyone please clarify what is meant? Is this about embedding other types of GUI than Qt into Qt?

[Rossmaxx]

It's about the vst embedding behaviour. Windows vsts usually embed into it's own sub window within the mdi, which can be disabled using the settings. I thought you might already know this .

[JohannesLorenz]

Ah, you mean whether plugins in general should be embedded into the Instrument's QMdiSubWindow? Then I understand what you mean.

[tresf]

With the release of cmake 4, now our x11 embedding technique is suffering from bitrot: #7825 (comment).

[Rossmaxx]

I completely nuked vst embedding from the lmms codebase with #7837 . Testing needed to make sure everything works properly