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 /TODO | |
| 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 'TODO')
| -rw-r--r-- | TODO | 9 |
1 files changed, 1 insertions, 8 deletions
@@ -6,6 +6,7 @@ # Features +* Real-time input. See inputstream branch. * Line Continuations on the CLI (like Lua's CLI) * CLI auto completions via libreadline. This could directly introspect the Stream object for instance. @@ -48,14 +49,6 @@ Unfortunately, it will not resolve all non-realtime-safe gtick-invocations. It's also questionable what happens when the timestamp wraps. Whether a wrap is safe or not, will depend on the generator. -* Inconsistent signal normalization. - Some signals like Stream:CC() are not normalized to [-1,1], so you need - special scaling methods like Stream:ccscale(). - The supposed advantage is that often a signal between [0,1] is needed, so you only - need a single division. E.g. Stream:mul(Stream:CC(...) / 127). - On the other hand, with normalized outputs, you could also write Stram:mul(Stream:CC(...):scale(1)). - Or there could even be a Stream:vol() method that takes signals between [-1,1]. - The question is whether the JIT compiler is smart enough to optimize this code. * The JIT compiler currently does not emit SIMD instructions (see simd-test.lua). See also https://github.com/LuaJIT/LuaJIT/issues/40 * Perhaps always enable Fused multiply-add (-O+fma). |