Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
jistr opened this issue Sep 26, 2023 · 2 comments
Open

Comments

@jistr
Copy link

jistr commented Sep 26, 2023

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
Copy link
Member

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
Copy link
Author

jistr commented Oct 6, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants