diff options
author | Robin Haberkorn <robin.haberkorn@googlemail.com> | 2023-09-26 18:44:43 +0300 |
---|---|---|
committer | Robin Haberkorn <robin.haberkorn@googlemail.com> | 2023-09-26 18:44:43 +0300 |
commit | 132dd6354c0d264b4fa2000aac02c9bffc88278a (patch) | |
tree | 2b89acc38488ac99768f4005cacd0b24803b781a /examples/simple.ipynb | |
parent | 8f0147f9d37509306e8b045cf85e95db3fa6390d (diff) | |
download | applause2-132dd6354c0d264b4fa2000aac02c9bffc88278a.tar.gz |
Stream:CC14() added, Stream:CC() outputs normalized values, got rid of Stream:ccscale()
* Stream:CC14() allows reading 14-bit CCs (split over two 7-bit MIDI messages).
It's actually capable to handle regular 7-bit controllers just fine.
The question is whether we still need a distinction between Stream:CC() and Stream:CC14().
Stream:CC14() has a slight overhead, but only when actually receiving MIDI messages.
* Stream:CC14() and Stream:CC() output values normalized to [-1,+1] now.
We actually never made use of raw CC values and the scaling can be done only once whenever
a matching MIDI message is received, so the runtime overhead is irrelevant.
* This means we could also get rid of Stream:ccscale() now.
Just use Stream:scale() from nowon.
* Use Stream:scan() now whenever relying on previous values.
That way, you can often avoid having to keep an accumulator variable in the closure.
Diffstat (limited to 'examples/simple.ipynb')
0 files changed, 0 insertions, 0 deletions