Add Carla support for windows

[Gabrielxd195]

In the update notes of lmms 1.2.0 rc7 mensiona that carla was implemented in mac systems. but I wonder if in the future it will also have support for windows ?, since lmms and carla have support for windows, and carla has a wide support for multiple plugins and soundfont. It would be quite useful to open sfz, vst files and play live. in windows I do not know a daw or a free plugin that imports archvos sfz, or emulate lv2 files like calf plugins (although I do not know if it would be possible to open lv2 files in windows), but for windows users having carla within lmms would be great .

I repeat my question:
Will lmms-carla support for windows?

[tresf]

Since fd77c79 (1.2.2 and higher) we have unofficial Carla library building for Windows which we intentionally place into plugins\optional to prevent it from loading.

If moved to plugins, the plugins will list as available, but they won't work.

Looking at the plugin code, we normally configure the resources folder, which depends on where Carla is installed. We skip this logic entirely for Windows so I don't think it will ever find the resources folder.

What I'm even more confused about is which resources folder we'd be using? The Carla Windows build shows the following resources folders...

Carla_2.2.0-win64\Carla.vst\resources
Carla_2.2.0-win64\Carla.lv2\resources

... both of which contain copies of carla-plugin.exe.

@falkTX does the Windows Carla build contain what we'd need or is there some additional support built into the MacOS and Linux builds that isn't yet available in the Windows version of Carla?

[falkTX]

The Carla.exe is a zip file, it contains the full things inside.
But until Carla has a real installer, the location will just be random. So if you want Carla and LMMS stuff on Windows, so you are going to need to have Carla shipped with LMMS (so it can find it)

[tresf]

@falkTX are you saying that the only thing preventing this from working is adding a reliable search path on Windows to resources? If so, does it not matter which directory we use (e.g. lv2 versus vst?)

[falkTX]

I am saying that carla has no reliable path where it will be installed, because there is no installer.
But if you ship Carla, yes, nothing prevents this from just working.

On the future v2.3 a new library is built that hides away the standalone stuff from carla (mainly device handling), leading to possible less symbol conflicts.

[tresf]

you are going to need to have Carla shipped with LMMS (so it can find it)

I'm sure many users would love this although it would drastically increase the LMMS download file size (from ~35 MB to ~280 MB) so this is probably a better conversation for Discord.

[falkTX]

not 280Mb, carla has duplicated files in the windows download because of the lack of symlink support in windows. so the resources are duplicated for standalone, lv2 and vst.
but yes, size increases.

the real best would be to build carla together with lmms, but pyqt will make that a challenge.

[tresf]

I am saying that carla has no reliable path where it will be installed, because there is no installer.

We have this issue on MacOS as well. At runtime, we get the path to LMMS.app and look adjacent (e.g. ../Carla.app/Contents/MacOS/resources/carla-plugin). I agree that a lack of Windows installer makes this unpredictable, but I'm still confused as to which version to use Carla.lv2/resources, Carla.vst/resources or if we should be doing something different.

[falkTX]

You can use the lv2 or vst resource folder, does not matter as they are exactly the same files.
So copy one of those folders to somewhere LMMS can find it I guess, and part of the installation.

Carla will then use resources\carla-plugin[-patchbay].exe for the gui

I think this ought to work...

[tresf]

@falkTX it appears [lib]carala_native-plugin.dll may be missing from the Windows version. We have the dummy version that we build, but that's just a stub we remove from the Mac and Linux installers.

For comparison, the MacOS version is located at Carla.app/Contents/MacOS/libcarla_native-plugin.dylib. How would we go about obtaining this file for Windows?

[tresf]

@falkTX it appears [lib]carala_native-plugin.dll may be missing from the Windows version. We have the dummy version that we build, but that's just a stub we remove from the Mac and Linux installers.

I think I found it as carla.dll. Running some experiments now...

[tresf]

As of tresf@1cce006, I can get the plugin to load simply by adding Carla.lv2 to my path, but the Show GUI button doesn't work, throwing the following exception:

cx_Freeze: Python error in main script
Traceback (most recent call last):
   File ".\lib\__startup__.py", line 14 in run
   File ".\lib\Console.py", line 26 in run
   File ".\lib\carla-pluglin-patchbay.py", line 22 in <module>
ImportError: DLL load failed: The specified procedure could not be found

I have a feeling it's Python related, but I'm not sure where. TestUI loads just fine if I double-click the carla-plugin-patchbay.exe directly.

[falkTX]

