Surge: Update to latest vstgui

[falkTX]

Latest "stable" version of vstgui has many issues under Linux, preventing it from working properly.

To Reproduce
Try to load the VST2 plugin in Ardour or Audacity.
The mix of Gtk2 (from Ardour) and Gtk3 (from the plugin) will result in a crash.
Qt based hosts are susceptible too, because they can be using the Gtk theme option which as of now uses Gtk2.

Expected behavior
The plugin should load without crashing the host.

The issue here is clash of library symbols.
Different Gtk versions uses the same name for its functions, as API does not change too much.
Mixing different toolkit versions causes the crash.
Note that Gtk4 is a thing coming up very soon...
It is never a good idea to use toolkits in shared library form when it comes to plugins. We should always try to make them self-contained.

The develop branch of vstgui has moved away from Gtk3 and is using cairo + xcb, so we will no longer have the crashes if we update to it.

[baconpaul]

@falkTX thanks; did you manage to do a build with the latest vstgui? How did you do it? (Like: what premake changes, what git commands, etc...)

@jsakkine tagging here also

[falkTX]

I commented out some code that had small API breakages, as I just wanted to get it built.
Also the premake needs to be adjusted to use xcb and cairo instead of gtk3.

I can start a PR with the work needed to get this going, using my own vst3sdk fork with the right versions.
Stuff that does not build I will just ifdef out, leaving for someone else to resolve.

This is how far I got:

[baconpaul]

OK cool. just FYI those are the components painted by "paint" and not by "load bitmap" so that draw is consistent with the UI not being able to load the bitmap resources in SurgeBitmaps.cpp.

I have no idea how bitmap resource management works on linux.

If you ifdef it out can you ifdef it out in a negative way with a symbol you positively set so it doesn't turn off other platforms? You know like

if !SKIP_NEW_LINUX_STUFF

endif

and define SKIP_NEW_LINUX_STUFF in your premake branch? You get the idea. Then if it does accidentally merge it doesn't turn off features for other platforms.

Thank you very much.

[baconpaul]

Oh also if you and @jsakkine would like, we can make a linux branch on surge-synthesizer/surge distinct from master for linux collaboration. Just let me know.

[jarkk0sakkinen]

Lets not switch VSTGUI SDK unless we find a real show stopper, i.e. a roadblock that can only be sorted out by doing the upgrade. GTK4 coming soon or not is a non-issue because the version we use, uses GTK3.

Usually switching stuff in the middle does not gain in the end. Better try to fix the issues what we have instead of introducing a new set of issues. Doing the switch could introduce a new set of problems to other platforms that Surge supports.

I think right time to reconsider the switch is after 1.6 has been released.

What I would suggest, however, is to pull a version of VSTGUI we want to use for the release, instead of using submodules so that we can fix possible bugs in the implementation. We can reconsider submodules again after 1.6.

I'm totally against of any linux sub branch. It can easily lead to quick hack solutions that might be hard to merge back to the master.

As long as I've written code professionally, the usual lesson has been, that "lets switch everything" is destined to fail.

[baconpaul]

I'll leave it to you guys to sort out! Was just giving you an option if you wanted to share and merge diffs without using your repos.

[jarkk0sakkinen]

@baconpaul, we cannot sort out my comment about submodules. I think for 1.6 that might be a good thing to do.

[jarkk0sakkinen]

Alternative would be to fork some submodules to surge-synthesizer. We can decide which, when we encounter actual regressions. Might be even zero, might not. Maybe we can postpone that discussion up until that point?

[jarkk0sakkinen]

@baconpaul, I think it should be fairly obvious to everyone that we don't want to fix VSTGUI just before the first release. That is a constraint that we should set also for Linux.

[falkTX]

A plugin that crashes on load seems to me the biggest showstopper possible.
It is not on all DAWs, but even for the lucky users it will make other plugins crash later on (if they reference Gtk2).

I think we should make that clear in the README or something like that.

[baconpaul]

@jsakkine I think that's obvious, if and only if it works. TBH I am finding bugs in vstgui on mac as I implement zoom. I think I can just subclass my way out of them on mac, but it's entirely possible the kit won't work on linux.

Has anyone actually built a working vst2 on linux which shows the UI and works yet? I think until we get to that point we should reserve judgement on what the path will be!

Obviously if we don't have to fix vstgui that's best.

@falkTX I think the linux section of the readme is sparse at best. Anything you want to add, just fire over a PR.

[jarkk0sakkinen]

@baconpaul, yeah, lets make new decisions based on what we encounter with VSTGUI when on Linux. Fair enough?

