search

osxmidi / LinVst

Linux Windows vst wrapper/bridge
GNU General Public License v3.0
674 stars 41 forks source link

blue cat audio - some of the plugins don't load #130

Closed dreamcat4 closed 4 years ago

dreamcat4 commented 4 years ago

Was just trying these plugins, unfortunately some of them don't display anything and just hang / do nothing. I'm not sure the reason here.

Some of my other vst plugins are working for me. Others not.

https://www.bluecataudio.com/Products/Bundle_FreewarePack/

BC Free Amp

https://gist.github.com/dreamcat4/01840a2868bb7f1798efc0952b291f9f

BC FreqAnalyst 2

https://gist.github.com/dreamcat4/230cea0b6e03a7b5b8708ccc0dd0a74e

osxmidi commented 4 years ago

Try them out with TestVst and if they produce an error then Wine can't handle them at the moment (without an override maybe).

If TestVst is run from a terminal and the output is looked at, then sometimes there can be an unimplemented function error in some dll and that dll can then be overriden.

dreamcat4 commented 4 years ago

Thank you for this debugging suggestions. Will be trying TestVst program, and to gather more useful error logs in next few days - 2 weeks. And get back to you later about it.

keybreak commented 4 years ago

@dreamcat4 Which wine version though?

At least in Renoise for me those 2 worked perfectly with 4.15-staging (and up i suppose) https://keybreak.github.io/linux-vst-compatibility-list/ Search Blue cat

Here you can find more of test enviroments / winetricks used: https://github.com/keybreak/linux-vst-compatibility-list

dreamcat4 commented 4 years ago

Thanks @keybreak for these additional help. I will be also looking into a few days time.

My wine is currently set to tkg-4.6-x86_64. Here in lutris it requires a bit more efforts to install and switch over to the same wine version as you. With the wine environment I am using here.

dreamcat4 commented 4 years ago

Well I have to come back and let you know how i got on:

Tried (quite a few things) including installing 4.15 wine version, 5.1 wine version release from the proton-ge-custom releases (you should skip wine 5.0 as it does not work for some reason the installer setup.exe windows wont open).

"thread blocked timed out waiting for thread loader.c in bitwig studio" or something like that.

Then i read this reddit post somewhere that 'if you are using bitwig then use airwave'. So I finally tried airwave again and could finally notice to open the settings window (finally) to let me change the wineprefix folder etc. And get it to work. Since I had problem following the instructions before since they dont mention to first configure the wineprefix etc. Which is not taken from the env var $WINEPRIFIX it turns out.

After that I had airwave generate the .so file for Free Amp only and tried that in Bitwig... hey presto it works now.

I think this is enough for me to switch over to airwave for the time being. To get a better compatibility with bitwig than linvst. Not sure why this is but certainly some other guy had already previously noticed that hence the reddit comment I saw today. It solved my problem!

dreamcat4 commented 4 years ago

@osxmidi Hello again. I have been testing some more plugins with bitwig and eventually found that it ships with this commandline tool at /opt/bitwig-studio/bin/BitwigPluginHost64. Which allows me to execute with a test argument to test the .so file that is generated by LinVst.

So here is a successful output from that:

https://gist.github.com/dreamcat4/cdbbe0371275f0ae073e18640883ca8f

And the plugin GUI loads up / appears on the screen. Everything seems OK fine when the plugin is being invoked through that cmdline mechanism.

However when I try to add the same VST plugin in bitwig itself, the result is a failure to respond. Or a blocked thread etc. The plugin loading sequence gets stuck somehow. Like one side is waiting for the next communication or callback. Which never happens. I think perhaps this might be a failure from the bitwig side. See here is the log from bitwig main program, where it just keeps spinning ('this plugin is taking a very long time to load...')

https://gist.github.com/dreamcat4/2ad657748a1ab947f37a06d4627d5382

It would seem that when its called on the cmdline this happen:

PluginHost: Plugin needs to restart processing during initialization

Which is not happening, and not printed in the main bitwig logs. Instead bitwig does not realize to do that? It just waits and does not hear anything anymore. And perhaps on the plugin side is waiting also for bitwig to do the thing which it is not realizing it must do.

022f:err:ntdll:RtlpWaitForCriticalSection section 0x7bee8820 "../../../../proton/wine/dlls/ntdll/loader.c: loader_section" wait timed out in thread 022f, blocked by 0224, retrying (60 sec)

Almost as if there needs to be a restart command sent to the plugin. Which bitwig does not realize to send... is there anything we can do about this issue @osxmidi ? It seems to be a problem that is specific to the way bitwig loads the plugins. And is getting stuck here I can also see with some of the other plugins. Although I have not looked into those other ones yet.