Moderators: MattKingUSA, khz, spamatica
I have put two of my songs that have probs with saving things into my dropbox.
First song has not saved any of the Audio-Group-Volume-Sliders, and needs "repair" of the two loaded Surge-Synths
https://www.dropbox.com/scl/fi/m210mlrl ... usiiw&dl=0
Second song does not save settings inside Calf-Flanger
https://www.dropbox.com/scl/fi/vbqa4y40 ... qqtuj&dl=0
Perhaps you can have a look at them, thanks a lot...
Tutorius wrote: ↑Sat Aug 26, 2023 12:37 pmSecond song does not save settings inside Calf-Flanger
https://www.dropbox.com/scl/fi/vbqa4y40 ... qqtuj&dl=0
The flanger on track 33 is the issue? Here it loads as follows:
Sliders on the audio groups load here as follows:
Tutorius wrote: ↑Sat Aug 26, 2023 12:37 pmFirst song [..] needs "repair" of the two loaded Surge-Synths
https://www.dropbox.com/scl/fi/m210mlrl ... usiiw&dl=0
On loading this song in get a warning that the project's sample rate is 88200 Hz.
Is that sample rate intentional? Maybe Surge goes crazy because of this? I can't get a sound out of it in this project at all (odin2 still works fine though, which is the only other synth installed here).
By the way, my MusE version:
*** Build info ***
Branch: master
Tag: 4.1.0-161-g2088f4fa
Commit timestamp: 2023-08-18 16:06:16 -0400
LV2 support: Enabled
DSSI support: Enabled
Native VST support: Enabled (using VESTIGE compatibility layer)
Wow, what a difference, look at the CPU usage when I open the Surge GUI:
With the self-built version the CPU load increases insignificantly on opening the GUI. But when opening the pre-built Surge GUI the CPU load increases to a whopping 70-80%!
These screenshots were taken in a new project, containing only an audio-out and a Surge audio track. Wasn't rolling or creating audio in any way: just opening the Surge GUI!
Crazy... I cant get the songs loaded, the values for the Audio-groups go to zero, the flanger has silly values...
Are you opening the project with the same MusE version as you've created it with? It really looks as if your MusE doesn't read hex values correctly (edit: although not all hex parameters are incorrectly loaded). I hate to invoke the L word, but, if you are running the latest version (see mine above), it could be locale related. Then you could try to set your system's locale to en_us (for numerical stuff at least), reboot, and retry...
I mean, just looking at the way the Calf Flanger parameters are loaded with your system, that's consistent with just the first digit after 0x.. in the hex values being loaded (1:=1, 100%, 0dB):
<control name="Min delay" val="0x1.99999ap-4" />
<control name="Mod depth" val="0x1.d0bd6ep+2" />
<control name="Mod rate" val="0x1.47ae14p-7" />
<control name="Feedback" val="0x1.509bf4p-1" />
<control name="Stereo phase" val="90" />
<control name="Reset" val="0" />
<control name="Amount" val="0x1.3a4ce2p+0" />
<control name="Dry Amount" val="0x1.8a884cp+0" />
<control name="Active" val="1" />
<control name="Input Gain" val="1" />
<control name="Output Gain" val="1" />
<control name="LFO" val="1" />
By the way, in that same project, all those audio groups which load with 0dB volume in your screenshot, except the one named FLANGER, do indeed have a volume of 0dB in the .med file, so they do load correctly. The exception is FLANGER, which has a value of -2.5 dB (0x1.7ff2224115d9ap-1) which is loaded as 0dB according to your screenshot....
Strangely, the volumes of other audio tracks do seem to load correctly in your screenshot, even though they are all in hex format too...Maybe the presence of an effect plugin with customized settings fucks up the loading of automation parameter "current values" of the entire track? That's something I can't find out here because everything seems to load correctly here. That's for you to troubleshoot.....
Hen i have a look at the audio-groups of a newly created track, it looks this way in the file:
Code: Select all
<AudioGroup>
<name>BAS-REV</name>
<record>0</record>
<mute>0</mute>
<solo>0</solo>
<off>0</off>
<channels>2</channels>
<height>24</height>
<locked>0</locked>
<recMonitor>0</recMonitor>
<prefader>0</prefader>
<sendMetronome>0</sendMetronome>
<automation>0</automation>
<gain>1</gain>
<controller id="0" cur="0x1.c9676c6fcaf2p-2" color="#ff0000" visible="0">
</controller>
<controller id="1" cur="0" color="#ffff00" visible="0">
</controller>
<controller id="2" cur="0" color="#0000ff" visible="0">
</controller>
</AudioGroup>
<AudioGroup>
<name>BAS-DEL</name>
<record>0</record>
<mute>0</mute>
<solo>0</solo>
<off>0</off>
<channels>2</channels>
<height>24</height>
<locked>0</locked>
<recMonitor>0</recMonitor>
<prefader>0</prefader>
<sendMetronome>0</sendMetronome>
<automation>0</automation>
<gain>1</gain>
<controller id="0" cur="0x1.22a9c2c9695e8p-5" color="#ff0000" visible="0">
</controller>
<controller id="1" cur="0" color="#ffff00" visible="0">
</controller>
<controller id="2" cur="0" color="#0000ff" visible="0">
</controller>
</AudioGroup>
This 0x1.22a0c29695e8p-5 means that after the dot "." this are the things after decimal pint in hex notation, after p is the exponent (2-exponent, i think)? Thats a format i never have seen before, and my system dows not to be able to read these, but is able to write...
Tutorius wrote: ↑Sun Aug 27, 2023 2:06 pmThis 0x1.22a0c29695e8p-5 means that after the dot "." this are the things after decimal pint in hex notation, after p is the exponent (2-exponent, i think)? Thats a format i never have seen before, and my system dows not to be able to read these, but is able to write...
I was thinking p-5 signifies just a left-shift of the dot with 5 places, but who knows? The format is not really relevant as long as it's written to and read from consistently.
By the way, what happens if you manually replace the dot by a comma?
I think i know what the problem is:
I have an other Archlinux-System on an other harddisk, and ther is the MusE installed thats in the Archlinux-repository. (Pacman-Version, not AUR-version).
And this version is able to load the slider-values as wished.
The version on my main harddisk was compiled after the thing with the non-working Midi-controllers. Link to thread below.
For me it looks as if the workaround for this problem created an other problem with loading of files that have audio-groups and altered slider-positions.
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.
Tim E. Real wrote: ↑Sun Aug 27, 2023 11:01 pmAbout 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.
Seems related to which native GUI option you choose:
With opening the native GUI I get two choices: kx or x11. With Odin2, only the kx GUI option leads to significant cpu load (to 35%). The X11 option leads to no obvious increase at all... Likewise with Surge (70% with kx, 8% with X11). Also with Pianoteq 7 (20% with kx, 6% with X11). AND also with LibreArp (35% vs 6%). That's every LV2 synth where I have the choice between kx and x11 UI...
(EDIT): With my self-built Surge lv2 (git-master) I do not get such a choice, b.t.w., and cpu load is even less.
What's the difference between those options anyway?
Tim E. Real wrote: ↑Sun Aug 27, 2023 11:01 pmImpostor, we should make you an honorary member of the repo's project team, with all your fantastic help. :wink:
Do I get a t-shirt with the MusE logo?
Tested tutorius's file:
Removed all customData tags. Set sampleRate tag to 44100.
No luck! Hm.
Tested my own song with 2 Surge and Odin-2 and all the effects he has.
Works fine.Hm.
Memory overloads with the given song... Pins memory usage meter. Terminal says "killed" after say, 20 seconds.
After several runs with that result, the desktop dies.
If I recall, the CPU meter did not stand out to me.
How'm I gonna track this one, eh? He he.
I'll try more process of elimination. Remove more stuff in the song. Examine the song more...
Yes, I remember yesterday after having fooled around with those projects, my swap partition was suddenly filled with something like 500MB (while I have 16GB RAM), and had a rather unresponsive system. My swap is almost never used normally. I thought it was maybe he made the Surge patch equivalent of a Klein bottle.