@falkTX, It used to pull down the whole DAW until I fixed some leaks in the VST2 plugin. Now it crashes, which is already much decent behaviour. I'm working on build first to get further, because it is mandatory to have easy way to build before even trying to fix anything.

When you state that "plugin crashing is a show stopper", you are claiming by essence that there is regression, which is completely unfixable. You should show real data to support your view.

[jarkk0sakkinen]

I also doubt that all the possible root causes for crashes would be only because of VSTGUI.

The best way to help Linux is to fix the code where it crashes, not turn things over.

I post one of my favourite articles to further support my claims :) https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

[baconpaul]

Yeah it's up to you guys. The only thing I check on linux now is my changes still link. Happy to read any PRs or offer any thoughts on impact back to mac (or win) if you want.

Although I will say that @falkTX claim that vstgui has bugs is rather credible from what I've seen on the mac implementation. Whether they are surmountable or not on linux I have no view.

Good luck!

[jarkk0sakkinen]

The decision logic here is fairly trivial. If we encounter a crash, it must be root caused first. If it turns out that the only reasonable way to fix whatever is encountered, is to switch VSTGUI, then we switch.

Even in this case it must be validated first that it does not break macOS or Windows.

The problem for me in the end is not the switch itself. The problem for me is to make big decisions without backing it with real data.

[jarkk0sakkinen]

I think this fairly standard practice. Applies to any type of engineering. Decisions can be done, but only with hard evidence...

[falkTX]

The issue with gtk2 + gtk3 mixup causing crashes is well known in Linux.
We had to deal with this for a long time for LV2.
See
http://lists.lv2plug.in/pipermail/devel-lv2plug.in/2016-March/001593.html
http://lists.ardour.org/pipermail/ardour-users-ardour.org/2018-November/028948.html

A few other examples I found quickly:
https://stackoverflow.com/questions/26517669/gtk-2-and-gtk-3-in-the-same-process-is-not-supported-for-qt5-application
https://github.com/mate-desktop/mate-panel/issues/565
https://bugzilla.redhat.com/show_bug.cgi?id=1285356

[baconpaul]

@falkTX so from that is it fair to conclude that "if surge uses current vstgui it will never work in ardour, since current vstgui is gtk3 and current ardour is gtk2"?

I've written a lot of code on linux; but have written basically zero UI code on linux so don't know those frameworks or state of play at all.

Thank you for sharing those articles.

[falkTX]

@falkTX so from that is it fair to conclude that "if surge uses current vstgui it will never work in ardour, since current vstgui is gtk3 and current ardour is gtk2"?

Correct. Though this applies to more hosts than just Ardour

[baconpaul]

Right. It would also apply to a host which didn't use GTK at all, but which had in-process plugins and loaded a gtk2 plugin before surge (which would make it seem like surge crashed the DAW); or a gtk2 plugin after surge (which would make it seem like that plugin crashed the DAW). And so on.

[jarkk0sakkinen]

@falkTX, The problem is the lack of hard evidence, not whether you are right or wrong. You make claims without any supporting data.

I would guess that the problem is in the nutshell:

• GTK2 and GTK3 loops race in the same address space.
• If the plugins have their own process (like you can select from Renoise setting), then it should work. It is then just an application using GTK3.

If that holds, then the switch might make sense for 1.6. I think, however, that it should be done after fixing Linux to the level that Surge running in its own process work. Better to do that for stable than unstable code.

[jarkk0sakkinen]

After we have reached the goal of having Linux plugin work on its own process, all the regressions that we might encounter, would be because of DAW's UI loop fighting with the use of XCB. That way we can focus on one set of regression at a time and do less guess work.

[rghvdberg]

just my 2 ct.
I have a plugin which uses aubio for onset detection.
I use aubio 4, Ardour uses aubio 3 and ardour crashes to desktop...
Had to link aubio static to resolve that. Which @falkTX thankfully did for me because I was totally lost :-)
If a small library like aubio causes crashes imagine what happens when you use gtk2/3 qt4/5 or whatever.

[baconpaul]

Hey @falkTX I came across a vstgui bug in #356 which has me, in #373 wanting to update to at least latest stable vst3sdk (or try it). Just an FYI and linking these issues.

Upgrading to latest dev branch is a bigger step.

[falkTX]

@falkTX, The problem is the lack of hard evidence, not whether you are right or wrong. You make claims without any supporting data.

I would guess that the problem is in the nutshell:

• GTK2 and GTK3 loops race in the same address space.

I think you are not understanding things here.
Mixing these toolkits and getting a crash is just a unavoidable technical problem.
I guess you are not used to these things as it is usually not something done on windows or macOS,
If 2 libraries export exactly the same function names and we try to load both in the same process, it results (at best) in undefined behaviour.

