MusE has probs loading synths, saving sliders

[Impostor]

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).

Commenting out the relevant "external UI" sections in plugin.ttl and manifest.ttl removes the choice for the kx GUI versions, so MusE loads the better option by default. (Is it better? Am I losing something here?)

Well, for Odin2, X11 is definitely better. Not only for the CPU load, but that weird behaviour I made a feature film out of (dragging the vector oscillator dot around for 20+ seconds making other controls move and turn on/off) doesn't occur here.

[Impostor]

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).

Try deleting the controller parameters for the (Surge) synths instead: lines 6166-7723 and 7848-9405.

Then, with the external kx UI blocked at least, the Surge GUIs open to what I assume are the correct patches Death to Gator, and Butter (@Tutorius please verify. If you made any adjustments to those patches those will get lost when deleting MusE's controller data, I presume), and play with clean sound. Also, they now respond to midi input and don't hang up anymore.

And, if you now resave the project, all those controller values are saved in the .med file again. But now I'm noticing a lot more hex values amongst them than I've deleted from the original file (266 vs 2)! So somehow, @Tutorius has created a hybrid project.

[Tutorius]

I have deinstalled the Muse4 that i self compiled and got back to the one that is inside Archlinux Pacman (on my main-system).
Reloading the Song "BassoBosso4" worked, but all sliders were to zero or at the lower bottom saving the song now and reloading worked well.

I think that the workaround for te thing with the naN's when adding controllers to sliders created a problem with loading the values.

[Tutorius]

Now my installed version on my main-system can't display the GUIs of calf-effects... My music-linux (also arch-linux) can do this...
Have to check whats the problem here...

[Tim E. Real]

Calf GUIs need GTK.

See our README about LV2 GUIs and GTK support.

Maybe your version of MusE was not built with the necessary GTK support compiled in ?
Or if it was, maybe try installing GTK runtime packages ?

[Tutorius]

It runs, i have installed the GIT-version now, and this works. GTK is and was allredy installed.

[Impostor]

It runs, i have installed the GIT-version now, and this works. GTK is and was allredy installed.

By the way, as Tim already noted, after replacing a plugin with a newer/older/other version, settings may or may not load correctly anymore either. I did some switching back/forth/sideways with Surge XT (newer<-->older//selfcompiled<-->prebuilt) and encountered problems with projects made with a different plugin version than currently installed. I wonder how many old projects I've already rendered "broken" with replacing various plugins with other versions...

[Tutorius]

Its getting somehow crazy...

I thought i have found a way to create and save my settings for the song... but i haven't.

I use two Odin's here, an unused Epiano, an Oberheim. Worked all well, then i added Drum-Gizmo as Drums.

This Drum-Synth uses recorded samles made by multiple mirophones. It has 16 channels (8 stereo) and i used 7 of these stereo-channels on 7 Audio-groups for mixing, one Audio-Group for setting volume of the Drum-result, and some Audio-groups for sending to reverb, Delay, Flanger.

The drum-related Aduio-groups are not saved (the position of the sliders).

The Calf-Delay and Calf-Flanger ar not correctly saved/loaded. I think they had been saved before adding Drums. Am not sure about that.

Bildschirmfoto zu 2023-09-01 00-10-08.jpg (175.39 KiB) Viewed 2101 times

[Tim E. Real]

Which version?
A version equal to or later than Aug 8 must be used for this to work properly.
Or else, a version older than several months ago - before I started tinkering with hex-floats.

[Tutorius]

Version is

MusE 4.1, (master | 4.1.0-161-g2088f4fa | 2023-08-18 16:06:16 -0400)

Its the git-version that Arch-Linux (AUR-Maintainer) puts in the AUR (Arch user repository)...
It worked all (even Calf-effects) until i added the Drum-Gizmo

File https://www.dropbox.com/scl/fi/t7y5qrir ... 9e77i&dl=0

Thing is: You need drum-samples to get Drumgizmo to work. I used DSR-Kit here

https://www.drumgizmo.org/wiki/doku.php?id=kits:drskit

Thanks for your support...

Hartmut

Which version?
A version equal to or later than Aug 8 must be used for this to work properly.
Or else, a version older than several months ago - before I started tinkering with hex-floats.

[Impostor]

I've reproduced @Tutorius' issue.

It seems it only happens with Drumgizmo, and it not only affects the project with Drumgizmo, but also every project you load after it (without closing MusE):

1. Create project Victim with (one or more) audio tracks. Adjust their volumes away from 0dB. Save.
2. Create project Vandal. Add a DrumGizmo track. Save.
3. Reload project Victim. Notice the volumes of the audio tracks being reset to 0dB.

(drumgizmo lv2 built from git today)

No wonder I could load Tutorius' previous projects fine: drumgizmo wasn't installed here.

[Tutorius]

Thats interesting...
Must have a look, had i used Drumgizmo for BassoBosso, too? Think so...
Now, is it a problem with inside Gizmo or is it possible for MusE-Developers to get it running?
Drum-Gizmo with its channels, up to 16 mono-channels, is something special.
Thanks for your testing, Impostor.

I've reproduced @Tutorius' issue.

It seems it only happens with Drumgizmo, and it not only affects the project with Drumgizmo, but also every project you load after it (without closing MusE):

1. Create project Victim with (one or more) audio tracks. Adjust their volumes away from 0dB. Save.
2. Create project Vandal. Add a DrumGizmo track. Save.
3. Reload project Victim. Notice the volumes of the audio tracks being reset to 0dB.

(drumgizmo lv2 built from git today)

No wonder I could load Tutorius' previous projects fine: drumgizmo wasn't installed here.

[Impostor]

Now, is it a problem with inside Gizmo or is it possible for MusE-Developers to get it running?
Drum-Gizmo with its channels, up to 16 mono-channels, is something special.

Neither the Carla multichannel plugins, nor the AVL multichannel drumkit plugins cause this issue. So it's not multichannel per se which causes it.

[Tutorius]

Hi together,

i just maked a test with the file:

I created a copy of the file, and edited it in a text-editor.
I deleted the complete "Custom-Data"-part for the Drum-Gizmo-Synth, between <customData> and </customData>.

And, what should i say, the file loads with all sliders loaded, an no problems loading the Calf-Effects.

Something in the CustomData-Section seems to bring the loading-routine out of order.

Hope that helps determine the problem.

PS: Its not possible to get DrumGizmo working then. It does not produce a sound, even when the samples are reloaded.

Greetings

Hartmut

[Impostor]

Hi together,

i just maked a test with the file:

I created a copy of the file, and edited it in a text-editor.
I deleted the complete "Custom-Data"-part for the Drum-Gizmo-Synth, between <customData> and </customData>.

And, what should i say, the file loads with all sliders loaded, an no problems loading the Calf-Effects.

Something in the CustomData-Section seems to bring the loading-routine out of order.

Hope that helps determine the problem.

PS: Its not possible to get DrumGizmo working then. It does not produce a sound, even when the samples are reloaded.

Greetings

Hartmut

And something related to DGizmo possibly remains in memory when it should be flushed upon opening another project, thereby interfering with that project's (and the next, and the next) settings.