synthio: Add Synthesizer.note_state

[jepler]

This enables the specific use case of checking whether a note's release phase has ended, but is also potentially useful to implement a sort of "voice stealing" algorithm in Python code, which can take account of the note's envelope state as well as other factors specific to the program.

@todbot your comment on this would be appreciated

[tannewt]

Looks good to me. Thank you for the size fix too.

[todbot]

This addition is really neat! Both items returned in synth.note_info() are handy. Here's the quick test I used; it maxes out all synthio voices while printing their note_info (and makes a nice distorty wall of sound). https://gist.github.com/todbot/e1e954889e47fafa7ef14429c53e2c2d

Am I correct that:

• The amplitude value returned is the same as Note.amplitude
• If it returns (None,0.0), synthio is done with that Note object

A few things I noticed:

• The whole system degrades if you ask it about a bunch of Note objects it doesn't know about
• I got some hard crashes with ear-splitting static a few times. Was that me just badgering USB too fast or is the note_info() call kinda costly?

[tannewt]

@jepler is out today and Monday so I'm going to merge this as-is to get the size fix. He can make a follow up PR if needed. Thanks for the feedback @todbot.

[jepler]

The Note.amplitude another value that is multiplied together with the envelope's current value to give an overall note loudness, so the two values are different. (A Note's panning is yet another factor into the overall note loudness)

Each note_state call does a linear search through the (typically) 12 note slots. If a note is found in an early slot it takes a bit less time, while if it's a note that is not playing or was never playing it takes the greatest amount of time.

Bulk printing of data can cause glitches, because during USB CDC console writes the background tasks can't run. (and with a displayio display it's even worse because the whole time a display is being background-updated, the audiobackground task is also blocked)

However, I don't know why this would lead to a hardfault. If you have a hardfault please try to minimize the test case and file an issue.