You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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
The text was updated successfully, but these errors were encountered:
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?
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.
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 ashelio
(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 ashelio
.Full description:
During plugin scanning, Helio is launching itself as a child process, and it cannot cope with being launched as
helio
(even though thehelio
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
):Working example (
--command=/app/bin/helio
):The text was updated successfully, but these errors were encountered: