PB & LFO to osc freq resolution: Still some stepping with 1-OCT-PitchBends on high notes or LFO+MW

[el-folie]

I did some further tests and just became aware of this. Don´t know why I didn´t hear it earlier.

Recorded some audio for alpha 10 and 11 for comparison due to "control priority changes for 11.1". I can´t hear much of a difference, just that there still are steps when pitchbending high notes.

And also, using a slow LFO to osc freq with fast MW movements leads to some stepping.

Desktop.zip

[image-et-son]

Dynamic pots were particularly geared towards: PW A&B and Poly Mod OSC B. If you're happy with those, we can at least close #71

For this one it would be interesting to have the comparison with earliest alphas in which this was improved. We've packed a lot of new functions (computations) into the cycle which might affect the steppiness, e.g. through new functions we've potentially fallen behind the smoothness of earlier versions. There is still some leverage for performance tuning. I guess the one control which is of top priority in that respect is pitch bend.

[el-folie]

Ah, I see... Yes, PW A&B and Poly Mod OSC B knobs are smooth as butter.

Also just tested poly mod envelope on frequency (never used that before) and dialled up/dwn sustain a few times. Yes, there is stepping but as it´s a set and forget parameter setup chain for a certain patch behaviour and nothing to dial in when playing the actual sound live, I think the stepping is unimportant in that case.

[el-folie]

Testing different alphas now...

[el-folie]

Okay, tested alpha12.1 vs alpha5, which was the breakthrough in PB/LFO smoothness. Yes, alpha12.1 is heavy on steppiness again when using PB wheel. Find audio comparison files attached. alpha12.1_vs_alpha5_freq steps.zip

[image-et-son]

Just a little documentation: with alpha 12.1 the rate of pitch bend read out was 80 per second (bad). Through tuning of parameters I got this to 210 (starting to be alright). This will be the minimum for alpha 13.

Then I did a thorough performance analysis to see where I squeeze something out. Now there is a non-timed update (one cycle about 0,72ms) including panel readout and a 2kHz timed update (anything that depends on time, such as envelopes, LFO etc.) including voice update. Unfortunately, the timed update takes up about 90% of CPU time. So what's left to non-timed updates (with the panel readout) is only 10% which limits the number of cycles per second. Pitch update of the voice would in principle by possible at 2kHz but with pitch bender we effectively reach only a tenth of that. Out of the 90% almost all time is spent on refreshVoice(). This function is optimized unless one starts playing around with wait cycles and the effect of that may be unpredictable. In short: beyond the 210 cycles the tuning potential is limited by the hardware setup. 300 seems possible.

Non-timed cycle has the following time distribution:

Panel readout | 46% Refresh pots | 23% Static CVs | 15% Tuned voice CVs | 17%

[matrix12x]

What about th hardware would limit us to a 300Hz pitch bender refresh?

[image-et-son]

What I wanted to say is that I could through conventional performance tuning potentially reach 300 Hz update frequency for the bender (when in action).

The fundamental problem is that most of the time is used up by wait cycles, waiting for voltages to raise and drop or waiting for the multiplexer to select. Notably these are the CYCLE_WAIT(2) in potmux_updatePot() (executed as many times as the desired bit depth of the pot during change detection) and the 2 times CYCLE_WAIT(1) in sh_setCV_FastPath() (e.g. 2 cycle waits for each of the 3 voltages of each voice in the 2kHz timed cycle). This is what I mean by hardware limitation because it is not the software (bare computation time). A different architecture would allow for parallel voltage reading and voltage setting, but we need to do everything in series.

[el-folie]

Tested. I still do hear tiny frequency steps and digitization noise on the PB wheel. So I guess the PB wheel scanning is approaching the system refresh rate. If anything could be done to smooth this out somehow I don´t know. Maybe by higher resolution?

[el-folie]

Adding an audio file of the tiny steps: alpha13_PBend_steps.zip

[el-folie]

alpha 13.4: We know now that the residue of audible stepping by 1-oct-pitch-bends mainly occurs in unison mode due to simultaneous voice calculation stress on the whole digital system. Solving this might not even be possible due to hardware constraints. Stepping in poly mode is now so tiny due to the optimizations that they are almost negligible. And as the general responsiveness is under constant observation by us and by testing, maybe this discrete issue could be closed too? We know it´ll be a constant companion anyway...

[image-et-son]

OK, I have the feeling that we're reaching a limit. Next steps could be code refactoring in the core functions. But I would like to do this independently from any other changes on the basis of a testes an stable release.