Hi. So... A few things...
Tutorius's files loaded OK here - at least as far as the sliders are concerned.
The values stored in the file are OK. Yes, some of the values are so-called 'hex-float' values.
However, Impostor appears to be correct in that whatever version was being used to reload the song
seems to be not the latest version, and therefore is still using the broken hex-float loading code.
The hex-float code was finally (hopefully) corrected once and for all on August 9.
It seems you've determined the problem. Hopefully all goes well.
I was going to suggest building current git master from source.
Because, if you were using the AppImage, I was going to suggest that maybe our AppImage file is not playing nice with target user distros.
But hopefully this seems not to be the case now.
This hex-float saga has been painful but necessary. You see, we were storing only decimal numbers before.
This was causing major headaches with graph points, plugin control values and so on, due to the rounding error
of using limited precision decimals. Values that were entered in a song were imprecise in the song file.
Hex-float eliminated this problem. (But caused all of these locale problems because of the locale-sensitive code I used.)
About the synths in your songs:
I get the same problem that Impostor sees: Massive CPU usage overload when either Odin-2 or Surge native UI is showing.
I am using pre-built versions.
I am unable to confirm this in QTractor since QTractor does not seem to have a CPU meter, and my system CPU monitoring tools
are strangely not showing me any CPU increases in either MusE or QTractor. Hm, how to test QTractor...
And... Your file BassoBosso kills my entire desktop!
Something odd going on.
Even after I edited the song file so that NO synth GUIs are to be shown, it still crashes my desktop.
Thus it does not seem to be related to synth native GUI + high CPU usage at all.
The song will only load if I tell MusE not to load any LV2 synths at startup (-2 option).
I have a suspicion that I will try to confirm later:
The binary 'customData' tag that is found in song files can be quite long and complex for synths, such as for Odin-2 and Surge.
It is possible that each of us is using slightly different versions of Surge and/or Odin-2.
I suspect that this binary data then becomes 'foreign' when sharing the song file with someone using different versions of Surge or Odin-2.
I suspect those versions don't like the custom data! Because the data format could be required to be different (new features etc.).
I suspect that a huge memory overload occurred, killing my desktop.
If this is the case, I fear we may have to start including the plugin version numbers in our song file,
so that upon loading a song, if we detect that a different plugin version is installed, we must abandon the custom data.
The plugin, in theory, should then continue to load OK, albeit with fresh initialization - as if freshly instantiated.
(We already do a similar abandonment of binary toolbar data - which stores user toolbar positions etc. - if we detect that an older
song file version is being loaded, to ensure that any new toolbars in the application will appear in the correct designed position at first.)
Impostor, we should make you an honorary member of the repo's project team, with all your fantastic help.
Thanks.
Tim.