VST3 Linux Inconsistently Working #514

baconpaul · 2019-02-06T00:12:38Z

Just here at the top of the thread

As of sep 2019

builds and runs in Steinberg editor host and reaper on linux
ui shows up as black in bitwig - the idle loop isn’t getting to the draw loop

baconpaul · 2019-02-08T02:31:57Z

Forever ago in #128 @asimilon told us the bundle needs to look like vst3sdk/doc/vstinterfaces/vst3loc.html on Linux so that's probably the issue here.

baconpaul · 2019-02-22T01:08:33Z

Hey OK that @asimilon document is right; we need to package it up like a mac bundle. When I do that I can get bitwig to recognize a VST3 then crash when it loads the plugin. But that's OK. Basically we can make a post-build script to build the .vst bundle.

VST3 on Linux requires a mac-like bundle, as described in the VST3 documentation vst3sdk/doc/vstinterfaces/vst3loc.html. These changes move VST3 from a raw dll to a bundle using the same techniques we use on macOS. Since we bake the images and so on into the bundle, the bundle contains only the DLL. With this change, bitwig studio will load our VST3, but it crashes if you open the UI and gives corrupted parameter names. But we are able to begin to debug. Addresses part of surge-synthesizer#514

VST3 on Linux requires a mac-like bundle, as described in the VST3 documentation vst3sdk/doc/vstinterfaces/vst3loc.html. These changes move VST3 from a raw dll to a bundle using the same techniques we use on macOS. Since we bake the images and so on into the bundle, the bundle contains only the DLL. With this change, bitwig studio will load our VST3, but it crashes if you open the UI and gives corrupted parameter names. But we are able to begin to debug. Addresses part of #514

baconpaul · 2019-02-22T01:57:50Z

OK great so if you build the steinberg editor host it can also load the .vst3 and gets a core dump in (of all places) xcb_generate_id from VSTGUI::ChildWindow. So clearly something amiss but also clearly our VST3 is now starting to work.

If you want to try this here's a set of commands

# first build and localy install surge vst3 using build-linux

mkdir VS
cd VS
git clone --recursive https://github.com/steinbergmedia/vst3sdk.git
mkdir build
cd build/
sudo apt-get install libsqlite3-dev
cmake ../vst3sdk/
cd public.sdk/samples/vst-hosting/editorhost
make
../../../../bin/Debug/editorhost ~/.vst3/Surge.vst3

and you'll get the loading starting, a window almost popping up, and this core trace:

#0  0x00007ffff6ace736 in xcb_generate_id () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#1  0x00007ffff54a094e in VSTGUI::X11::ChildWindow::ChildWindow(unsigned long, VSTGUI::CPoint) ()
   from /home/paul/.vst3/Surge.vst3/Contents/x86_64-linux/Surge.so
#2  0x00007ffff549c249 in VSTGUI::X11::Frame::Frame(VSTGUI::IPlatformFrameCallback*, VSTGUI::CRect const&, unsigned int, VSTGUI::IPlatformFrameConfig*) () from /home/paul/.vst3/Surge.vst3/Contents/x86_64-linux/Surge.so
#3  0x00007ffff549c77f in VSTGUI::IPlatformFrame::createPlatformFrame(VSTGUI::IPlatformFrameCallback*, VSTGUI::CRect const&, void*, VSTGUI::PlatformType, VSTGUI::IPlatformFrameConfig*) () from /home/paul/.vst3/Surge.vst3/Contents/x86_64-linux/Surge.so
#4  0x00007ffff545387d in VSTGUI::CFrame::open(void*, VSTGUI::PlatformType, VSTGUI::IPlatformFrameConfig*) ()
   from /home/paul/.vst3/Surge.vst3/Contents/x86_64-linux/Surge.so
#5  0x00007ffff538feed in SurgeGUIEditor::open(void*, VSTGUI::PlatformType const&) ()
   from /home/paul/.vst3/Surge.vst3/Contents/x86_64-linux/Surge.so
#6  0x00007ffff548e3a9 in Steinberg::Vst::VSTGUIEditor::attached(void*, char const*) ()
   from /home/paul/.vst3/Surge.vst3/Contents/x86_64-linux/Surge.so