That library is missing on the Windows builds simply because I did not think it would be useful to ship with.
I can do a build later today that provides these.

Why do you add the lv2 dir to the path?

I think the issue here might be either that the new process does not look into the resources dir for the dlls (like qt stuff) or some dll is conflicting with LMMS provided ones.
So I recommend to try to get the CarlaVST plugin working in LMMS first, and only continue once that is shown to work.
It is a shell plugin, so if that is not good I can provide the single-plugin vst dll instead

[tresf]

Why do you add the lv2 dir to the path?

Because it allows LMMS on Windows to find carla.dll without hard-coding a path.

[tresf]

So I recommend to try to get the CarlaVST plugin working in LMMS first, and only continue once that is shown to work.

Please pardon my ignorance, are you asking if I can load Carla using Vestige? If so, how? CarlaVstFxShell.dll loads and shows your name in the plugin details, but Show GUI doesn't work there either. Is that what you were asking me to test?

[tresf]

That library is missing on the Windows builds simply because I did not think it would be useful to ship with.
I can do a build later today that provides these.

Thanks. If the library is the same as carla.dll, that's OK. I've successfully switched (my own fork) to look for it by that name, but the aforementioned error occurs.

[falkTX]

So I recommend to try to get the CarlaVST plugin working in LMMS first, and only continue once that is shown to work.

Please pardon my ignorance, are you asking if I can load Carla using Vestige? If so, how? CarlaVstFxShell.dll loads and shows your name in the plugin details, but Show GUI doesn't work there either. Is that what you were asking me to test?

Yeah, that is what I am suggesting. do you get the same error when clicking show gui, or not?

[tresf]

Yeah, that is what I am suggesting. do you get the same error when clicking show gui, or not?

Not interactively, no although it may be erroring with it silently, Windows is sort of terrible at telling me those things. Wine's better, I could see if there's something on the terminal.

[falkTX]

I think that might be just LMMS not support vst shell plugins.
In order to keep carla size from growing even larger, I only use the vst-shells on windows so that 1 plugin serves the 6 variants of rack and patchbay 2, 16, 32, etc.

Attaching here the non-shell plugin version. place it in the carla.vst folder and see if that works.
CarlaRack.zip

[DomClark]

See #5542.

[falkTX]

ah okay then it makes sense. btw, speaking of windows... LMMS does not enable JACK support under Windows, correct?
with the latest jack2 release, I mean as of today, see https://jackaudio.org/news/2020/10/15/jack2-v1915-release-and-current-status.html, windows builds are supported again. so would be nice to have this too. that will be a separate ticket yes, but not sure if already implemented or not

[tresf]

that will be a separate ticket yes, but not sure if already implemented or not

We have a thread about it here. #2136 Probably doable, we use weakjack, but I'd have to dive more into it. Edit: Done #5716

See #5542

Hmm.. Ok. Assuming Carla as a VST is a no-go, I won't waste any more time on that endeavor. If that changes, let me know.

I think the issue here might be either that the new process does not look into the resources dir for the dlls (like qt stuff) or some dll is conflicting with LMMS provided ones.

Back to this... Interestingly, Carla seems to fire up partially on Wine (The UI is black, so perhaps it's a DLL conflict as you suspect?). Ideas welcome. I can also test with MSYS2 on native Windows in hopes I'll get some form of console output.

wine cmd
C:\>PATH=%PATH%;Z:\home\ubuntu\Desktop\Carla_2.2.0-win64\Carla.lv2  
C:\>"C:\Program Files\LMMS\lmms.exe"
# Drag Carla from sidebar, click "Show GUI" button
C:\>Trying to start carla-plugin using "Z:/home/ubuntu/Desktop/Carla_2.2.0-win64/Carla.lv2/resources\carla-plugin-patchbay.exe"
Carla 2.2.0 started, status:
  Python version: 3.7.4
  Qt version:     5.13.1
  PyQt version:   5.13.1
  Binary dir:     Z:\home\ubuntu\Desktop\Carla_2.2.0-win64\Carla.lv2
  Resources dir:  Z:\home\ubuntu\Desktop\Carla_2.2.0-win64\Carla.lv2\resources
ALL OK!

[tresf]

It gets stranger... using msys2, Carla loads just fine. Ugh, why? :D

owner@TRESFINOCCHDEE9 MSYS ~
$ PATH=$PATH:/c/Users/owner/Desktop/Carla_2.2.0-win64/Carla.lv2/
owner@TRESFINOCCHDEE9 MSYS ~
$ "c:\Program Files\LMMS\lmms.exe"
Trying to start carla-plugin using "C:/Users/owner/Desktop/Carla_2.2.0-win64/Carla.lv2/resources\carla-plugin-patchbay.exe"
ALL OK!
Trying to start carla-plugin using "C:/Users/owner/Desktop/Carla_2.2.0-win64/Carla.lv2/resources\carla-plugin.exe"
ALL OK!

[falkTX]

Carla grabs the pyqt dlls from msys2, that might be why :)