• If the plugins have their own process (like you can select from Renoise setting), then it should work. It is then just an application using GTK3.

Seems overcomplicating things for no real reason.
Running each plugin in its own process does not scale, with all the thread syncing and context switching.

[jarkk0sakkinen]

I did not know that GTK2 and GTK3 share the same symbol names as I've used neither, but I'm very well aware how the Linux dynamic loader works.

Renoise and Bitwig demo both have an option to run each plugin in its own process. Better to fix all the non-GTK related issues in that environment, and only after that do the switch. That way the mainline repository gets updated in smaller in smaller chunks.

When you speak about "overcomplicating" things you are utterly wrong. Even if we did the switch, when you want to run the plugin in its own process (when you develop, not as an end user), because that gives you easy way to attach gdb and strace to the process's PID.

I'm for the switch. For me the question is how to milestone things.

[falkTX]

I did not know that GTK2 and GTK3 share the same symbol names as I've used neither, but I'm very well aware how the Linux dynamic loader works.

Renoise and Bitwig demo both have an option to run each plugin in its own process. Better to fix all the non-GTK related issues in that environment, and only after that do the switch. That way the mainline repository gets updated in smaller in smaller chunks.

that seems reasonable.
reaper is also an option btw.

we can go one issue at a time.

When you speak about "overcomplicating" things you are utterly wrong. Even if we did the switch, when you want to run the plugin in its own process (when you develop, not as an end user), because that gives you easy way to attach gdb and strace to the process's PID.

I think we misunderstood each other here.
If you mean to run the plugin as standalone, then I agree completely it is the best way to test things.
I thought you were speaking of (in case of linux) always run the plugin as separate process (inside a daw). This would involve setting up IPC and shared memory, it is quite the effort to do vs just trying to get things to built with an updated library.

I have something that can help the debugging in my own host (carla).
We can run the plugin as if standalone, started via CLI, in a mode where only a single plugin is run.
carla's frontend uses Qt, but the backend does not, so a crash won't be triggered by GTK related things

[jarkk0sakkinen]

@kzantow, definitely did not mean that :) Carla does look a good testing tool for this. Definitely will give a shot at that.

@baconpaul, Have you tried the latest version with macOS or Windows? Maybe that could be used as one way to evaluate whether to do switch now or later. E.g. does your zooming code break etc.

If things work really well on Windows and macOS, maybe less conservative approach could be re-considered.

[baconpaul]

Need to be careful; there's two options here. Update to the latest stable version (which was my other issue) or update to the latest dev version (which is @falkTX's solution).

I think (maybe) the best thing to do if we decide to need the dev branch for linux is to add another submodule called vst3sdk.dev which points at the commit on the dev branch. Then we can move the pointers independently and linux could link against vst3sdk.dev and mac and windows could link against vst3sdk.

So I propose

1. Update the vst3sdk pointer to the latest stable to sweep in 6 months of changes. That's the separate issue #373. That won't fix the GTK problem @falkTX outlines but it may fix my zooming problems. That's "work" but I can find to look at it in the next week or two.
2. Use separate-process-space-hosts or non-gtk-hosts to see if we can get linux working with vst3sdk. Like "load the bitmaps" and stuff. That may involve writing the standalone app for debugging to be host free even. Maybe not.
3. Depending on the result of step 2, either
   
   
   
   1. package linux with a disclaimer that "you need to set the separate process flag and it only works in hosts X Y and Z and not A B and C" (if we get it working and that set is a big enough set to be credible) or
      
      
      
      
      
      1. add vst3sdk.dev as a second submodule and make the linux premake use that and debug and so on
      
      
      
   
   

Hows that sound to folks? I'm happy to whack away at #1 but it seems that you can do #2 now.

Again from your screenshot, @falkTX, I think the primary problem your UI is exhibiting is that non of SurgeBitmaps is able to load a bitmap.

And a question: is there any way to run vst2 or vst3 on linux now with stderr attached to the console? That could be super duper useful.

[jarkk0sakkinen]

Yeah, well isn't that what I originally proposed i.e. fix issues with process sandbox and then see where we are at with Linux?

[baconpaul]

Yes; with the extra color that my update to vst3sdk pointer won't address @falkTX's desire to try the dev version; and if we want to do that we should have two submodules. So the new version you ask about when you tagged me isn't the new version @falkTX is talking about.

[jarkk0sakkinen]

OK, fine with me.

[baconpaul]

Just FYI vst3sdk is at latest stable in the project now and the various namespace changes have been accommodated

[falkTX]

Nice, thanks for the great work!