#7  0x0000555555578771 in Steinberg::Vst::EditorHost::WindowController::onShow (this=0x5555559f5db0, w=...)
    at /home/paul/VS/vst3sdk/public.sdk/samples/vst-hosting/editorhost/source/editorhost.cpp:296
#8  0x000055555558bf72 in Steinberg::Vst::EditorHost::X11Window::Impl::handleMainWindowEvent (this=0x5555559f61d0, event=...)
    at /home/paul/VS/vst3sdk/public.sdk/samples/vst-hosting/editorhost/source/platform/linux/window.cpp:831
#9  0x000055555558ad62 in Steinberg::Vst::EditorHost::X11Window::Impl::<lambda(const XEvent&)>::operator()(const XEvent &) const (
    __closure=0x5555559f6440, e=...)
    at /home/paul/VS/vst3sdk/public.sdk/samples/vst-hosting/editorhost/source/platform/linux/window.cpp:632
#10 0x000055555558ccb9 in std::_Function_handler<bool(const _XEvent&), Steinberg::Vst::EditorHost::X11Window::Impl::init(const string&, Steinberg::Vst::EditorHost::Size, bool, const WindowControllerPtr&, Display*, const WindowClosedFunc&)::<lambda(const XEvent&)> >::_M_invoke(const std::_Any_data &, const _XEvent &) (__functor=..., __args#0=...) at /usr/include/c++/7/bits/std_function.h:302
#11 0x0000555555584167 in std::function<bool (_XEvent const&)>::operator()(_XEvent const&) const (this=0x5555559f6440, 
    __args#0=...) at /usr/include/c++/7/bits/std_function.h:706
#12 0x0000555555581639 in Steinberg::Vst::EditorHost::RunLoop::handleEvents (
    this=0x5555557f3960 <Steinberg::Vst::EditorHost::RunLoop::instance()::gInstance>)
    at /home/paul/VS/vst3sdk/public.sdk/samples/vst-hosting/editorhost/source/platform/linux/runloop.cpp:133

baconpaul · 2019-02-22T02:43:55Z

OK I just spent a bit of time debugging this. There's two basic problems

1: The runloop handling in VST3 on Linux is all done by having the processor vs editor split which we didn't do

Trying to fake it by whacking a runloop in place gives you a screen that doesn't repaint

The stack above happens because the runloop isn't initialized. You can fix that by making a runloop object and passing it down to the frame constructor in SurgeGUIEditor like they do in vst3editor.cpp but nothing actually runs that loop them.

So the trick @falkTX played with the aeff editor forcing loop for VST2 needs to happen here, but it needs to happen in conjunction with us embracing the VST3 editor/processor split as described in #164

baconpaul · 2019-02-22T03:07:21Z

Basically: @falkTX do you know how to hang a runloop in which repaints on vst3 like you did on vst2? If you can point at an example of that it would be lovely.

falkTX · 2019-02-22T07:45:46Z

I know almost nothing about vst3, cant help much here sorry.
But note that there almost no hosts or plugins that support vst3 on linux right now, so I do not think it is worth bothering.
The hosts that do support vst3 also support vst2, so surge will still work there.
I do not think we need to prioritize this.

At some point later, after initial linux release, I will do a DPF build (like vst2, vst3, etc but for DPF) which allows us to have fully-working standalone (via JACK), LV2 and legal vst2 (no more steinberg vstsdk).
LV2 and VST2 are pretty much the only formats that matter right now on Linux.

baconpaul · 2019-02-22T11:33:56Z

Ok thanks !

Look forward to the dpf build.

asimilon · 2019-02-23T13:04:29Z

Perhaps relevant : https://forum.juce.com/t/vst3-support-on-linux/31872/2

baconpaul · 2019-02-23T13:28:37Z

Thank you yeah that matches what I found exactly. Glad to know I’m not nuts.

But also the vst3sdk contains a runloop for the editor which configures itself pretty well but only if you have the editor / processor split. Since we don’t have that split, we need to c-n-p that editor runloop across (or somehow grossly double inherit or something).

