Everything should be using the keypad module instead.
Note: there are several boards that still had gamepadshift enabled. I
did not contact their authors to make sure they already switched to
keypad in their code and documentation. We should probably wait with
merging this for their go ahead.
os.getenv() will use it (when available) to load variables from
/.env
This will also be useful when we need secrets or config for
CircuitPython outside of the VM (like WiFi credentials.)
Fixes#4212
The old formulation
* wouldn't work if there were ID3 tags at the end
* would choose whether to background-refill the inbuf
based on a check before skipping to the next sync word, which
could be incorrect.
I think it was aspect "B" that ended up triggering the erroneous EOF
problem fixed in the prior commit. This would depend on specific data
sizes and offsets occuring in the file such that a read would be
scheduled but then the buffer would be filled and left 100% full by
find_sync_word(). It's just lucky(?) that a particular person produced
such a file, and/or many files produced by Audacity have those
characteristics.
This saves 444 bytes on the pygamer build (both commits taken together)
testing performed:
* pygamer (samd51) with ShiftRegisterKeys
* macropad (rp2040) with Keys
* UM feather s2 (esp32-s2) with KeyMatrix
Result:
* all ports still worked nicely
* keys held down at start always registered (>2 trials all boards, >100 trials esp32-s2)
* keys held down are immediately registered after reset() (>100 trials esp32-s2)
* double .reset() is OK, accessing .events throws (only tested esp32-s2)
Some audio implementations, notably samd, really don't like it when
you return 0 samples of data. This was the case when reaching the
end of an MP3 file.
Now, we read forward in an MP3 file to the next sync word during
"get_buffer", so that we can accurately return GET_BUFFER_DONE when the
NEXT call WOULD HAVE resulted in 0 samples.
Tested with @gamblor21's "laugh.mp3" file on a Trellis M4 Express.
