VST3 builds have incorrect window position and causes DAW crash.

[Olnium]

VST3 versions of the plugins build without errors, however, upon loading in DAW, the plugin GUI is shifted down and to the right, leaving a blank grey border to the top and left of the plugin window. System then locks up and causes DAW to crash (Plugin crashes should be contained in Bitwig's plugin sandbox). See attached image. LV2, CLAP & VST2 build without errors and run without issue.

Build System: MinGW-w64 Build Target: Windows x64 Build Platform: Windows 11 Pro; AMD Ryzen DAW: Bitwig Studio

[sadko4u]

Fixed the incorrect position of the window in Bitwig.

Meanwhile, I tried to investigate the problem about why plugins hang up the Bitwig and it seems to be the following.

LSP Plugins use extensive VST3 message exchange mechanism: they form a message, fill it with content and send it to a peer. Both sides (Controller and Processor) can generate messages but Processor does it regularly for sending music position to the Controller or mesh data.

According to unknown reason, when this exchange occurs, the memory used by Bitwig starts to grow and finally it goes out of memory. When there is no message allocation and disposal cycles, the memory does not grow and all works fine except that UI does not show graphic data on a graph because did not receive it from backend.

Messages are reference-counted objects and I validated that the number of references to the message is proper (that means one) before it becomes disposed. But I'm not sure that it gets disposed or gets disposed completely/correct.

I suppose that it is someway related to the Bitwig because REAPER DAW that also is used for tests doesn't leak memory under the same conditions and it is a good reason to ask Bitwig developers about the proper implementation of the Steinberg::Vst::IMessage disposal.

[abique]

Hi @sadko4u, Maybe you're not doing the ref counting right.

Keep in mind that when you ask the host to create the Message object for you, it already has a refcount of 1.

#define FUNKNOWN_CTOR	{ __funknownRefCount = 1; }

[sadko4u]

@abique No. I do the refcounting in the following manner:

message.acquire();
uint32_t count = message.release();

lsp_trace("message references=%d", int(count));

[abique]

The interesting part is where you create the message.

[sadko4u]

Here is an example how the message becomes created and sent: https://github.com/lsp-plugins/lsp-plugin-fw/blob/f4a725c5366b5540b6e11155bdf6454111cc25b5/include/lsp-plug.in/plug-fw/wrap/vst3/impl/wrapper.h#L2999-L3054

The alloc_message function: https://github.com/lsp-plugins/lsp-plugin-fw/blob/f4a725c5366b5540b6e11155bdf6454111cc25b5/include/lsp-plug.in/plug-fw/wrap/vst3/helpers.h#L655-L671

[sadko4u]

@abique any ideas?

[sadko4u]

Hi @abique !

I did one more investigation and just replaced the Bitwig's implementation of Steinberg::Vst::IMessage by mine trivial one:

https://github.com/lsp-plugins/lsp-plugin-fw/blob/devel/include/lsp-plug.in/plug-fw/wrap/vst3/message.h https://github.com/lsp-plugins/lsp-plugin-fw/blob/devel/include/lsp-plug.in/plug-fw/wrap/vst3/impl/message.h

After activating this line the memory stopped leaking in Bitwig: https://github.com/lsp-plugins/lsp-plugin-fw/blob/f95db8ee03e646b5288d065a27d4ad3bbb24c637/include/lsp-plug.in/plug-fw/wrap/vst3/helpers.h#L674

So now I for sure consider the message exchange mechanism being broken in @bitwig.

@vosc @kurasu FYI

[abique]

I'll try it tomorrow.

[abique]

By the way do you have plans to update the arch package to bundle vst3 as well?

[sadko4u]

@abique I'm not responsible for packaging LSP for Arch Linux. I think @dvzrv is the right person to ask for it.

[sadko4u]

Added workaround that enables LSP's implemented Steinberg::Vst::IMessage interface for Bitwig Studio.

[abique]

I think I found the problem in Bitwig's code. About to test it.

[abique]

I've tried to build the plugin, but it didn't build vst3 it seems.

[abique]

Ah, there's a binary distribution here: https://sourceforge.net/projects/lsp-plugins/files/lsp-plugins/1.2.15/Linux-x86_64/

[abique]

Memory isn't growing here. I believe I've fixed it.

Thanks for the report :+1:, will likely be in 5.1.8.

[sadko4u]

Fixes and workarounds in 1.2.16!

[Olnium]

Window position confirmed fixed with latest release. Will monitor stability going forward.