Re: [yoshimi-user] Different sound in Yoshimi and ZynAddSubFX - update
- From: Kristian Amlie <kristian@xxxxxxxxxx>
- To: yoshimi-user@xxxxxxxxxxxxxxxxxxxxx
- Date: Tue, 25 Feb 2014 21:57:56 +0100
On 23/02/14 12:16, Will Godfrey wrote:
As far as I can see there are at least 3 places where AddSynth filtering is
handled and Cal has made a lot of changes with regard to variable names - all
of which make perfect sense of course!
Also there are a number of places where he's replaced something like:
GlobalPar.PFilterVelocityScale / 127.0 * 6.0 // velocity sensing
with:
GlobalPar.PFilterVelocityScale / 127.0f * 6.0f // velocity sensing
Is the latter just a more correct way of presenting a float value, or is it
possible that the compiler would treat these differently?
It is possible. Compilers generally convert each operand to the "best"
type of either operand. Which one is best is decided (roughly) by this
hierarchy:
- long double
- double
- float
- int
- short
- char
I see from the definition of PFilterVelocityScale that this is a char
variable, which has a *very* small range. So it's possible that all
numbers are converted to char before doing the math, which is
potentially very bad. By explicitly stating that those numbers are
floats, we increase the range and resolution of the calculation a lot.
Then again, it's hard to know exactly what compilers do, so take what I
said with a grain of salt. But I *think* that is how it works.
Finally there are a lot of places where such a line:
if (pars->VoicePar[nvoice].PFMDetuneType != 0)
has been replaced with:
if (pars->VoicePar[nvoice].PFMDetuneType)
This is one I'm quite happy with. It makes things more readable and in both
cases (as far as I know) the compiled code simply checks the zero flag of a
register.
You're right, those two are equivalent.
--
Kristian
Other related posts:
