How to save plugin settings

Ardour 7.4 on Linux. Using lv2 version of Sfizz for playback of SFZ instruments. Ideally I’d like to load up an SFZ instrument, tweak how the MIDI cc settings affect playback of samples in the plugin interface and then save that as a preset so it loads with the session. Is this possible? I am able to “Save a new preset” but on reloading the session those settings don’t load. And even manually loading that new preset doesn’t load the settings I saved. The “save the current preset” button is grayed out.
I even have a situation where a MIDI control which is coded in the instrument text file to be 0 loads as 127.
Might I be missing something obvious or should I report it as a bug?

What you describe does sound like a bug. We do need a more information to determine where that is.

  • Which version of sfizz are you using?
  • Is the state of other LV2 plugins restored correctly?
  • Does it work if you use sfizz as VST3 plugin (instead of LV2)?

Are you perhaps using a distro provided flatpak version of Ardour?

There was a bug that state save/restore that was only fixed earlier this year:

and another issue when using flatpak’ed version.

Hi Robin. Thanks for the quick reply.

I have some of that info but not all of it.

I’m on AVLinux, using Ardour 7.4.0 downloaded from Ardour site. No flatpaks involved.

I was running the develop version of sfizz until earlier this month when the project was divided into 2 repositories. The updated version wasn’t available on OBS so I’m now running 1.2.0 which I understand is an older version. I’m out of my comfort zone when it comes to building from source but I’ll have a go compiling the latest version and report back.

But this is a longstanding issue; it was the case with the develop version back in April - I made a note at the time and the fix you mention would have been implemented by then. In any case it’s become more of an issue for me since then because of changes in my workflow.

However to answer your other points;

The only other lv2 instrument plugin I’m familiar with is setBfree. There’s no need there even to create a preset. Ardour just seems to save the state the plugin is in at the time of saving, and that is restored when the session is opened. But also yes, if a new preset is created then simply selecting that preset does recall it correctly. But you already know that :wink:

The VST3 version works better in this respect. So it doesn’t load the settings of the saved preset but rather loads the default settings of the instrument concerned. But clicking on the name of the preset in the menu does restore the settings I’ve saved. That’s great and I can work with that.

However the problem with the VST3 version of sfizz is the same as I raised in a question back in January concerning DecentSampler; there is no “Plugin Provided” mapping of CC numbers to parameters. So it’s really fiddly and complicated to set up midi automation. However two of the many positive things about VST3 sfizz (and DS) are that if you set up the automation correctly then moving the slider in the automation lane is reflected in movement in the GUI of the plugin. Likewise the effect of events drawn into the automation lane are, during playback also reflected in movement in the GUI of the plugin. (There is however the weird situation where events drawn in the automation lane do NOT during playback show up in the slider of the automation lane.)

The lv2 version of sfizz OTOH does have a “Plugin Provided” mapping of CC numbers. This makes setting up automation so much quicker and easier. The automation does work, but DOESN’T show up in the plugin GUI.

Reading all of that back it does sound like it’s something I should really be posting on the sfizz discord as much as on here.

Any other suggestions much appreciated. I’ll post back after compiling the newest version of sfizz.

For a second opinion, you could run sfizz in another LV2 host:
LV2 presets are shared between hosts (saved to ~/.lv2)


The sfizz team are working on making a Linux version of 1.2.1 available through OBS asap. I’ll update when I’ve installed it.

In the meantime I thought I’d try making some custom MIDNAM files to use with the VST3 version.

From the manual and previous posts here I thought I could just edit a copy of “MIDI.midnam” from “/opt/ardour/share/patchfiles/” and put it in ~/.config/ardour7/patchfiles”, but Ardour doesn’t seem to see it there.

Running xmllint (Ardour Manual Chapter 95) just gives errors even for the unedited “MIDI.midnam” file.

Any help appreciated.

There’s a recent MIDNAM post, with similar issues here

I presume you could put your file in /opt/ardour/share/patchfiles/ as a workaround, until things get sorted out.

Thanks Peder. I got it to work partially using ~/.config/ardour7/patchfiles. I just needed to choose a better file to edit and be better with my XML formatting.

So I can select my instrument from the dropdown and the list of Controllers only shows those I added to the file. For example selecting “Automation” and then “Controllers” now gives me the option of selecting “25: LPF Cutoff.”

The missing bit is that that automation lane then just shows “Controller 25” rather than including the name of the parameter that controller is assigned to.

If someone can help with that I could do a walkthrough of the whole process.

I modified the default Waldorf_Blofeld.midnam slightly and saved it as ~/.config/ardour7/patchfiles/W_Jaws.midnam
The automation lane shows “LFO 3 Cynk”, so there doesn’t seem to be any inherent problem with Ardour’s use of the midnam files
At least not in the version I’m using; 7.4-82-gf958b7b0e0

You made a better choice of which file to modify than me! I got it sorted out in the end though.

The line I needed to add was <UsesControlNameList Name=“Controls”/>, presumably because that now tallies with <ControlNameList Name=“Controls”> where the cc numbers are mapped to names.

Thanks for the input.

Just an update in case this helps anyone…

I’ve updated to sfizz 1.2.1. . Thanks to the sfizz devs.

Creating a midnam file for the VST3 version was easier but a bit more time-consuming than I had expected. But now I have a working template it will be easy to amend as required for other SFZs. This means the VST3 version of sfizz is now not only usable but preferable to the lv2 version, at least for me.

Here’s why;

The 2 versions behave slightly differently, but the main issues I was having with each stem from the same problem.

In both cases there was a conflict between sliders in MIDI automation lanes and settings in the sfizz GUI. When reloading a session, even when automation is set to “off,” the value of the slider overrides the setting in the sfizz GUI. Changing values in the plugin GUI does not update the value in the slider but it does impact on the SFZ as expected.

VST3 version;
when reloading a session the value in the slider is what is used to set the actual level of the CC, but the GUI is not updated to reflect this. So I had a GUI value for CC11 of 100 but had somehow left the slider at a value of 0 from trialling a fade. Automation was set to “off” but there was no sound. Nudging the GUI knob made everything work even though the slider didn’t move.

After the initial load of the SFZ subsequent moves of the slider do update the GUI. And crucially automation that happens during playback updates both the slider and the sfizz GUI.

LV2 version;
when reloading a session the value in the slider is what is used to set both the actual level of the CC and the value showing in the GUI, regardless of what values were active when the session was saved. Subsequent movement of the slider does not update the GUI, neither does any information in the automation lanes. However automation does update the slider and it does work, in that it impacts on sample playback as expected.

So the fix for me was;

  1. use the VST3 version rather than the lv2. This involves;
  2. writing midnam files for my SFZ instruments so I can set up the automation lanes more easily
  3. avoid using the slider to set levels. Use the plugin UI if it’s a single value, draw it in the automation lane or use a physical controller
  4. in case of problems and prior to saving the session check by using “show existing automation” that the slider values tally with the plugin UI

Thanks to Robin and Peder, as well as Paul back in January for flagging the midnam issue.

1 Like