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.
Previously, cmake only tested for a specific version of libsndfile and then assumed, it has OGG/Vorbis support. However, libsndfile may still be compiled without OGG/Vorbis support. If this is the case, fluidsynth should refuse to load SF3 files. Otherwise the attempt to load SF3 files would fail with a bunch of error messages.
The solution of this PR proposes to lookup the private libs listed in sndfile.pc and see whether it includes "vorbis".
Libsndfile was unintentionally compiled without OGG/Vorbis support. That's because libopus was missing. When compiling libsndfile with autotools [you get a nice warning](9349a566e2/configure.ac (L381-L386)). When using CMake you don't...
Solution: Compile libopus before compiling libsndfile. Now it reports
```
-- The following features have been enabled:
* ENABLE_EXTERNAL_LIBS, enable FLAC, Vorbis, and Opus codecs
```
The unit tests keep failing when compiling with MinGW x86 on x64 Windows10. This is related to the change introduced in #629. The exact reason for the failure is unknown. I assume it's a broken MinGW implementation of the function `fgetpos()` or `_fseeki64()`, as the tests run fine for WindowsXP x86. However, I have little interest in further investigation, as I don't consider using MinGWx86 on x64 to be a valid use-case.
Pipelines should not be triggered when other pipelines are modified. This saves many resources when messing around with a single pipeline, because other pipelines won't run.
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).
Use executable suffix to make test work on Windows and
specify explicit output directory for dump_sfont tool.
Uses a generator expression $<0:> to prevent VS and Xcode from
adding per-config subdirectories to the RUNTIME_OUTPUT_DIRECTORY
Runs the new dump_sfont utility on the test soundfonts and
compares them against the stored representation. Raise an error
if there are any differences.
