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.
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.
Cheers!
Josh
_______________________________________________
fluid-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/fluid-dev
