.. when an associated value is not a quoted string.
This includes some cases where it would previously return an
integer, a CPython incompatibility.
However, it's an incompatible behavior change with circuitpython
since previously a number would be returned.
Closes: #9113
Signed-off-by: Jeff Epler <jepler@gmail.com>
This test was written in such a way that having a wrong data type
for the mp3 samples wasn't detected. Instead of using
np.frombuffer(dtype=int16), just do arithmetic directly on the
samples. During testing time we don't care if it might be a little
slower or use a little more RAM than ulab, and we don't care
whether it's actually an RMS calculation. Just that it's
consistent and shows the audio data is correct, including its
defined data type.
.. and add a very basic audioeffects test, showing that it plausibly
is working
I had to address several build errors that occurred in the Unix build,
mostly related to conversion from FP types to integral types (replaced
by explicit casts) and by
accidental mixing of regular & f-suffixed floating constants (replaced
with the MICROPY_FLOAT_CONST macro)
Particularly this change could use consideration:
```diff
- self->max_echo_buffer_len = self->sample_rate / 1000.0f * max_delay_ms * (self->channel_count * sizeof(uint16_t)); // bytes
+ self->max_echo_buffer_len = (uint32_t)(self->sample_rate / 1000.0f * max_delay_ms) * (self->channel_count * sizeof(uint16_t)); // bytes
```
The buffer length is being calculated in floating point based on the
millisecond delay & the sample rate. The result could then be a fractional
number such as 529.2 for a 12ms delay at 44.1kHz. Multiplying a floating
number by the size required for each echo buffer item
(`(self->channel_count * sizeof(uint16_t))`) could yield a number of bytes
that doesn't correspond to an integral number of buffer items. I grouped
the float->int conversion so that it converts the number of echo buffer
items to an integer and then multiplies by the size of the item.
BlockBiquad takes kind, f0 (center frequency) & Q (sharpness)
block type arguments and calculates the actual filter coefficients
every frame.
This allows the filter characteristics f0 and Q to be changed dynamically
from LFOs & arithmetic blocks.
A new manual test demonstrates this on a host computer, playing a simple
tone that is dynamically filtered.
This turns out to be needed by the testsuite of jepler_udecimal, which
needs to add the `jepler_udecimal` directory both to PYTHONPATH and
MICROPYPATH.
