different versions of wine

[miomiomiomi]

Feature description

yabridge can already work with multiple prefixes which is a life saving feature for me, but if it could also use different versions of wine for different prefixes, that would be even better. i tried to replace my wine executable with

#!/bin/sh
echo "$WINEPREFIX"
if [ "$WINEPREFIX" = '/root/.wine'  ]; then
    /usr/bin/wine-staging-8.21 $@
else
    /usr/bin/wine-staging-10.5 $@
fi

but that did not work because i probably need to do that with every single executable that wine ships, and bcz yabridge probably directly calls /usr/bin/wine-staging-8.21by absolute path anyway, and even if worked, it still won't be reliable or good solution i guess, so i really hope to see multiple wine versions support somewhere in the future. thx for the project, literally wouldnt've ever become a musician without it

Anything else?

No response

[relaborn]

Yes, you're right that's extremely useful.

I've thought the same thing. There's no yabridge config item for that but yabridge-host.exe (adds .so to it's name for the process) is a shell script. I haven't tested this but you should be able to put your alternatives in there and change the PATH as necessary because you have access to the full path to the VST being run.

[microfortnight]

You're close, you need to override WINELOADER environment variable as described in #115

Here is a working example for such a script tailored to Bottles, but it works for regular prefixes too, see the commented out section at the bottom of the script: https://github.com/microfortnight/yabridge-bottles-wineloader

[mito551]

You're close, you need to override WINELOADER environment variable as described in #115

Here is a working example for such a script tailored to Bottles, but it works for regular prefixes too, see the commented out section at the bottom of the script: https://github.com/microfortnight/yabridge-bottles-wineloader

hey, I am using this script to use different wine version with different plugin combinations, but it doesn't seem to be doing what I expect it to, so either it's not working for me or I'm misunderstanding how to use it / what to expect.

I've tested out the script by forcing the wineprefix environment variable (see below), so the script is fine, but I'm not sure yabridge cares? I'm using the wine-10-embedding branch of yabridge if that matters at all.

$ /home/mitori/.local/bin/wineloader.sh --version
wine-9.21.r0.gf03d32e3 ( TkG Staging Esync Fsync )
$ export WINEPREFIX=/home/mitori/.var/app/com.usebottles.bottles/data/bottles/bottles/NeuralDSP
$ echo $WINEPREFIX
/home/mitori/.var/app/com.usebottles.bottles/data/bottles/bottles/NeuralDSP
$ /home/mitori/.local/bin/wineloader.sh --version
wine-10.11.r0.g3e94d124 ( TkG Staging Esync )

would greatly appreciate any help - one plugin (which has a standalone version that I tested out) is really misbehaving under 9.21, but runs great under 10.11

[microfortnight]

so either it's not working for me or I'm misunderstanding how to use it / what to expect.

Hey, you can verify which version of WINE is being used by following the DEBUG instructions found in the yabridge README, e.g. YABRIDGE_DEBUG_FILE=/tmp/yabridge.log bitwig-studio

If it doesn't work (system WINE is used), most likely the environment variable is not set or active. In my repository, I suggest using a systemd environment.d file, which works well on GNOME and is part of the freedesktop.org specifications. Depending on your desktop environment, exporting the environment variable may need to be done differently.

The expectation is that yabridge uses the WINELOADER environment variable to call the script instead of directly invoking a WINE binary. Since the WINEPREFIX variable is now set, the script can parse the Bottles configuration inside the prefix and locate the appropriate runner.

[mito551]

Hey, you can verify which version of WINE is being used by following the DEBUG instructions found in the yabridge README, e.g. YABRIDGE_DEBUG_FILE=/tmp/yabridge.log bitwig-studio

thank you so much, it took me entirely too long to figure out how I could check that. I ended up figuring out it wasn't the script that was wrong but that I've missed that I haven't moved the plugins into a new prefix with a different runner. thank you for your help!