Multi-instrument SF2s reset to instrument in index 0 in the UI when closing and reopening the plugin window in Reaper

[ghost]

Tested on Linux Mint 21.3 (Cinnamon desktop), Reaper 7.07, Fluida 0.9.2.

If you have a multi-insturment SF2 loaded in Fluida in Reaper, the instrument index in the GUI seems to mostly (but not always) revert to the one in index 0, even though the correct instrument keeps playing.

In the below video I'm using the "General User GS" SF2 ( https://schristiancollins.com/generaluser.php ), the "HonkyTonk" instrument. Most of the time when closing the plugin window and reopening, it reverts to the instrument at index 0 which is "Stereo Grand". Later in the video I show the same thing happening when choosing the instrument " Marimba". https://imgur.com/a/wABaFvM

Unlike the issue mentioned here, https://github.com/brummer10/Fluida.lv2/issues/18 , for me it does not show None as current path, it shows the correct path to the SF2 file.

[brummer10]

That's strange. I can't reproduce it. Here it works as expected. https://i.imgur.com/dyPEYP6.gif Do you use the pre-build binary or do you build it yourself? In case you build yourself, please update to the latest git version, as that is what I use here.

[ghost]

I'm using the latest Linux 64 bit binary from github, not custom compiled ( this one: https://github.com/brummer10/Fluida.lv2/releases/download/v0.9.2/Fluida.lv2-v0.9.2-linux-x86_64.tar.xz ) I extract the folder "Fluida.lv2" to "home/.lv2".

Reaper is flatpak version from Flathub, version 7.09. This may also matter: I'm using evaluation version of Reaper, not purchased, maybe this has an effect. I'm still deciding between staying with FL Studio on Windows or if I can move my workflow to Linux/Reaper.

Issue also exists with other soundfont files, like "FluidR3_GM.sf2".

You may also notice our Fluida UI text font seems to be different as well.

Any ideas?

[brummer10]

Fluida using the "Sans" font set. When that isn't installed it fail back to whatever it found. You may install the "Sans" font set from your package manager to get rid of this ugly font.

Also, could it be that you've a MIDI keyboard connected to Reaper which send MIDI clock? I know that some hosts have issues with LV2 atom ports when a MIDI clock is running. So it may be related to this issue https://github.com/brummer10/Fluida.lv2/issues/19

[ghost]

Have you tried the plugin on a flatpak version of Reaper? That may be the problem. The plugin may not be given access to the fonts folder of the system by the DAW. Because I seem to have the needed fonts:

There seems to be two solutions here:

1) Bundle a font file with the plugin itself AND/OR: 2) Have a hardcoded list of fonts to fallback to in case the plugin fails to find the one it wanted. As you can see if you let it fallback to whatever it finds first, the results can be pretty unusable.

Also, could it be that you've a MIDI keyboard connected to Reaper which send MIDI clock?

No I don't. I do have a MIDI keyboard but it's not connected right now and for about a month.

[brummer10]

Maybe you switch away from the flatpack version of Reaper. Why do you use it from flatpack anyway? I use as well the evolution version of Reaper, just download the binary, unpack it and run it from the download folder without any installation needed. I can't see any gain in using Reaper nor any other host at all, from flatpack. That is always a source of trouble which could easily be avoided.

[ghost]

I won't speak for myself but in general: Flatpaks are almost always up-to-date, quicker to install since available from most software managers, and in case of Reaper, require zero fiddling in command line and I believe updates from the Update Manager. But we can ignore all this:

The general rule in software development is you don't offer software that limits user's choices for an unnecessary reason. It's not for us to decide what is or isn't better to use. You can decide people should use your software this or that way, but at the end of the day you're artifically limiting usefulness of your software to a subset of your users and potentially reducing the number of users, and for what really?

Again, I'm not speaking for myself, I could just move to a non-flatpak version, even though I'd prefer not to. But all this may be avoidable if the dev lets the users make their own choices, I don't think this is a good road to go down.

[brummer10]

Good point. But, to be honest, I like to avoid to bake a font into a audio plugin. Even a hardcoded fallback list wouldn't help much here as you never know, in case of flatpack, what font may be available. On the other side, flatpack audio packages been known for a couple of issues which been introduced by the flatpack structure, jack connect issues for example, so the use of them in the Linux Audio world is very very limited. I'm pretty sure you'll find more issues with other plugs as well. It maybe useful for some quick first tests, but in the long run you wont use a flatpack as your audio host of choice.