[tresf]

Carla grabs the pyqt dlls from msys2, that might be why :)

Hmm... This is a fresh msys2 environment and I don't think msys2 ships with pyqt at all (I believe the installer's written with Qt Installer Framework, but I don't believe any Qt dlls are exposed to msys2 processes unless I explicitly pacman them).

[falkTX]

you got a libgcc, libstdc++, libwinpthread from the start, correct?

carla's current windows build still has those because of msys2.
but I plan to build pyqt myself, python is just a pain to cross-compile with mingw (as it is not officially supported)

[tresf]

you got a libgcc, libstdc++, libwinpthread from the start, correct?

They're not on my path, but that's true for all environments (Wine, msys2, etc).

If I use the same technique in CMD as I did with msys2, and use PATH directly in the terminal, Carla works. This is working fine (where as the environmental variable isn't).

Is there anything you can think of in the carla executables that would be modifying the path?

C:\Users\owner>PATH=%PATH%;C:\Users\owner\Desktop\Carla_2.2.0-win64\Carla.lv2

C:\Users\owner>"c:\Program Files\LMMS\lmms.exe"

C:\Users\owner>Cannot load library C:\Program Files\LMMS\plugins\papu.dll: The specified procedure could not be found.
Cannot load library C:\Program Files\LMMS\plugins\OPL2.dll: The specified procedure could not be found.
Cannot load library C:\Program Files\LMMS\plugins\spectrumanalyzer.dll: The specified procedure could not be found.
Trying to start carla-plugin using "C:/Users/owner/Desktop/Carla_2.2.0-win64/Carla.lv2/resources\carla-plugin-patchbay.exe"
waitForClientFirstMessage() - read failed

C:\Users\owner>
C:\Users\owner>Trying to start carla-plugin using "C:/Users/owner/Desktop/Carla_2.2.0-win64/Carla.lv2/resources\carla-plugin-patchbay.exe"
ALL OK!

[falkTX]

maybe there is a way for windows to change the path where it loads libraries from? I have the same issue with carla-lv2 + ardour on windows, but there the error is more clear.
when starting a new process (as done for carla UI) it would be nice to clear up the "current path" of that new process to be the one of the executable.

[tresf]

It's the working directory. Hell, that was sneaky... You're right, DLL conflicts..

1. When I start LMMS from the Desktop shortcut, it sets the working path to C:\Program Files\LMMS which contains some of the DLLs needed by Carla, but not the right copies. 🤦
2. When I start LMMS from CMD, it sets the working path to C:\Users\owner, which does not contain the DLLs needed by Carla.
3. Windows takes working path first, so in the event that LMMS is started out-of-directory, Carla's OK. In the event LMMS is started normally, Carla won't start.

So the workaround is to wipe-out the "Start in" value from our shortcut (or better, find a way to clobber this when launching Carla).

[falkTX]

oh very interesting!

an ugly hack for now just for testing is to change the CWD when showing carla gui (revert back after function is done)

[tresf]

ugly hack for now just for testing is to change the CWD when showing carla gui (revert back after function is done)

Would this be internal to Carla? I think LMMS sees it as the same process, so we have no easy way to modify the environment once LMMS is launched. If it were a remote process, I think we'd be able to control the environment via QProcess, etc... but as a native plugin, I don't know where we'd start.

[falkTX]

I mean in LMMS, for now. (I have to find a way to nicely do this in Carla yes, but while we are testing Carla+LMMS on Windows a small hack in LMMS is the fastest way)

basically switch the current working directly (whatever the win32 API for that is..) before opening the carla ui.
I think that should do the trick

[tresf]

before opening the carla ui. I think that should do the trick

Yeah, that seems to work. I'll add it to the patch.

[tresf]

PR opened. For anyone that wants to test it out, you can snag it here: https://github.com/tresf/lmms/releases/download/experimental/lmms-1.2.3-729+gb64fe8e7c-mingw-win64.exe