Hi!
First of all, thank you for all the work you've put into this project.
I've been following the development of this fork for a while, and after spending some time building and testing it on Linux, I think the project has a lot of potential. I'd like to contribute what I can from the perspective of a Linux user and help improve native support where possible.
I understand from your previous comments that Linux support isn't currently a priority, and I completely understand why. The Linux ecosystem is fragmented enough that maintaining native support can easily become a project of its own. My intention isn't to ask for official support immediately, but rather to provide feedback and patches that may make future Linux support easier if you decide to pursue it.
My Test Environment
- Zorin OS 18.1 (based on Ubuntu 24.04)
- Qt 6.6.3
- FluidSynth 2.3.4
- clang 18.1.3
- cmake 4.3.4
Issue 1: FluidSynth initializes with WASAPI on Linux
When launching MidiEditor, FluidSynth fails to initialize because the audio driver becomes wasapi.
Couldn't find the requested audio driver 'wasapi'
The Linux build of FluidSynth only supports drivers such as:
alsa
pipewire
pulseaudio
jack
oss
sdl2
file
After temporarily forcing the driver to pulseaudio, FluidSynth initializes successfully and MIDI playback works correctly.
I created a temporary workaround here:
LianSheng197@62a29bb
I don't believe this is the correct long-term solution, so I wanted to ask what architecture you would prefer. My workaround simply avoids the initialization failure so I could continue testing.
Issue 2: SF3 playback crash
I tested both SoundFont formats.
FluidR3_GM.sf2 works correctly.MuseScore_General_Lite.sf3 loads successfully, but playback immediately causes a segmentation fault.
The SoundFont is successfully loaded:
Loaded SoundFont "...MuseScore_General_Lite.sf3"
but playback crashes afterwards.
I haven't investigated this one deeply yet.
Packaging suggestion
If native Linux builds become available in the future, my suggestion would be to start with AppImage.
At this stage, AppImage keeps the development and debugging process simple without introducing sandboxing or additional packaging concerns. Once the application's runtime behavior, filesystem layout, and permission requirements are well understood, it would make more sense to evaluate a Flatpak package.
If you're interested in having native Linux releases in the future, I'd be happy to help maintain the AppImage packaging and test releases on Linux. I think it's better to establish a stable native build first, and only then consider Flatpak once the application's behavior and required permissions have settled.
I understand Linux support isn't your primary target, and I'm not expecting you to spend significant time on it. My goal is simply to reduce some of that burden where I can, so you don't have to solve every Linux-specific problem yourself.
I intentionally kept my current patch as a local workaround. Before cleaning it up into a proper PR, I wanted to ask for your thoughts on what direction you think would make the most sense.
Hi!
First of all, thank you for all the work you've put into this project.
I've been following the development of this fork for a while, and after spending some time building and testing it on Linux, I think the project has a lot of potential. I'd like to contribute what I can from the perspective of a Linux user and help improve native support where possible.
I understand from your previous comments that Linux support isn't currently a priority, and I completely understand why. The Linux ecosystem is fragmented enough that maintaining native support can easily become a project of its own. My intention isn't to ask for official support immediately, but rather to provide feedback and patches that may make future Linux support easier if you decide to pursue it.
My Test Environment
Issue 1: FluidSynth initializes with WASAPI on Linux
When launching MidiEditor, FluidSynth fails to initialize because the audio driver becomes
wasapi.The Linux build of FluidSynth only supports drivers such as:
After temporarily forcing the driver to
pulseaudio, FluidSynth initializes successfully and MIDI playback works correctly.I created a temporary workaround here:
LianSheng197@62a29bb
I don't believe this is the correct long-term solution, so I wanted to ask what architecture you would prefer. My workaround simply avoids the initialization failure so I could continue testing.
Issue 2: SF3 playback crash
I tested both SoundFont formats.
FluidR3_GM.sf2works correctly.MuseScore_General_Lite.sf3loads successfully, but playback immediately causes a segmentation fault.The SoundFont is successfully loaded:
but playback crashes afterwards.
I haven't investigated this one deeply yet.
Packaging suggestion
If native Linux builds become available in the future, my suggestion would be to start with AppImage.
At this stage, AppImage keeps the development and debugging process simple without introducing sandboxing or additional packaging concerns. Once the application's runtime behavior, filesystem layout, and permission requirements are well understood, it would make more sense to evaluate a Flatpak package.
If you're interested in having native Linux releases in the future, I'd be happy to help maintain the AppImage packaging and test releases on Linux. I think it's better to establish a stable native build first, and only then consider Flatpak once the application's behavior and required permissions have settled.
I understand Linux support isn't your primary target, and I'm not expecting you to spend significant time on it. My goal is simply to reduce some of that burden where I can, so you don't have to solve every Linux-specific problem yourself.
I intentionally kept my current patch as a local workaround. Before cleaning it up into a proper PR, I wanted to ask for your thoughts on what direction you think would make the most sense.