These two files are not ordinary C files, and are being compiled
through #include's in other C source files, not through invoking
compiler on generated files. This might confuse both developers and
automated systems.
For longer explanation see discussion in #800.
In `fluid_rvoice_mixer.c`:`fluid_rvoice_mixer_process_fx()`:
If an audio processing callback is used, `mix_fx_to_out` would be `FALSE`. As a result, `in_ch` and `out_ch_l` points to the same buffer.
In `fluid_chorus.c`:`fluid_chorus_processreplace()`:
```C
/* process stereo unit */
/* store the chorus stereo unit d_out to left and right output */
left_out[sample_index] = d_out[0] * chorus->wet1 + d_out[1] * chorus->wet2;
right_out[sample_index] = d_out[1] * chorus->wet1 + d_out[0] * chorus->wet2;
/* Write the current input sample into the circular buffer */
push_in_delay_line(chorus, in[sample_index]);
```
Here the chorus processing code writes to the left output buffer (which will overwrite the input buffer in this case) before the sample from the input buffer is stored into the delay buffer, making the chorus output all zeros. If no audio processing callback is used, `mix_fx_to_out` would be `TRUE` and `in` and `left_out` will not point to the same buffer, therefore the order doesn't matter.
Simply swapping the two steps should be a sufficient fix. This patch also apply the same change to `fluid_chorus_processmix` only for the sake of consistency (since they are almost exact copies of each other).
Resolves#751.
This PR addresses #669 point 2.1.
It proposes set/get API functions to change/read fx unit parameters.
The deprecated shell commands are updated. Now the commands line have 2 parameters:
- first parameter is the fx unit index.
- second parameter is the value to apply to the fx unit.
Currently, all fx unit output (in mix mode) are mapped to the `first buffer`.
This is not appropriate for synth.audio-groups > 1
This PR allows the mapping of fx output based on `fx unit index` and `synth.audio-groups` value.
This allows us to get the `fx output `mixed to the respective `buffer` on which a `MIDI channel` is mapped.
For example: with `synth.audio-groups = 3` and `synth.effect-groups = 3`:
- MIDI chan 0 (dry + fx0) is mapped to buf 0
- MIDI chan 1 (dry + fx1) is mapped to buf 1
- MIDI chan 2 (dry + fx2) is mapped to buf 2
This PR allows the reverb to pre-allocate the memory needed for the maximum sample-rate of the synth. That means that on sample rate change there are no memory allocation and the function fluid_revmodel_samplerate_change() should always return FLUID_OK.
The PR addresses discussion in #608.
This fixes a regression introduced in 907ec27a9e
When rendering a voice, there are 3 cases to consider: silent, playing,
and finished. When optimizing away the memset, I incorrectly assumed that
a voice cannot switch between playing and silence (like crazy) while
rendering FLUID_MIXER_MAX_BUFFERS_DEFAULT. Apparently this does not
hold true, esp. when rendering at sample rates ~96kHz.
This adds new LFO modulators:
- these modulators are computed on the fly, instead of using lfo lookup table. Advantages:
- Avoiding a lost of 608272 memory bytes when lfo speed is low (0.3Hz).
- Allows to diminish the lfo speed lower limit to 0.1Hz instead of 0.3Hz.
A speed of 0.1 is interesting for chorus. Using a lookup table for 0.1Hz
would require too much memory (1824816 bytes).
- Make use of first-order all-pass interpolator instead of bandlimited interpolation.
- Although lfo modulator is computed on the fly, cpu load is lower than using
lfo lookup table with bandlimited interpolator.
Also adds a stereo unit controlled by WIDTH macro. WIDTH [0..10] value define a stereo separation between left and right.
- When 0, the output is monophonic.
- When > 0 , the output is stereophonic.
WIDTH is currently fixed to maximum value to provide maximum stereo effect.
I tried to check the generated ASM code when WITH_FLOAT macro is defined and when it is undefined. In both cases I noticed that there are some points where the math number are converted from float to double and viceversa. Actually this happens whether the FPU is present or not, perhaps for granting the right precision in digits. I also noticed few points that could be simplified a bit by using integer math, so I also included them.
* Since fluid_voice_get_actual_key() returns an integer value, the value 60 could be subtracted directly as integer, the code generated looks a bit better.
* FLUID_NOISE_FLOOR needs to be cast to fluid_real_t to generate a bit more efficient code.
* DC_OFFSET needs a cast to fluid_real_t to generate a bit more efficient code.
* "last_fres" and "output_rate" are already fluid_real_t, so they do not need type cast.
* "chan_add", "par1_add" and "par2_add" are integer types, so they can be added without FPU. "chan_mul", "par1_mul" and "par2_mul" are already fluid_real_t, so they do not need type cast. Instead, the constant 0.5 needs cast to fluid_real_t to be more efficient.
Since v 2.1 ,as recommended by soundfont 2.01/2.4 spec
ATTACK section is convex. So, when skiping from a
section above ATTACK to ATTACK, it is necessary to
correct current modulation envelope value to get
seamless transition.
