[yoshimi] Re: How to deal with that problem?

  • From: Will Godfrey <willgodfrey@xxxxxxxxxxxxxxx>
  • To: yoshimi@xxxxxxxxxxxxx
  • Date: Sat, 29 Sep 2018 14:28:03 +0100


On Mon, 28 May 2018 13:30:01 +0200
Ichthyostega <prg@xxxxxxxxxxxxxxx> wrote:

So my conclusion and *proposal* is:

(a) either we revert the change of Andrew, and use the FE_TOWARDZERO for the
   LV2-Plugin as well, where it should (according to Andrew's reasoning)
   make no difference (--> and review Reverb.cpp and SynthEngine.cpp)

(b) or we follow up with Andrew's reasoning and get rid of the FE_TOWARDZERO
   altogether, in the whole code base. Which means, to round towards the
   closest next grid value (which is the default). This would mean to judge
   the ramifications for parameter value display in the GUI.

Getting back to this again. I'm thinking of a more radical way of dealing with
all of these issues. In the first place I was quite horrified when I finally
understood how the behaviour of 'standard' routines could be modified by the
environment. As far as I'm concerned this is an absolute NO for critical engine
and parameter settings, which must be consistent regardless of environment on
source.

So, I jumped in the deep end and wrestled the heffalump again.

In my current build of /src/Synth/ADnote.cpp
 
I changed lines 1089-1900:
    oscfreqhi[nvoice][k] = float2int(speed);
    oscfreqlo[nvoice][k] = speed - floor(speed);
to:
    int tmp = int(speed);
    oscfreqhi[nvoice][k] = tmp;
    oscfreqlo[nvoice][k] = speed - tmp;

My reasoning for doing this in this *specific* case is as follows:
 
    We know the floating point value will always be positive.
    We know we always want to round it down.
    A cast to int is faster than any function.
    A subtraction is faster than any function.
    There are no time-wasting built-in checks for non-relevant conditions.
    There is no dependency on environment conditions.

Finally, there is a known issue with casting to int if the float has a
value outside the range of an integer. For that to be a problem we would need
to be running oscillators at a frequency even the bats wouldn't be able to hear!


I'm pleased to report that not only does this work quite correctly on a variety
of machines I have access to, but also on David's N270 (a heffalump victim).

What I intend to do now, is see how many other similar cases we can uncover and
simplfy. If there are enough we can put in-line functions in MiscFuncs to keep
everything tidy. One I already know that I use extensively is float to bool,
where I've been using:

value_bool = (value > 0.5f);

In theory we should also allow for negative values, but they never actually
occur, so why bother?

Any thoughts on this are more than welcome. If you think I'm wrong please do
say so... and why :)


Moving on, quite a long time ago LFOs were made real time. Filters and
envelopes are still next-note. Now I can't think of a rationale for making
envelopes real time, but filters would definitely be nice to be able to adjust
on a sounding note. Anyone fancy taking a look at that?

TTFN :)

-- 
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
Yoshimi source code is available from either: 
https://sourceforge.net/projects/yoshimi
Or: https://github.com/Yoshimi/yoshimi
Our list archive is at: https://www.freelists.org/archive/yoshimi
To post, email to yoshimi@xxxxxxxxxxxxx

Other related posts: