MusE saving Uhbik plugin state problem

[Impostor]

Recently I got me a shiny package full of nice effects: Uhbik from U-he (VST2). But, MusE has a problem with saving the correct settings:

If I load an instance of, say, Uhbik-A, select a factory preset, and save the project, the preset's parameters are not saved. Most like MusE didn't get the memo that parameters have changed in the first place.

If, and only if, I manually adjust the knobs in the GUI, then these changes are correctly saved in the project. And only those ones!

This means that if you want to save the state of any Uhbik plugin correctly in a project, you must make sure to have changed all of their adjustable parameters manually at least once, including the bypass button and whatnot!

Must be something in the communication between MusE and Uhbik that fails. Renoise saves and loads all of Uhbik's parameters correctly, as far as I've tried it.

Edit: it concerns all automatable parameters. There are some non-automatable* ones, like the feedback activation switches of Uhbik-D, which are saved correctly when their state changes via the loading of a preset.

*They aren't exposed in MusE's automation column at least.

[Impostor]

Additional info:

Now, if I load a Uhbik effect plugin as a synth on its own synth track, then changes induced by loading a preset do get saved! Alas, this is not really a feasible solution.

[Impostor]

So, since this miscommunication only occurs with Uhbik in MusE's effects rack, Uhbik probably does communicate the preset-loading-induced parameter changes to MusE, but MusE just doesn't listen?

Edit: After some confusion with Qtractor, it seems Qtractor behaves correcty, as does Renoise. (With Qtractor, changing an Uhbik preset didn't lead to a "project modified" message, but it does save the correct parameter values when saving the project with "save as.."

[GMaq]

Uhbik for Linux are a bit problematic in a few ways, I also bought them on sale and in Ardour they insist on using all of their surround outputs even if you load them on a stereo or mono track, the only recourse ids to wipe them off the track and manually delete the Audio ports they force-create. I regret the purchase although I'm extremely happy with Presswerk and Satin..

[Tim E. Real]

Problem has been observed.
Waiting to get some time to test other plugins... ie. does it happen with others? I'll try this weekend.
I looked briefly through the code.
I seem to recall I fixed a very similar problem recently. I thought this was fixed.

[Impostor]

Uhbik for Linux are a bit problematic in a few ways, I also bought them on sale and in Ardour they insist on using all of their surround outputs even if you load them on a stereo or mono track, the only recourse ids to wipe them off the track and manually delete the Audio ports they force-create. I regret the purchase although I'm extremely happy with Presswerk and Satin..

If you right-click on the info display you get a channel-select menu. Maybe that helps?

It seems Uhbik doesn't set the number of channels, but the host does: "This default mode tests the number of output channels, then switches to 1.0,2.0, 3.0, 3.1, 5.0, 5.1, 7.0 or 7.1 accordingly." (from the Uhbik user manual, about "auto/surround" mode)

[Impostor]

Problem has been observed.
Waiting to get some time to test other plugins... ie. does it happen with others? I'll try this weekend.
I looked briefly through the code.
I seem to recall I fixed a very similar problem recently. I thought this was fixed.

I always used Calf for effects, whose preset menu isn't available in the plugins (only available in the standalone Calf Effect Rack). I'll try to find some others..

[Impostor]

Problem has been observed.
Waiting to get some time to test other plugins... ie. does it happen with others? I'll try this weekend.
I looked briefly through the code.
I seem to recall I fixed a very similar problem recently. I thought this was fixed.

It seems to be a regression in MusE 4.2: Using the 4.1 appimage, it works correctly as far as I can discern (be sure to use the proper "patches" menu to change presets. Doing it by clicking the GUI display tends to crash this version of MusE).

[glowrak guy]

The vst3 Uhbik is disabled by default, due to some Steinberg code insanities, mentioned in a readme in the installer folder.
Explains the rather spectacular crashes one might have when loading the linux vst3
I gave the terminal output to the U-he linux forum, but the readme mentions 'fixes' are too expensive in man-hours, to do any time soon.

The vst2 version seems to work fine in Reaper . But if you click the button '2/8 in+out' above the Uhbik logo, you get a matrix to connect things, but the channel reassignment accessed by right-click in the 'info-display' doesn't seem to happen, so I mentioned that also at the U-he forum post

https://www.kvraudio.com/forum/viewtopi ... 5#p8796425

Uhbik-outs.jpg (147.98 KiB) Viewed 4610 times

[Impostor]

s, but the channel reassignment accessed by right-click in the 'info-display' doesn't seem to happen,

The right-click menu is apparently only for selecting which of the eight channels get processed by the plugin. The rest are just pass-through channels. At least that's what I make of the manual.

[Impostor]

The vst3 Uhbik is disabled by default, due to some Steinberg code insanities, mentioned in a readme in the installer folder.
Explains the rather spectacular crashes one might have when loading the linux vst3 :shock:

Did a quick test with Uhbik-A vst3 in Renoise: seems to work fine, including automation. My VST3_ReadMe only mentions midi-learning not working...

[Tim E. Real]

U-he Uhbik-A vs. TAL Reverb-4, as effects in a MusE effect rack:

Uhe-vs-TAL-effect-param-saving.jpg (220.76 KiB) Viewed 4529 times

The U-he does not update our generic UI when changing patches and thus MusE saves incorrect parameters in the song.
The TAL does update our generic UI when changing patches and thus saves everything correctly.
It seems the U-he does not inform us when patches change, or else we're not listening for the right information ?

If the U-he is loaded as synth track, it still does not update our generic UI when changing patches, but it saves parameters OK.
I see some code differences between the effect and synth song-saving code.

I'll try to at least fix the song saving bug.
As for the other U-he behaviour, not informing us of patch changes and not updating our generic UI,
I'll take a look but a fix might not be possible...

[Impostor]

If the U-he is loaded as synth track, it still does not update our generic UI when changing patches, but it saves parameters OK.

Same thing happens with the 4.1 Appimage with Uhbik in the effects rack: Generic UI is not updated. But that doesn't seem to negatively affect*) the working of the plugin, nor the saving/loading of plugin parameters.

*)Edit: I'll have to take that back. with Uhbik-A, even though most parameters are saved/loaded correctly, there are one or two, depending on the preset I select, which are loaded with the wrong value:(
The MusE 4.2 synth track behaves better, b.t.w. but I'm still comparing screenshots.

Anyway, in Renoise, and also in Qtractor, the generic UI is immediately updated when changing presets in the Uhbik GUI, so something is definitely being communicated.

[Impostor]

Seems that Uhbik is not the only plugin where the generic GUI isn't updated when switching presets:

This also affects Pianoteq 7&8 VST, and also Pianoteq 7 LV2, Dexed VST and LV2.
Some other synths are unaffected: OBXD VST, Odin2 LV2, Vaporizer VST.

[Tim E. Real]

Just a heads-up.
I am working on this issue.
Unfortunately it also requires several other tweaks, fixes, and re-writes,
all of which will make things "better".
All for now...