ideas for future GUI improvement

[mrbumpy409]

Currently, FluidSynthPlugin provides everything I need for my uses. The current GUI approach provides many benefits that I appreciate, such as the abilities to use variables in the file path and to copy and paste settings between plugin instances.

The one area that I think might pose an obstacle to many users, however, is the preset handling. Currently, one must make use of separate software to know what presets are available in a given SoundFont. In my case, I usually open the SoundFont in Polyphone or juicysfplugin, take note of its presets and then write the correct values to FluidSynthPlugin's program = parameter. While a bit clunky in workflow, I am willing to take these measures to make use of the best SoundFont engine available within a DAW.

To improve ease of use whilst preserving most of how the plugin currently functions, I propose the following ideas for your consideration:

1. Drag and drop a SoundFont into the plugin interface to paste the SoundFont's file path. — This would be useful for those without an advanced file manager capable of executing "copy file location" or something similar. Simply typing soundfont = then dragging the SF2 into the interface to paste the full file path at the current cursor location would ease the workflow for many.
2. Add a preset browser to the GUI. — This would make the biggest difference as then the user could see what presets are actually available within the SoundFont. Here is a mockup: My thoughts on how this could function:
   • The preset browser would not be populated until a SoundFont has been loaded. The FluidSynth API appears to have a method for retrieving a list of presets from the loaded SoundFont(s).
   • Clicking on a preset name would switch to that preset immediately, without needing to press "Confirm" and also without resetting the synthesizer.
   • The program = parameter would not need to exist within the parameter box. If the program = parameter does exist, it would take precedence over the preset browser, but only when clicking "Confirm" or when the plugin is reloaded.

If adding such ideas is outside of the scope of this project, I understand. I do believe, however, that they would make the plugin more accessible to a wider audience. Please don't feel obligated to these suggestions, and if you need to take a break from all the work you've been putting into this plugin, you should come back to this if/when you have the motivation. I will be enjoying the plugin either way. :smile:

Yours truly, -~Chris

[prof-spock]

Hello mrbumpy409,

thanks for your interesting suggestion!

I am not sure whether extending the user interface with additional elements is helpful or whether it might even be confusing. Because in your proposal there are some hidden rules as you mentioned: a textual setting of program takes precedence over the selected preset in the widget but any change in the widget is automatically confirmed. So this might get complicated...

But what I could imagine is the following:

• Extend the context menu of the text widget by two entries: Select soundfont... and Select program....

• The first menu entry brings up a standard file selection dialog box, where the soundfont can be selected. A confirmed selection updates the soundfont entry in the edit field or creates a new entry there, but leaves or puts the edit field in the "edited" state.

• The second menu entry brings up a preset selection dialog for the previously confirmed soundfont (this is necessary because any tinkering with the text field is only relevant once the Confirm button is pressed). A selected preset either updates an existing program entry in the text field or creates a new entry with the appropriate bank and program number and leaves or puts the edit field in the "edited" state.

• A drag'n'drop of a soundfont file to the edit field could also update the soundfont setting there and leaves or puts the field in the "edited" state.

This means that the original UI logic is still valid: you may play around with the edit field in any way you like, but it is only operational once the Confirm button has been pressed.

So the typical workflow might be:

1. Right-click on the widget and select menu entry Select soundfont...

2. Select the soundfont from the file selection dialog.

3. Confirm edits (to have soundfont loaded).

4. Right-click on the widget and select menu entry Select program...

5. Select the program from the selection dialog.

6. Confirm edits.

You are quite right that the fluidsynth API provides means for enumerating the presets in a soundfont; so this seems to be doable.

So your proposal looks interesting, and it would definitely simplify the access to the very academical interface of the software.

But I cannot promise a quick implementation, because this needs some time and I have to think about a good UI. Nevertheless I'll keep it on my todo list and have you informed as soon as you can test it... :wink:

Best regards, Prof. Spock

[mrbumpy409]

Honestly, your proposed way of doing this sounds great to me, and I agree it would be more consistent with the way the plugin currently behaves.

[prof-spock]

Hello mrbumpy409,

about 1500 line of code and two weeks later your suggestion has been implemented :wink:

Please have a look at the branch "feature" whether this works as expected. Unfortunately drag'n'drop does not work for Linux (a known issue in JUCE), but all the other features should be okay.

I have noticed that the debugging versions of the plugins might be somewhat flaky (at least when multiple plugin instances try to write logs simultaneously like in the test file); I have to think again how to synchronize parallel logging, but honestly this is a rather esoteric use case...

Hopefully this is what you had suggested?

Best regards, Prof. Spock

[mrbumpy409]

I can't wait to test this out! Unfortunately, I get an error during the cmake step:

CMake Error at CMakeLists.txt:41 (INCLUDE):
  INCLUDE could not find requested file:

    PluginCPPCompilerSettings.cmake

Indeed, the PluginCPPCompilerSettings.cmake file does not exist.

[mrbumpy409]

Okay, I just saw your commit adding the missing file. Building now.

[prof-spock]

Hello mrbumby409,

argh, I should definitively build the distributions from the repository for a check. (I am doing this now...). The missing file is added to the branch, hopefully this solves your problem.

Best regards, Prof. Spock

[mrbumpy409]

The new GUI options work beautifully! I've discovered a couple of bugs, which I've reported on their own tickets. I think these changes will really increase accessibility for a lot of people!

[prof-spock]

part of release 0.7.0, see release notes