Plugin Window Created To Take Initialisation Outside of Code

[ManInBlue917]

To simplify the setup of the plugin, I added a _ready() function to the singleton that calls on the functions needed to initialise FMOD. set_software_format(), set_dsp_buffer_size(), init(), set_sound_3D_settings(), and set_listener_number() are all run by the the singleton using data loaded from a .cfg file. This file is edited in the new plugin window to make setup and understanding of each option simpler.

The singleton will also autoload specified banks with options to automatically add all banks, or to clear them for custom loading.

As a small extra to this, I also created a simple debug panel that can be toggled on or off in the plugin window to show memory and CPU usage by FMOD.

The readme has been updated to reflect the change this would have on the set-up of FMOD.

[CedNaru]

What I would suggest to add:

• The new code in the _ready() function reading the configuration files should be put in its own function "load_configuration" taking the path to the configuration file as a parameter. That way people might be able to use and load those files outside of just the start of the program.
• In the same logic, not everyone wants to load FMOD at the start of the program but maybe later as it can started and closed at will, so you should also add an option "Load FMOD configuration at start" as well and only call the new "load_configuration" in ready if set.
• In the new debug window, it would be nice to display information like whether or not the sound events are currently playing or not. That way we can see if there is a difference between what is the state of the demo and what we hear.

[CedNaru]

Nevermind what I said about the debug window, I thought you created it as part of the demo but it's a standalone thing.

[CedNaru]

Adding that, the reasoning for having the configuration file outside the addon directory is to avoid overwriting it when the plugin is updated. It should be part of the project itself, not some external dependency. Like I suggested on Discord, I see 2 ways of doing it:

• Simpler approach, adding a project setting with the path to the configuration file with the root of the project (or root/fmod) default value + the option to set the automatic loading of it on launch (that way you don't have to open the file to know whether you should actually read and load it or not).
• More complex approach, instead of relying on an external configuration files, we use some FmodConfiguration Node that will init/close Fmod when added/remove to/from the SceneTree, it would basically work like the Environment node. It would offer better control and even different settings that can vary with levels/scenes. The Dock UI would be used to configure the node instead of the configuration file, the same way we edit a node like AnimationPlayer.

[ManInBlue917]

I've followed the simpler approach of having the config file be what FMOD reads from and moved that into it's own directory. I do think I'm going to look at the FMODEnvironment node idea also as I feel like it can be built on top of the current implementation, with the config file still being used, but as a resource for the new node to allow for an FMOD Environment to be saved and reused.

For now though, I think keeping it simple is for the best.

[ManInBlue917]

Incorrect bank location checks and ensuring that the master bank is the first to load has been resolved at the start of the load_bank_names() function.

Selecting bank location from a FolderDialog node has also been added.

Autogeneration of the file is handled by fmod_singleton.gd and fmod_config_window.gd. The FMOD singleton script creates a directory called fmod if the directory doesn't exists, and then the config window script writes a default file to the new directory.

[CedNaru]

When you click "clear banks", you still get Master saved in the config when it's supposed to mean you don't want to load any bank at start.