When there's no sustain, the release step needs to be calculated from
the attack level, not the sustain level. Otherwise, contrary to intent,
this leads to the actual release taking a loooonnngg time.
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.
Now the vibrato 'units' are 1.0 = one octave, 1/12 = one semitone,
1/1200 = one cent. Before, the units were somewhat arbitrary and were not
perceptually "symmetrical" around the base frequency.
For vibrato_depth = 1/12 and base frequency of 440,
before: pitch from 403.33 to 476.67Hz, not corresponding to any notes
after: pitch from 415.30 to 466.16Hz, corresponding to G# and A#
this has the side effect of making some notes more accurate, the new
frequency= value in the test is closer to the true midi frequency of
830.609...Hz.
and re-vamp overall envelope calculation again.
Now, if you set a low overall attack level like 0.2 this avoids the
"diminishing volume" effect when many notes sound at once. You need
simply choose a maximum attack level that is appropriate for the max
number of voices that will actually be played.
.. and account releasing notes at their sustain level until they're
done.
this ameliorates the effect where multiple releasing notes
don't seem to actually be releasing, but stay at a constant volume.
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)
Add address_little_endian for epaper displays with little endian
(low byte first) addresses.
Also clears allocated display and display bus memory so it has a
known state. The acep member wasn't always set so it varied
accidentally.
Fixes#7560. May fix#7778. Fixes#5119.
PicoDVI in CP support 640x480 and 800x480 on Feather DVI, Pico and
Pico W. 1 and 2 bit grayscale are full resolution. 8 and 16 bit
color are half resolution.
Memory layout is modified to give the top most 4k of ram to the
second core. Its MPU is used to prevent flash access after startup.
The port saved word is moved to a watchdog scratch register so that
it doesn't get overwritten by other things in RAM.
Right align status bar and scroll area. This normally gives a few
pixels of padding on the left hand side and improves the odds it is
readable in a case. Fixes#7562
Fixes c stack checking. The length was correct but the top was being
set to the current stack pointer instead of the correct top.
Fixes#7643
This makes Bitmap subscr raise IndexError instead of ValueError
when the index arguments are wrong.
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.
a waveform object (array of 'h') can be passed in, replacing the
standard square wave. This waveform must be a 'single cycle waveform'
and some obvious things to pass in are sine, triangle or sawtooth waves,
but you can construct whatever you like.
Otherwise, the following would occur:
* settings.toml is in the process of being written by host computer
* soft-reset begins
* web workflow tries to grab CIRCUITPY_WIFI_SSID, but loops forever
because FAT filesystem is in inconsistent state and file reads error
* settings.toml write by host computer never completes and the filesystem
remains corrupt
* restarting yields a soft-bricked device, because startup reads
CIRCUITPY_WIFI_SSID again
