CircuitPython version

main

Code/REPL

# https://gist.github.com/relic-se/77e48df1920b20d3e50762cbc06d1bb9

Behavior

It depends on LFO & math block side effects that are unintended

Description

No response

Additional information

audiofilters should have their own independent LFOs and should properly "tick" them every 256 samples when generating output samples. LFOs and other BlockInputs should never be shared between different audio-generating objects.

What happens right now is:

• audiomixer will generate 512 (?) output samples from the synthesizer
• during this time the synthesizer will tick the LFOs twice
• audiomixer will generate 512 (?) output samples from the audiofilter
• during this time the LFOs will tick zero times

so while this sort-of works, the LFO's effect on the filter is changing less frequently than it should, though at the same overall rate.

If the audiofilter correctly ticked its block inputs, but they were shared with the synthesizer, then it would advance at double the rate, ticked twice for synthesizer and twice for audiofilter; each user of the LFO would see different values and the values would be "jumpy".

There seems to be no way to force the "update LFOs every 256 samples" behavior through the whole stack; for instance imagine you have an audiomixer that goes into another audiomixer just so you can control audio levels of some channels in unison. Each audiomixer wants to produce some number of samples, not necessarily 256. And in fact a big point of audiomixer is to "re-block" audio output and reduce underruns.

This all feels kinda shabby and it's my design and my fault... but we need to do the best with it we can, and it feels like audiofilter needs to "do better", by properly ticking the block inputs that it uses. (by factoring some code out of synthio to be shared between it and audiofilters! .. and probably by forcing audiofilters to always work in SYNTHIO_MAX_DUR samples between ticks, or else making the new factored out layer work in scaled seconds instead of samples and reciprocal sample rate)

Sadly, this will end up incompatibly changing code that relied on the illegal side effect of using the synthesizer to tick them.

I would love a better solution if someone has one.