By placing certain fields in a fixed location in all sample types,
code can be reduced & reused. For instance, the same property object
can be used for every sample type's `sample_rate` property.
The sample proto functions like `sample_rate` become superfluous since
once an object is verified to support the audiosample protocol, direct
access to the fields in the base object is possible.
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.
Semi-incompatible name change: The method `release_then_press`
is now `change`. For now a compatibility alias is supported.
Everywhere a `NoteSequence` was accepted, a single note is now accepted.
So for instance, `synth.press(30)` can be written instead of requiring
``synth.press((30,))`. The same goes for `change.retrigger`, which
will accept a single LFO or a sequence.
A note can be placed in the center (panning=0) or moved to just the left
(panning=1) or right (panning=-1) channels. Fractional panning values
place it partially in both channels.
This class allows much more expressive sound synthesis:
* tremolo & vibrato
* arbitrary frequency
* different evelope & waveform per note
* all properties dynamically settable from Python code
This works for me (tested playing midi to raw files on host computer, as
well as a variant of the nunchuk instrument on pygamer)
it has to re-factor how/when MIDI reading occurs, because reasons.
endorse new test results
.. and allow `-1` to specify a note with no sustain (plucked)
In contrast to MidiTrack, this can be controlled from Python code,
turning notes on/off as desired.
Not tested on real HW yet, just the acceptance test based on checking
which notes it thinks are held internally.
