On Tue, 15 Dec 2009 19:02:19 -0800, address@hidden wrote:
I committed some additional changes which reverts the work that was
done with Reverb/Chorus in regards to queuing the events and
processing them in synthesis context. They are now processed
immediately and with a mutex to ensure multiple threads don't try to
assign values at the same time. Therefore chorus/reverb should not be
assigned from synthesis context if real time is a concern (noted in
the API reference), which shouldn't be a problem. I looked over the
Chorus and Reverb code and from what I can tell, there shouldn't be
any crash issues in regards to interactions between assigning
reverb/chorus and the synth thread, but there are still synthesis
artifacts, especially with Chorus. To be fixed later and probably as
a side effect of them being replaced by something better.
I noticed in QSynth that it is not using the full ranges of the Reverb
and Chorus. Especially in the case of Reverb, which probably accounts
for the reason why the reverb controls don't seem to have much effect.
Reverb:
roomsize: 0.0 - 1.2
damping: 0.0 - 1.0
width: 0.0 - 100.0
level: 0.0 - 1.0
QSynth only uses 0.0 - 1.0 for all parameters.
not quite. parameters are in deed normalized and stored in 0.0 - 1.0 range
for configuration persistence store. a scale factor of 100.0 is in effect
at runtime. actual parameter limits are imposed by the gui widget itself
though.
Chorus:
nr: 0 - 99
level: 0.0 - 1.0
speed: 0.29 - 5.0
depth_ms: 0.0-21.0 is safe for sample rate values up to 96KHz
Looks like QSynth goes up to 100 on the "nr" parameter and 10.0 on the
level parameter. The other ones seem OK though.
seems like these reverb and chorus ranges/scales changed from previous
fluidsynth versions (<1.1.0) and reading from the above i would say that
they have changed quite radically for some of them.
will try to cope with these new figures (please confirm the actual values,
please)