- When DEBUG macro is set, this allows printing of voices
modulators on stdout.
- Printing is done by fluid_print_voice_mod() which allows
displaying of voices modulators belonging to any combination (preset
zone, intrument zone).
Filters names are useful for printing voice modulators of only one
zone when necessary.
The parameters (roomsize, level, etc.) of the reverb effects unit are initialized at the very end of `new_fluid_synth()` with `fluid_synth_set_reverb_full_LOCAL()`.
This however only adds an update-event to the `rvoice_mixer` queue.
The call to `fluid_synth_process_event_queue()` in `new_fluid_synth()` should make sure, that this event is dispatched and triggers the actual update.
However, the event is not dispatched immediately, because the rvoice event queue has not been committed yet, that is, a call to `fluid_rvoice_eventhandler_flush()` is missing.
So, although a reverb param initialization event has been queued, the reverb params still are garbage initialized (on Windows to some `-6.2774385622041925e+66`).
The next call to through the synth's public API will flush the queue and finally dispatch the update event, but when will it happen?
1. If the soundfont is specified as command-line argument, this call will happen before the audio driver starts rendering.
2. If the soundfont is loaded via shell command `load`, the audio driver will first start rendering audio, after updating the reverb.
Case 1. is trivial, everything works as it should.
Case 2. is interesting. Since the synth already started rendering audio by using that uninitialized reverb unit, the reverb engine's internal buffer is completely filled up with noise. Before outputting that signal to sound card, the sound is clipped to `1.0f`. That's the click we hear at the beginning. And because the reverb is so loud, the rendered audio signal stays 1.0f for quite a long time (...or always, can't tell).
Why is it not reproducible on Linux? Because GCC and Clang (AFAIK) leave all values uninitialized after allocating memory. And because malloc() often return zero-initialized memory, the reverb params seem to be nicely zero-initialized. MSVC however, always initializes memory with garbage, which is why we "hear" this resonance disaster.
Solution: Just update the reverb params via public API, which implicitly calls `fluid_rvoice_eventhandler_flush()`.
Fixes#563.
1)@param mod_count number of modulators in table list_mod:
- If > 0, the function assumes that list_mod is a table and
initializes it as a list of modulators chained by next field, so that the caller
doesn't need to do this initialization. This is appropriate when the
function is called from fluid_voice_add_mod2().
- If 0, the function assumes that mod_list is a list of modulators with next
field properly initalialized by the caller. This is appropriate when the
function is called from the soundfont loader.
2) Test 11 is added to test_modulator_links.c allowing to test this new parameter.
1)@param linked_count, number of modulators in linked_mod:
- If > 0, the function assumes that linked_mod contains a table provided
by the caller. The function returns linked modulators directly in
this table which is faster because it doesn't allocate memory.
This is appropriate when the function is called from fluid_voice_add_mod2().
- If 0, the function makes internal allocation and returns the list in
linked_mod. This is appropriate when the function is called from
the soundfont loader as the list of linked modulators must exist during the
life of the preset it belongs to. NULL is returned in linked_mod if there is
no linked modulators in list_mod.
2) Test 10 is added to test_modulator_links.c allowing to test this new parameter.
- rename fluid_test_linked_mod_test_identity() to
fluid_linked_mod_dump_test_identity()
- make use of duplicate function fluid_dump_linked_mod() in
fluid_desfont.c
- add comments
This document explains what sostenuto pedal is compared to sustain pedal. It is intended for a musician playing live. It gives information about specifications and implementation in fluidsynth.