In testing, I saw that the decoded_samples value kept increasing when I
stopped and restarted playback, as I'd missed setting it back to zero
during the reset operation.
In my testing, there is no way to accurately know how far into a MP3 file
you're currently playing. You can use monotonic time, but that can have
drift versus the audio playback system, which may not be running at exactly
the expected sample rate.
To allow syncing animation with timestamps in a MP3 file, this presents a
new property, decoded_samples, that records the number of audio samples
sent out of the decoder. While this may not be a completely accurate time,
due to mixer delays, it's much better position that the monotonic clock
difference.
Implementation is keeping track of this value in the mp3file structure and
adding to it whenever data is sent out of the decoder. The property
implementation was a copy/paste from current properties in the audiomp3
files.
new utility function for all vectorio shape specializations for testing
whether a screen-space x,y point falls within a shape's x,y.
This respects the current orientation of the screen in the manner of
displayio and vectorio - so your x,y requests are in the same coordinate
domain as your x,y locations and your width/height etc. properties that
ou set on other shapes. I.e., if you're using this for touch points then
you will need to make sure the touch events are in the same x,y domain as
your display.
```
contains(2, 4) -> true
------------------
| |
| |
| -- |
| | \ |
| |. \ |
| | \ |
| |____\ |
| |
------------------
contains(5, 4) -> false
------------------
| |
| |
| -- |
| | \ |
| | \. |
| | \ |
| |____\ |
| |
------------------
```
This helps provide low overhead introspection of shape coverage on screen.
It's envisioned that this will be used for things like touch-and-drag
widget controls, touch "areas" and may help with random ornament placement
on toy Christmas trees.
.. which is what the addition of cmd25 made happen. We still signal
an error when failing to reach the idle state at any other time,
which _is_ different than adafruit_sdcard but I think that it is
correct.
This fixed#5600 according to Dan's testing on a GCM4 on the internal
SD card slot. There are still some ambiguous results on the MM4 with
external SD card slot on 6" jumper wires.
this happens to make the occasional FS dither artifact disappear.
I guess `a * b >> 8` and `(a * b) / 256` are not identical. I'm not
sure if it was just the parens or not, but write the clearer code and
rely on the compiler to substitute an appropriate shift if possible.