[ghost]

I'm not sure what the issue is with including a freefont file, they seem pretty small.

I use Sfizz for SFZ and Carla plugins and can't say I've noticed any issues. But let's assume there were issues: you'd be not future proofing your plugin for issues existing today. Same with flatpak DAWs having very limited use: do we actually have any real statistical data and are the issues inherent issues that can't/won't be fixed down the line?

This is all assuming the issue doesn't exist on my system with the non-flatpak version. I'll need to get access to it and try first.

Even a hardcoded fallback list wouldn't help much here as you never know, in case of flatpack, what font may be available.

Reducing risk vs solving 100%.

[brummer10]

I'm not sure what the issue is with including a freefont file, they seem pretty small.

A plugin is loaded into the addressing space of the host. If, the same font is already loaded by the host, that may lead to symbol clashes. Hence, that is the reason why some stuff needs to be shared.

I'll need to get access to it and try first.

Yes please, try it. You'll surprised how easy Reaper makes it for you to use the binary.

[ghost]

A plugin is loaded into the addressing space of the host. If, the same font is already loaded by the host, that may lead to symbol clashes. Hence, that is the reason why some stuff needs to be shared.

Sounds like you can alter the name of the font file to avoid that.

Yes please, try it. You'll surprised how easy Reaper makes it for you to use the binary.

To clarify, I've used the Reaper binary from the site before, the advatnages of flatpak I listed still stand.

[brummer10]

I'm sorry, but that wont happen. I maintain a couple of plugs using libxputty as GUI back-end. Some of them needs a other fonts, for example to display Note names, back that all in, rename all the symbols, is, in my view a overkill.

You know that the issue could be solved easily as well by flatpack, by just add the font to the pack. So, it's not me who limit the user, it's the flatpack pack which limit your access to your system.

[ghost]

No I meant renaming the file name of the freefont file stored locally in the .lv2 plugin folder.

You can blame flatpak all you want but the end user experience is all that should matter.

And again, other VST/LV2 plugins seem to work fine. So we could discuss the APIs involved and the technology involved, but at the end of the day it wouldn't change the user experience with your software.

[brummer10]

No I meant renaming the file name of the freefont file stored locally in the .lv2 plugin folder.

That's not how this stuff works.

You can blame flatpak all you want but the end user experience is all that should matter.

Well, as I said, sooner or later you'll move away from flatpack hosting your DAW anyway. Surely a couple of plugs works without issues on flatpack hosted DAW's, but, your issues will be sum up as more you use it. It is as simple as cutting yourself from getting full access to your system.

[ghost]

Look, I kept my calm and engaged in this discussion but the bottom line is all you're doing here is trying to win an argument instead of making software better:

1) Other plugins work just fine, therefore this is not an inherent Flatpak issue. I've explain this already and still see you bringing it up. 2) It's not for you to decide if users should be using flatpak or non-flatpak versions of their DAWs. I've explain this already and still see you bringing it up.

Regular users will see a problem with the software that makes it unusable for them and move on to other options. They won't "bow down" to your way of using their PC/OS/DAW and changing their setup to work with your specific plugin. Expecting users to use sofware they way you personally prefer and to limit themselves that way is arrogant, impractical and completrely against the pilosophy of "free" sofware.

I don't see a need in contributing more feedback to a project where the dev finds this fine. We're paying you with our time and too many FOSS devs don't seem to understand this simple fact.

Good luck.

[brummer10]

I don't want to win anything. I said that this is a minor issue and that I don't going to fix it. I explained to you that implementing a font file in a plugin isn't trivial, but you ignore my claims.

It seems you misunderstood how open software works. I provide the source code. You have a issue. Fix it in the source and provide a pull request. Then I check it and decide if I would implement it or not. If not, you are free to maintain a fork with your own version which provide the fix you mean is useful. That is what Open Source is about. I'm not here to follow all your suggestions and fulfil your wishes.

However, as you seems to loos your interest in Fluida, I close this issue now.

[brummer10]

This issue is closed. Open a new one if you want, but here, your comments ain't make it true any more.