prof-spock / FluidSynthPlugin

Simple Wrappers Around the FluidSynth Library as DAW Plugin and Pedantic Command Line Processor
5 stars 0 forks source link

inconsistent behavior when selected preset is not present in the SoundFont #10

Closed mrbumpy409 closed 4 months ago

mrbumpy409 commented 5 months ago

When attempting to load a preset that is not present in the SoundFont, I get different behavior depending on the situation. Here are three different scenarios and their results:

Scenario 1

  1. Load a SoundFont into FluidSynthPlugin and hit "Confirm".
  2. Set the program to a preset that doesn't exist in the SoundFont (e.g., program = 0:50) and hit "Confirm".

Result: FluidSynthPlugin displays the error message cannot set 'program' to '0:50' and the synthesizer plays preset 0:0.

Scenario 2

  1. Load a SoundFont into FluidSynthPlugin and hit "Confirm".
  2. Choose a preset that exists in the SoundFont, and hit "Confirm".
  3. Load a different SoundFont that does not contain the bank and/or preset number selected in step 1, and hit "Confirm".

Result: No error message is thrown, and the synthesizer continues playing the preset from the previously loaded SoundFont.

Scenario 3

  1. Load a SoundFont into FluidSynthPlugin.
  2. Add the line synth.interpolation-method = 7 in the text window and hit "Confirm".
  3. Choose a preset that exists in the SoundFont, and hit "Confirm".
  4. Load a different SoundFont that does not contain the bank and/or preset number selected in step 1, and hit "Confirm".

Result: FluidSynthPlugin displays the error message cannot set 'synth.interpolation-method' to '7' and the synthesizer plays preset 0:0 of the newly loaded SoundFont.

Summary

The third scenario's error message appears to be a red herring—the real issue is that it cannot set the preset. I'm guessing the preferred behavior in all three cases is the result of Scenario 1. In all cases I am selecting the SoundFont and presets using the new right-click menu options, except for changing the bank/preset in Scenario 1.

Fortunately, this bug is just cosmetic and doesn't impact the functionality of the plugin.

prof-spock commented 5 months ago

Hello mrbumpy409,

I tried to fix this in the current feature branch, please have a look.

The measure is quite drastic: any sound output is suppressed unless soundfont and program are reasonable. Before that the plugin has simply relied on the FluidSynth default reactions and this is confusing as you rightly mentioned.

Regarding the error messages: there is some imprecision here, because some settings (like the synth.interpolation-method you have used) require a restart of the underlying synthesizer. This means that another time the previous settings of the plugin are transferred to the fluidsynth synthesizer and here the bad program number is detected as erroneous just before the interpolation method setting is processed.

I hope that the current fix at least obscures this problem.

It is unfortunate that one cannot just tell the Fluidsynth synthesizer what to do in whatever sequence. The restart logic implemented is a crutch to cope with that, but it would be quite difficult to completely hide the state model of the synthesizer from the plugin user.

Best regards, Prof. Spock

mrbumpy409 commented 5 months ago

In my testing, this works well. Behavior is consistent, and having no sound produced when the synth is passed an invalid bank/preset makes sense.

However, this does impact a different use case that should be discussed. If I want to use bank & preset MIDI messages to change instruments, this previously worked if I left the "program = " line out of the text box. Otherwise, if the "program = " line is present, MIDI program change events work, but bank change commands do not.

Now, after this latest change, leaving the "program = " line out of the text box results in no sound produced, so I can no longer use MIDI commands to change bank/instrument in this circumstance.

Off the top of my head, this could be addressed a couple of ways. One would be to fix the MIDI bank change events to work even if the "program = " line is present. The other would be to make it so leaving out "program = " would work as it did before, with FluidSynth I presume loading preset 0:0.

prof-spock commented 5 months ago

Hello mrbumpy409,

this is incorrect and a severe oversight on my side. I have provided a fix: a program change unlocks the playback blocking (or causes it 😉 )

But you see, once you want to hide the state model of the underlying library from the user it breaks elsewhere.

I hope the change works for you?!

Best regards, Prof. Spock

mrbumpy409 commented 5 months ago

Here is what I'm seeing with the latest update, tested with REAPER in Linux:

Scenario 1: With no program = parameter in the text box, MIDI program changes work, but bank selection (CC0) doesn't. I am sending the typical simultaneous CC0 and PC events. Scenario 2: With program = 0:0 in the text box, neither program changes nor bank selection works.

Scenario 2 not working is not a problem, because I can always just omit the program = parameter if I want to use MIDI events for preset selection (and this behavior can be documented). However, being unable to change banks in Scenario 1 is a regression from prior versions.

mrbumpy409 commented 5 months ago

I must add a huge THANK YOU for all of the extra time you have been dedicating to stamping out these remaining issues. I hope I haven't been too much a thorn in your side! What you've created here is providing what I believe to be the best SoundFont rendering you can get in a DAW. I hope that it will continue to garner more attention and become widely used, as it deserves to be! I will certainly be doing my part to proselytize your efforts.

prof-spock commented 5 months ago

Hello mrbumpy409,

you wrote:

bank changes do not work as expected

We are again bitten by Steinberg's dumb idea to separate the program change logic from the MIDI event stream in VST3.

I've checked in a fix that should address that problem.

I must add a huge THANK YOU for all of the extra time you have been dedicating to stamping out these remaining issues.

No need for gratitude, I have to thank you for your patience and dedication!

Many years ago I had pestered the FluidSynth people myself about technical details, because I needed a DAW plugin that exactly reproduces the FluidSynth command line version and the available ones were not good enough.

