- Only send all sound off on channels which had notes playing
- Send it as ALL_SOUND_OFF CC to a MIDI router to route it to a different synth channel afterwards
* FluidSynthConfigVersion.cmake is created with ${VERSION} instead of
${LIB_VERSION_INFO}
* FluidSynthConfig.cmake.in simplified: it doesn't need to include the
version file.
* Simplified BUILD_INTERFACE generator expression as suggested
The build system creates two exported targets:
- The executable FluidSynth::fluidsynth
- The library FluidSynth::libfluidsynth
A downstream project using CMake can find and link the library target
directly with cmake (without needing pkg-config) this way:
~~~
project(sample LANGUAGES C)
find_package ( FluidSynth )
if (FluidSynth_FOUND)
add_executable( sample sample.c )
target_link_libraries ( sample PRIVATE FluidSynth::libfluidsynth )
endif ()
~~~
After installing fluidsynth in a prefix like "$HOME/Fluidsynth3":
cmake -DCNAKE_PREFIX_PATH="$HOME/Fluidsynth3/;..."
Instead installing, the build directory can be used directly, for
instance:
cmake -DFluidSynth_DIR="$HOME/fluidsynth-2.2.2/build/" ...
Context: https://github.com/FluidSynth/fluidsynth/discussions/931
There is a new settings "audio.oboe.error-recovery-mode" which has
string value of "Reconnect" (default) or "Stop".
Under `Reconnect` mode, it automatically recreate AudioStream for the
same audio device ID (which is the default = valid device, unless a
specific ID is specified). The behavior is the same as OpenSLES.
In the future Fluidsynth might want to provide consistent error handling
mode for audio device unplugged state, but so far this change makes apps
behave not too weird.
For detuned channels it might be better to use another key for Soundfont sample selection
giving better approximations for the pitch than the original key.
Example: play key 60 on 6370 Hz => use tuned key 64 for sample selection
This feature is only enabled for melodic channels.
For drum channels we always select Soundfont samples by key numbers.
The 2 seconds timeout was chosen for consistency, but the reason to increase the initialization timeout is that one of my test devices (Asus T101HA, Windows 10) fails to initialize the wasapi driver with a timeout error most of the times.
Each input event has values (chan, par1, par2) that could be changed by a rule.
After a rule had been applied on any value and the value is out of range, the event
can be ignored or the value can be clamped depending of the type of the event:
- To get full benefice of the rule the value is clamped and the event
passed to the output.
- To avoid MIDI messages conflicts at the output, the event is ignored
(i.e not passed to the output).
chan value: event is ignored regardless of the event type
par1: event is ignored for PROG_CHANGE or CONTROL_CHANGE type, par1 is clamped otherwise.
par2: par2 is clamped regardless of the event type.
The jack driver has a potential side-effect of starting
a new server. ALSA does not have such side-effects
and therefore makes a better default audio driver.
It seems that the addition of multichannel output has broken the WaveOut driver.
If you try to run FluidSynth with -a waveout, you will get this message:
fluidsynth: audio.periods 8 exceeds internal limit 4
Actually, the default value for period is set to 8, so it will never work unless you change that value before opening the driver. Rather than lowering the default period value or rising the limit of the number of buffers, in my opinion it would be better to free the driver from this limitation, by allocating the needed amount of memory for WAVEHDR too.
Attached patch fixes this bug.
It is not really clear to me the reason because braces are written into the initialization of channel_mask_speakers[], since their presence causes these messages from the compiler:
fluid_dsound.c:63:5: warning: braces around scalar initializer
In my opinion, it is better to remove them.
I couldn't find a conceivable use case for calling `new_fluid_audio_driver2`
with `fluid_synth_process` as its callback in client code... So I took the
lazy route.
If custom audio processing is indeed used, nothing would be changed by this
patch. It still gets no effects buffer (like the vast majority of other
drivers).
