Plugin scanning broken unless Helio is launched with an absolute path [Linux]

[jistr]

First, thanks a lot for making Helio!

TL;DR: On Linux, Helio should be launched as /usr/bin/helio for plugin scanning to work, not as helio (even if it is on $PATH). If this is not fixable, at least a clear error message should be shown on a plugin scan attempt when launched as helio.

Full description:

During plugin scanning, Helio is launching itself as a child process, and it cannot cope with being launched as helio (even though the helio binary is on $PATH). It seems Helio must be launched with an absolute path to the binary for plugin scanning to work (/usr/bin/helio when installed directly in the system, /app/bin/helio in a flatpak).

This assertion in JUCE fails when Helio is launched as helio:

https://github.com/peterrudenko/JUCE/blob/1246068b8ca75bc8181de6e1e3b6a87d9b7a44b5/modules/juce_core/native/juce_posix_SharedCode.h#L1100-L1101

That makes me think the bug is perhaps a JUCE limitation, i'm not sure if it's fixable in Helio itself. If it's not fixable, it would be good if at the beginning of a plugin scan attempt, Helio would check if it was launched with an absolute path, and if not, show an error message that the user should restart it using an absolute path. In the current state, a non-programmer has no chance of figuring out what is going wrong with the plugin scan.

This issue only prevents scanning plugins, but not using them. Once the plugins have been scanned and added to the config file, they seem to work fine regardless of how Helio was launched.

---

Broken example (--command=helio):

$ flatpak run --command=helio fm.helio.Workstation
Safe scanning: /app/extensions/Plugins/vst3/Dexed.vst3
JUCE Assertion failure in juce_posix_SharedCode.h:1100
Done scanning for audio plugins

$ flatpak run --devel --command=bash fm.helio.Workstation -c 'echo $PATH'
/app/bin:/usr/bin

Working example (--command=/app/bin/helio):

$ flatpak run --command=/app/bin/helio fm.helio.Workstation
Safe scanning: /app/extensions/Plugins/vst3/Dexed.vst3
Done scanning for audio plugins

[peterrudenko]

Thanks for bringing it up, the issue is definitely caused by attempting to scan plugins in a separate process and failing to launch one. This could be fixed by switching to single-process scanning, but that's less safer: many plugins tend to crash for whatever reasons, especially on Linux. Also JUCE seems to rely on getCurrentWorkingDirectory() method in many other places, so I'm wondering if it's possible in Flatpak to configure the sandbox for this app in a way that the working dir is set to where the executable is and you don't have to specify it manually in the command line?

[jistr]

Thanks for the reply, i amended the Flatpak so that we provide a full path to the executable ( flathub/fm.helio.Workstation#4 ). So Flatpak should not be hitting this problem anymore.

But users who install Helio normally and then perhaps launch it from command line or some script might still hit this problem, so i was thinking perhaps it's worth detecting the situation when Helio won't be able to launch itself as a subprocess and showing an error message. Currently it fails silently.

[nyxkn]

Confirming the issue exists, and that the fix of running with absolute path works just fine.

It's a straightforward workaround to apply on linux, but hard to figure out that that's what needs to be done - save for finding this github issue. Maybe a warning message when not run with absolute path (if it's possible to detect this)?