Bug in LV2PluginFormat?

1

on line 5281 in LV2PluginFormat.cpp the getDefaultLocationsToSearch() returns

return { "%APPDATA%\\LV2;"
            "%COMMONPROGRAMFILES%\\LV2" };

which doesn’t make much sense since neither of the macros APPDATA nor COMMONPROGRAMFILES gets resolved, leading to a file search hickup.

Could we have that changed to someting more useful, like

FileSearchPath fsp;
       fsp.add(File::getSpecialLocation(File::windowsLocalAppData).getChildFile("LV2"));
       fsp.add(File::getSpecialLocation(File::globalApplicationsDirectory).getChildFile("common files").getChildFile("LV2"));

       return fsp;

please?

2

How are you testing this? What hiccup are you seeing? Are you sure the environment variables don’t get resolved?

Those paths are passed to lilv_world_load_all, which splits the paths by the path separator and then loads each individually. During that process, each path is passed to lilv_expand, which is a thin wrapper over ExpandEnvironmentStrings on Windows.

If this isn’t working for you, please provide the exact steps that you’re taking, the result you’d expect, and the actual result you’re seeing.

3

Be aware that, if you have a file named the same as the Users’ folder directory, in that directory, then there will be issues resolving %APPDATA% … imho it is better to change the API to use SHGetSpecialFolderPath (underneath File::windowsLocalAppData) as requested, since this method deals with Unicode better, and does not require parsing the environment string (shell escape) …

4

Hi reuk!

I guess I didn’t expect to get an answer to my post so I held it brief. Sorry for that. Anyway, I build the AudioPluginHost from the juce develop branch as of yesterday, using the VisualStudio2022 branch, didn’t change anything (except maybe for bumping up the C++ Language version to c++20 from c++2017). (By the way, why do you default to c++2017?)

I press “p” to come to the Plugin scan dialog, press Option, then Scan for new LV2-plugins
and get this (see pic), after some asserts in File::parseAbsolutePath(). As you can see the macros are still unresolved.

LV2 is, as I understand it, mostly a linux format, and on a Linux machine these macros might get resolved, but I’m on windows 11 and wanted to check out some LV2-plugins.

image

Of course this is no dealbreaker, you can set a new path manually, and thereafter the scan is succesful, but I felt it was a bit bugish anyway…

5

Thanks for reporting, the issue should be fixed on develop:

6

Well, it looks different now, but still not quite what I’d expected…

image

7

Oh, sorry it seems to work now. I just expected the paths would look more like the VST3 paths

image

But maybe this is the way paths should look like acc to Linux people. Case closed for me, anyway. Thanks for the update!