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 allows to test how the midi synthesizer is working, without access
to hardware. Run `micropython-coverage midi2wav.py` and it will create
`tune.wav` as an output.
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.
* Enable dcache for OCRAM where the VM heap lives.
* Add CIRCUITPY_SWO_TRACE for pushing program counters out over the
SWO pin via the ITM module in the CPU. Exempt some functions from
instrumentation to reduce traffic and allow inlining.
* Place more functions in ITCM to handle errors using code in RAM-only
and speed up CP.
* Use SET and CLEAR registers for digitalio. The SDK does read, mask
and write.
* Switch to 2MiB reserved for CircuitPython code. Up from 1MiB.
* Run USB interrupts during flash erase and write.
* Allow storage writes from CP if the USB drive is disabled.
* Get perf bench tests running on CircuitPython and increase timeouts
so it works when instrumentation is active.
cpython actually makes sure the newly chained exception doesn't create
a cycle (even indirectly); see _PyErr_SetObject use of "Floyd's cycle
detection algo". We'll go for the simpler solution of just checking
one level deep until it's clear we need to do more.
Closes: #7414
\r\n files must be working due to micropython's built in handling of
text-mode files, I didn't implement it.
\r-only (old mac text-mode files) are explicitly not supported by
the toml format.
While working on adding 0o and 0b literals (which aren't added yet and
may not be) I realized that my approach would likely cause a problem
for the value "0"
* use a virtual fat filesystem during the test
* this makes the file I/O part more closely patch runtime which is nice
* side-steps the need to add a special function for testing
* but test still can't be run on a device, because the vfs calls
are incompatible, and you intentionally can't remount "/" anyway
* and side-steps problems with storing 'bad' toml files
This adds the __cause__, __context__ and __suppress_context__
members to exception objects and makes e.g., `raise exc from cause`
set them in the same way as standard Python.
A task that has been sent to the loop's exception handler due to being
re-scheduled twice will then subsequently cause a `raise None` if it is
subsequently awaited. In the C version of task.py, this causes a segfault.
This makes the await succeed (via raising StopIteration instead).
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
This also depends on https://github.com/adafruit/Adafruit_CircuitPython_Ticks/pull/8
otherwise adafruit_ticks is unimportable and the tests are just skipped.
Several of the tests fail, and one runs forever instead of terminating.
We should fix our asyncio until the tests patch, then incorporate this
change.
