Glitchy mod wheel action with vib/LFO target pitch

[image-et-son]

When adjusting the strength of pitch modulation by either vibrato or LFO using the mod wheel one can hear distinct steps. This is most pronounced when the modulation frequency is low, so that the mod wheel action changes the pitch more quickly than the vib/LFO. The effect occurs for vibrato sin and all LFO waveforms. For the modulation targets "PWM" and "Filter" no similar effect occurs, or at least it is not recognizable if it does.

[image-et-son]

el-folie remarks on gearspace: the technical manual (section 2.6) says that mod wheel has priority in the interrupt in the Z80.

[image-et-son]

After some testing with the alpha 3 (Fedora avr-gcc 11. compile) and the alpha 4 (Mac avr-gcc 4.8.2 compile) it seems that the glitchness / steppiness of bend/wheel/freq pots etc. is a "problem" of the 4.8.2 compile and solved in the 11. compile. However, 11.* produces MIDI problems. This topic needs to be analysed properly, also w.r.t. to optimization of the code and other compiler versions.

[image-et-son]

The problem with the compiler is solved.

[image-et-son]

Performance measurement using MIDI

Here are my first results based on my Fedora 11.1 compile an based on alpha 5 (plus the MIDI probing):

• the synth_update() function (which is responsible for responsiveness) runs about 300 per second without load and about 150 times per second under full load (all voices active, multiple pot movements - but not yet with external MIDI). This should be compared to 2000 cycles per second for the timer.
• The distribution of load over the 4 cycles of the timer are roughly: 10%, 20%, 30%, 40% (I looked at where the interrupted synth_update() is more likely to start, maybe I am drawing the wrong conclusion, though)
• Under load the distribution of load of the cycles does not change. For me this is a strong indicator that the synth_update() function is not interrupted more strongly but rather takes much longer itself. So performance tuning should focus on synth_update(). synth_update_measurements.txt

[image-et-son]

The synth_update() function spends 99% of its time in the function potmux_update(reg. pot count). Current 9 pots are updated per cycle. There is the potential to remove an average of 2 per cycle, because priority pots are done twice if they are in the regular pot selection, so a performance gain of ab 20-25% might be possible.

Further optimization ideas: 1) Introduce a three tier priority, with a very slow set, for instance ADSR controls. To be tested! 2) Introduce a dynamic prioritization, where in the first contact of a pot only a first estimate is made (half the bit depth?) which is refined only in the next cycle. Idea: On a fast sweep it better to have a fast sequence of approximate values than a steppy set of precise values. This is a major change, though.

[matrix12x]

I suggest picking the low hanging fruit first.

3 tier priority is a great idea. Envelope and switches should all be lowest priority. Filter and pitch controls should be highest priority.

[image-et-son]

First results: it is a difficult choice to demote single pots. The delay on very slow pots becomes very pronounced and the gain on the fastest pots is only about 20-30% faster at max. My test indicate that we'd need reaction times which correspond to >600 per second, so simply demoting other pots alone will not help. E.g. with always read full bit depth of every pot, the changes by prioritization will simply not be enough.

Before trying other things what needs to be tested is how much of the overall computation time goes into synth_update(). If it is <<50% it may also be effective in the next step to optimize functions called in synth_timer_interrupt().

[matrix12x]

Maybe for "big moves" of the pots we can just read a reduced bit depth, and if there are "fine moves" we could read the full bit depth? Or would determining that eat up the resources we are trying to save?

[matrix12x]

Another possible savings is to not calculate an envelope or an LFO unless it is being used. e.g., the LFO amount >0 or not calculating the filter envelope when the env amount is = 0 (and its not being used by poly mod.)

Maybe making a LFO mod destination of none to save cycles on certain patches.