baconpaul · 2019-03-07T22:55:35Z

Connect with #747

VST3 on Linux requires a mac-like bundle, as described in the VST3 documentation vst3sdk/doc/vstinterfaces/vst3loc.html. These changes move VST3 from a raw dll to a bundle using the same techniques we use on macOS. Since we bake the images and so on into the bundle, the bundle contains only the DLL. With this change, bitwig studio will load our VST3, but it crashes if you open the UI and gives corrupted parameter names. But we are able to begin to debug. Addresses part of surge-synthesizer#514 Former-commit-id: 2f4e1b3d64624c7b9c046af41ad004986be98b49 [formerly 47fe976] Former-commit-id: 19718ab93becd95200eac7b81fcaa914c6fa8883 Former-commit-id: 96557f18f5c1814dbde4dcab427c909b1fa5cc04

baconpaul · 2019-07-26T16:36:24Z

OK so here's some details

There's a platform/x11/FrameCOnfig which contains a shared_ptr IRunLoop
x11platform has a RunLoop::Impl which contains a static ::init method
That static ::init method is called by x11Frame in the constructor if the cfg->runLoop is not null
That is specified as an option to CFrame::open and is defaulted to =nullptr
In SurgeGUIEditor.cpp we call ->open with the 2 arg (so it is nullptr)
In the vst2 impl from falktx we do this

{
        frame = new CFrame (CRect (0, 0, 0, 0), this);
        getFrame ()->setTransparency (true);

        IPlatformFrameConfig* config = nullptr;
        X11::FrameConfig x11config;
        x11config.runLoop = &LinuxRunLoop::instance();
        config = &x11config;

    // printf("%s %p %p\n", __func__, frame, ptr);
        getFrame ()->open (ptr, kDefaultNative, config);

where LinuxRunLoop is an implementation of IRunLoop

so looks like VST3 could work if

We made SurgeVST3LinuxExtensions which copied/modified quite a bit of the vst2 runloop
Ifdef that ->open() for VST3 && Linux to grab a config and pass it in in SurgeGUIEditor
Spin up a thread to call an ::idle we add to our runloop implementation every 1/30th of a second or what not

Bumping this to 1.6.2 since I am tired of not having vst3 all platforms.

baconpaul · 2019-07-27T14:12:36Z

Nope. Too hard.

baconpaul · 2019-07-27T14:55:45Z

Cool. Steinberg::Linux::IRunLoop and VSTGUI::X11::IRunLoop

One is from the host side and the other is from the plugin sude

That's what all that stupid vst3editor code is bridging

This stuff is a nightmare, undocumented, and badly designed. I'll checkpoint as close as I got on a branch and then try again some other time.

This set of changes creates a VST3 which works in the Steinberg Demo edithost but does not work in BitWig quite yet. Addresses surge-synthesizer#514

This set of changes creates a VST3 which works in the Steinberg Demo edithost but does not work in BitWig quite yet. Addresses #514

baconpaul · 2019-08-10T15:19:07Z

Note to self; The linux vst2 calls idle from the synth idle. I wonder if I should do that rather than spin up a thread in the vst3 equivalent (see where I spin up the thread in the ::start in the vst3 support thing). Just for when I come back to that, saw it in the code and thought of it.

With this diff, the Limux VST3 works fine in Reaper. Still a crash on exit. Addresses surge-synthesizer#514

With this diff, the Limux VST3 works fine in Reaper. Still a crash on exit. Addresses #514

The LInux VST3 now cleanly shuts down its runloop, meaning it works completely in reaper linux. I have included it in the deb file for installation as a result. Addresses surge-synthesizer#514

The LInux VST3 now cleanly shuts down its runloop, meaning it works completely in reaper linux. I have included it in the deb file for installation as a result. Addresses #514 Addresses #937

tank-trax · 2019-09-13T00:23:55Z

as a reminder,

the Surge VST3 loads in Reaper and plays presets
in Bitwig it gives a black screen and can only play the loaded init

baconpaul · 2019-09-13T00:24:40Z

In bitwig you canauromste parameters and it responds correctly right?

baconpaul · 2019-09-13T00:32:35Z

Can automate that is. Sorry

tank-trax · 2019-09-13T01:21:27Z

what I notice is the VST3 does not display values but fiddling with the settings will produce changes in sound

here is what the VST2 looks like

and the VST3

baconpaul · 2019-09-13T01:24:30Z

Oh that’s super useful

I will bang my head against it one more time before we ship 1.6.2. Maybe I can find it.

baconpaul · 2019-09-14T19:38:51Z

Right so debugged some. Here's the difference

both reaper and bigwig are registering a file descriptor listener and 3 timers.
both reaper and bitwig are running the timers
but bitwig never calls us back in an event on the file descriptor
and bitwig unregisters 2 of the 3 timers twice

Hmm.

jpcima · 2019-09-27T20:25:01Z

The file descriptor is supposed to activate on Xcb events arriving, which in some particular cases poll() failed to notice.

For example under Lv2 idle callback, polling is never working at this call site. But you can get it working in a parallel thread. (which no doubt is somewhat racey, but then it works)

I guess something else may be consuming the events before that VSTGUI is able to poll them.

baconpaul · 2020-04-27T02:23:22Z

Just hitting this with some notes to self

As @tank-trax points out, in some hosts (Carla it seems) and sometimes in bitwig the menu doesn't work. This is also the case in the JUCE6 AudioPluginHost which is a super useful testbed

cmake -Bbuild -DJUCE_BUILD_EXAMPLES=ON -DJUCE_BUILD_EXTRAS=ON
cmake --build build --config Release --target AudioPluginHost
./build/extras/AudioPluginHost/AudioPluginHost_artefacts/AudioPluginHost

and then you can load a surge vst3. I see

menus don't work
close and reopen are not reliable and more improtantly
close leaves a ghost window around

baconpaul · 2020-05-27T14:11:25Z

So after a bunch of work with @tank-trax and many others, I'm now confident that the surge VST3 is basically fine at head in the nightly. One or two glitches here but those are separate issues. So I'm gonna close this

baconpaul added Linux Issues which only occur on Linux VST3 VST3 plugin related issues labels Feb 6, 2019

This was referenced Feb 6, 2019

Old-Surge feature: Folders with .wav -format wavetables used to be shown and were loadable from wavetable-context menu. #509

Closed

VST3 bundle layout #128

Closed

baconpaul mentioned this issue Feb 22, 2019

VST3 on Linux packages and installs #646

Merged

baconpaul changed the title ~~Linux VST3 doesn't work anywhere yet~~ Linux VST3 crashes because of a lack of runloop Feb 22, 2019

baconpaul added this to the 1.6.n milestone Mar 7, 2019

baconpaul mentioned this issue May 14, 2019

Surge crashes in menu animation (Linux) #813

Closed

baconpaul modified the milestones: 1.6.n, 1.6.2 Jul 26, 2019

baconpaul added a commit to baconpaul/surge that referenced this issue Jul 27, 2019

VST3 Linux Attempt

8a2ac41

This set of changes creates a VST3 which works in the Steinberg Demo edithost but does not work in BitWig quite yet. Addresses surge-synthesizer#514

baconpaul added a commit to baconpaul/surge that referenced this issue Jul 29, 2019

VST3 Linux Attempt

da709f4

This set of changes creates a VST3 which works in the Steinberg Demo edithost but does not work in BitWig quite yet. Addresses surge-synthesizer#514

baconpaul mentioned this issue Jul 29, 2019

VST3 Linux Attempt #979

Merged

baconpaul added a commit that referenced this issue Jul 29, 2019

VST3 Linux Attempt (#979)

514ed95

This set of changes creates a VST3 which works in the Steinberg Demo edithost but does not work in BitWig quite yet. Addresses #514

baconpaul modified the milestones: 1.6.2, 1.6.3 Aug 17, 2019

baconpaul added a commit to baconpaul/surge that referenced this issue Aug 18, 2019

Further Linux VST3 Progress

83f77fb

With this diff, the Limux VST3 works fine in Reaper. Still a crash on exit. Addresses surge-synthesizer#514

baconpaul mentioned this issue Aug 18, 2019

Further Linux VST3 Progress #1047

Merged

baconpaul added a commit to baconpaul/surge that referenced this issue Aug 18, 2019

Further Linux VST3 Progress

2a6271a

With this diff, the Limux VST3 works fine in Reaper. Still a crash on exit. Addresses surge-synthesizer#514

baconpaul added a commit that referenced this issue Aug 18, 2019

Further Linux VST3 Progress (#1047)

f24dc27

With this diff, the Limux VST3 works fine in Reaper. Still a crash on exit. Addresses #514

baconpaul mentioned this issue Aug 20, 2019

Linux VST3 Shutdown; and include in DEB #1067

Merged

jpcima mentioned this issue Sep 3, 2019

Add the LV2 plugin format #1093

Merged

3 tasks

baconpaul changed the title ~~Linux VST3 crashes because of a lack of runloop~~ VST3 Linux Inconsistently Working Sep 12, 2019

baconpaul mentioned this issue Sep 28, 2019

Surge can't load to Waveform10 #1223

Closed

baconpaul modified the milestones: 1.6.3, Currently Unscheduled Oct 9, 2019

baconpaul mentioned this issue Mar 5, 2020

Bitwig Linux VST3 GUI errors (vst2 crash resolved) #1572

Closed

baconpaul closed this as completed May 27, 2020

mkruselj removed this from the Currently Unscheduled milestone Jun 18, 2020

sjoerdvankreel mentioned this issue Mar 30, 2023

Building on Linux sjoerdvankreel/infernal-synth#2

Closed

bobobo199733 mentioned this issue Mar 5, 2024

surge - 2018-09-25 - 2019-02-28 bobobo199733/issues-metrics-tool-repo#9

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

VST3 Linux Inconsistently Working #514

VST3 Linux Inconsistently Working #514

baconpaul commented Feb 6, 2019 •

edited

Loading

baconpaul commented Feb 8, 2019

baconpaul commented Feb 22, 2019

baconpaul commented Feb 22, 2019

baconpaul commented Feb 22, 2019

baconpaul commented Feb 22, 2019

falkTX commented Feb 22, 2019

baconpaul commented Feb 22, 2019

asimilon commented Feb 23, 2019

baconpaul commented Feb 23, 2019

baconpaul commented Mar 7, 2019

baconpaul commented Jul 26, 2019 •

edited

Loading

baconpaul commented Jul 27, 2019

baconpaul commented Jul 27, 2019

baconpaul commented Aug 10, 2019

tank-trax commented Sep 13, 2019

baconpaul commented Sep 13, 2019

baconpaul commented Sep 13, 2019

tank-trax commented Sep 13, 2019

baconpaul commented Sep 13, 2019

baconpaul commented Sep 14, 2019

jpcima commented Sep 27, 2019

baconpaul commented Apr 27, 2020

baconpaul commented May 27, 2020

VST3 Linux Inconsistently Working #514

VST3 Linux Inconsistently Working #514

Comments

baconpaul commented Feb 6, 2019 • edited Loading

baconpaul commented Feb 8, 2019

baconpaul commented Feb 22, 2019

baconpaul commented Feb 22, 2019

baconpaul commented Feb 22, 2019

baconpaul commented Feb 22, 2019

falkTX commented Feb 22, 2019

baconpaul commented Feb 22, 2019

asimilon commented Feb 23, 2019

baconpaul commented Feb 23, 2019

baconpaul commented Mar 7, 2019

baconpaul commented Jul 26, 2019 • edited Loading

baconpaul commented Jul 27, 2019

baconpaul commented Jul 27, 2019

baconpaul commented Aug 10, 2019

tank-trax commented Sep 13, 2019

baconpaul commented Sep 13, 2019

baconpaul commented Sep 13, 2019

tank-trax commented Sep 13, 2019

baconpaul commented Sep 13, 2019

baconpaul commented Sep 14, 2019

jpcima commented Sep 27, 2019

baconpaul commented Apr 27, 2020

baconpaul commented May 27, 2020

baconpaul commented Feb 6, 2019 •

edited

Loading

baconpaul commented Jul 26, 2019 •

edited

Loading