globalTimescale seems to be getting intermittently banged with random numbers

[boqs]

Possibly a breakthrough on all the the unpredictable behaviour I've been seeing when running lines scenes very hot...

When you really go crazy hitting many of lines' params simultaneously, occasionally it will start really glitching out, getting stuck etc. finally discovered I can perform a 'reset' after it gets in this state by re-sending the globalTimescale param. globalTimescale is also, coincidentally, the very first param in the enum!

hypothesis:
sometimes params are getting corrupted/dropped. When this happens, it sends a random number to
param 0.

experiment:
put an extra 'dummy' param on idx 0

[boqs]

additional observation:
I definitely just saw the 'emperically correct' right-shift for that globalTimescale param in param_set.c jump from 5 to 6 over the course of this morning. pretty certain the 'theroretically correct' value is 4!

[boqs]

observation:
adding an extra 'dummy' param on idx 0 & shuffling globalTimescale to the end of param list fixes the random jumps in globalTimescale.

There's still a yet-rarer intermittent bug. That is the module unrecoverably goes silent which seems correlated with BEES synthspew but has also been observed in normal (but heavy) usage. My patch transmits several params 'at once' using split.

conjecture:
to fix this final bug, throttle BEES' param transmission down to, like, 2-per-millisecond using (in the first instance) calls to sleep.

[boqs]

the entire system seems totally resilient now to very intense param-thrashing with only 100us sleep per-param. After two pretty horrible days thrashing about in confusion over these intermittent bugs I'm calling this an epic win!

Trying 50us because that's just over 2 audio frames & we really shouldn't be sending params any faster than that... (50us works!!!!!!)

[boqs]

inexplicably, that 'dummy' param is still fixing something, with or without the 50us sleeps... At this stage I can live with this particular piece of braindamage & am happy to let it seep into all the other modules...

[catfact]

so you think PR 301 is good to merge?

[boqs]

@catfact as long you approve of the 16-bit mixing change, yes I believe this is now ready to merge.
Just about to test one more feature - fade-in write head to reduce those pops when recording is a few milliseconds after the start of a sound.

I think the write-fade also works, just need to repeat all the stress-testing then I'll add it to that PR. (also just added LIST4)

[boqs]

Observation:
tried reverting both ecf1b32 (blackfin CV driver) & boqs@afd75b5 (dummy DSP param). This combination has excellent stability.

Conclusion:
Blackfin CV driver change was the root cause of this 0th-param-getting-randomly-overwritten intermittent weirdness!

[catfact]

argh, sorry. what a drag, I thought we were on to something there

[boqs]

yeah it all looked so promising I got really excited about the CVs too. But personally I can live without them.

Suspect with current firmware state they would still be fine as percussive triggers, just not for pitch-CV.