The user can specify a custom soundfont to be used with fluidsynth.
There was previously a hack for the iOS7 backend to get the path to
the document folder where the user can put files in a sandboxed
environment. This hack was removed in commit:
cac0664757
The problem however occurred when creating a FSNode from the full
system path because FSNode uses makeFileNodePath, which already
prepends the root. So the full path is added twice which causes the
fileNode.exists() to fail.
Create the FSNode from the path to the soundfont and check if the
file exist. If so then return the full path.
Cherry-pick of: addbdc13c5
Git conflict manually fixed
The code looks a bit less hack-ish and also now supports using path
in the application bundle and not only in the documents folder. It
could also help for other backends using a sandoxed filesystem.
This updates the FluidSynth settings to the value ranges and defaults used by
the current version 2.3.4.
Reverb
- Room size: 0.00-1.20 / 0.20 to 0.00-1.00 / 0.20
- Width: 0-100 / 1 to 0.0-100.0 / 0.5
Chorus
- Level: 0.00-1.00 / 1.00 to 0.00 - 10.00 / 2.00
- Speed: 0.30-5.00 / 0.30 to 0.10-5.00 / 0.30
- Depth: 0.0-21.0 / 8.0 to 0.0-256.0 / 8.0
If FLUID_INFO is "verbose informational messages", perhaps they should
be better hidden from the average user than warnings. Particularly since
warnings are the only kind I've actually seen in the wild. (Change
suggested by criezy.)
When an engine provides in-memory SoundFont data, use that unless a
SoundFont has been explicitly configured on the current game. Otherwise
a global SoundFont setting will always override it. Even overriding the
MIDI settings for the game and leaving the SoundFont setting blank did
not work for me.
The previous fix did not work as the forbidden exception had no effect
since scummsys.h and thus forbidden.h had already been included prior
to the fluidsynth header being included. This also meant that undefining
the exception define after the header would have had no effect anyway.
This new solution was suggest by eriktorbjorn on bug #11278 and should
avoid the need to add an exception which would persist over the entire
source file.
The function signature for these functions was changed from (char *) to
(const char *) in the v1.1.7 release, so compiling against
Fluidsynth v1.1.6 or earlier requires the copying of the strings to
prevent compilation errors such as "error: invalid conversion from
'const char*' to 'char*'".
Normally, we would break compatibility with older versions as platforms
should be using the latest Fluidsynth v1.X release of v1.1.11.
However, since this is trivial to fix and prevents breakage for legacy
platforms, am restoring the string duplication with scumm_strdup().
Apart from this, we should look at the Fluidsynth v2.X releases
currently in RC testing as the API is now changed for this.
MIDI code will control volume via MIDI events thus the generated audio should
not be affected by mixer sound volumes.
The initial commit(s) in d4d045b117 /
13dc149ded added it as music sound type.
So, this seems to be a long standing issue.
To help people familiar with Qsynth (I'm not, but it seems to be
one of the more polished FluidSynth front ends), use the same
presentation and terminology for the FluidSynth settings.
More to follow.
I don't really understand what these parameters do, or what the
sensible values are, so for now the sliders are limited only by
the allowed (or, in one case, "safe") values.