My desire was to replicate in a DAW an external tool chain (including FluidSynth and SoX) for an automatically generated band notation video production; and I wanted it to be almost perfect. If you can hear the grass grow, you will understand very well what I mean.

But to be honest: nobody cares about soundfonts or even more some academic tool for them with high fidelity but a simplistic user interface. Except for a few people somewhere in the world like you.

So I am grateful that you - as the Godfather of soundfonts - have invested so much testing effort. It has greatly improved the tool and I hope you can use it for your purposes and your pleasure!

And my wife does not think any longer that I am the only customer for my audio plugins...

Best regards, Prof. Spock

mrbumpy409 commented 5 months ago

Hi Prof, thank you for your kind words! I am very happy to be able to test and help you with this plugin.

The latest change has re-introduced the issue with FluidSynth playing internally at the wrong sample rate. Furthermore, bank and preset changes continue to not function as expected. I have created an unlisted YouTube video to show you the issues I am running into. Hopefully it may shed some light on the subject and help you reproduce the behaviors on your end.

Peace, -~Chris

mrbumpy409 commented 5 months ago

Thinking on this further, I wonder if not silencing the output of FluidSynth and just letting it handle the bank & preset events sent to it might be better than trying to reprogram the bank/preset handling logic that's already present in the synthesizer, even if the messaging isn't always clear.

In earlier builds, I could leave the "program = " command out, and all bank & preset change commands worked as expected. Perhaps returning this behavior when "program = " is absent would be the easiest way to handle cases where someone wants to control bank/preset via MIDI commands.

prof-spock commented 5 months ago

Well, one could even say that bank/program changes are filtered out whenever you have specified a preset in the edit field: when you defined something there, you may not override that existing setting.

This looks like a good idea, because now I have to store MSB and LSB of the bank internally (in whatever sequence they had occurred) and have them only get relevant when a program change occurs. And they define the default bank for a partial setting in the edit field (like ":67"). And hopefully the plugin host hunts those control changes when doing a rewind in the DAW and the FluidSynthPlugin updates the settings correctly...

Looks complicated and this is the reason that things got worse as you have shown in your video.

By the way: the sample rate bug was easy. Possibly I was drunk when doing the underlying naive change.

And another question to the expert: is a combination of MIDI bank number and program number (like "1:28") a "preset" (as opposed to a "program" as used in the plugin UI)? What do you mean: shall we rename the parameter?

Anyway: expect a new version for testing tonight... (maybe CDT and not CEST :wink:)

mrbumpy409 commented 5 months ago

I think you can use "preset", "program", and "patch" interchangeably. I don't see any reason to change it from "program = ". If you wanted to support "preset = " you could code it as an alias for "program = " to avoid breaking anybody's existing VST3 presets.

I look forward to trying the new build later. :smile:

prof-spock commented 5 months ago

Hello mrbumpy409,

please have a look, I hope it solves the problems. At least program and bank changes are suppressed when a preset exists and they should go through when no preset is specified.

Sorry to use you as an alpha-tester, but those effects are a bit subtle. And also the fact that VST3s hosts must filter out the program changes from the MIDI event stream and make them plugin preset changes does not help either.

Best regards, Prof. Spock

mrbumpy409 commented 5 months ago

Bank and preset changing with no "program =" command in the window now works perfectly! The only remaining issue I could find was that if I added "program = 0:0" or whatever, and then later remove it, bank/program changes still don't work. I have to remove the plugin from the track and add a new plugin instance in order to use bank/preset changes again.

I'll keep testing and let you know if I run into any further issues.

Peace, -~Chris

prof-spock commented 4 months ago

Hello mrbumpy409,

well, I am a bit puzzled. I did a test on the feature branch repository version freshly installed. You'll find my results in this unlisted video.

Did you test in Linux or Windows? Or both?

Best regards, Prof. Spock

mrbumpy409 commented 4 months ago

Aah, I figured it out. This bug only happens when synth.interpolation-method = is used.

Steps to Reproduce

  1. Initialize an instance of FluidSynthPlugin as follows (adjusting SoundFont path):

    soundfont = path/to/soundfont.sf2
    synth.interpolation-method = 7

    Result: MIDI bank/preset changes work as expected.

  2. Add program = 0:0 to the plugin window.

    Result: MIDI bank/preset changes have no effect, as expected.

  3. Remove program = 0:0 from the plugin window.

    Result: MIDI bank/preset changes have no effect. Expected Result: MIDI bank/preset changes should work again.

  4. Remove synth.interpolation-method = 7 from the plugin window.

    Result: MIDI bank/preset changes work again.

This was only tested using the Linux version, but I would be surprised if it didn't affect all versions.

Peace, -~Chris

prof-spock commented 4 months ago

Hello mrbumpy409,

well, let's have another try. I hope it works with the latest update (at least it does for me). Sorry for your inconvenience!

Best regards, Prof. Spock

mrbumpy409 commented 4 months ago

Yes, I can no longer reproduce the bug after the last update. Everything appears to be working as expected.

prof-spock commented 4 months ago

Okay, to tie the loose ends together I would wrap up everything so far, provide a new release and close the bug issues. Is that fine with you?

mrbumpy409 commented 4 months ago

Sounds good to me. 😁

mrbumpy409 commented 4 months ago

By the way, I have to say that the SoundFont loader automatically detecting file path variables is awesome! Nice touch, Prof!

prof-spock commented 4 months ago

Well, I like it when computers do something seemingly intelligent 🖖

prof-spock commented 4 months ago

part of release 0.7.0, see release notes