From 132dd6354c0d264b4fa2000aac02c9bffc88278a Mon Sep 17 00:00:00 2001 From: Robin Haberkorn Date: Tue, 26 Sep 2023 18:44:43 +0300 Subject: 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. --- TODO | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) (limited to 'TODO') diff --git a/TODO b/TODO index d49a831..62cc4cb 100644 --- a/TODO +++ b/TODO @@ -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). -- cgit v1.2.3