anthonyalfimov / swonic-dynamic-controls Goto Github PK

Steps to reproduce:

Edit a mode in Dashboard and quit without saving. When you launch Dashboard again, the Block retains the modified mode, while the Dashboard UI displays the unmodified state of the same mode.

• I will further investigate this behaviour and see if this can be fixed using an upload script.

Andreas:
→ Another idea would be to copy the behavior of the MPE buttons the ROLI apps have (sending slide, glide and press CC when moved after touch...). I didn’t program that feature since it was nothing I needed for my setup... but with enough memory I think it would make total sense!

After installing the 4.3.0 update, metadata variable change scripts don't function anymore, which breaks the apps Dashboard UI.

It should be possible to use invisible non-vectorised metadata variables as a memory buffer to preserve values of parameters represented by the CCB variable. It would take 13 ints, or 52 bytes (~1% memory) (4 ints per parameter + 1 to store previous control type).

This is not a pretty solution, since CCB values will be stored in three different locations (metadata vector for the UI, metadata "buffer" for persistence and heap for performance).

Since this will take half of our bug-fixing memory, maybe we should wait and introduce it only after some beta testing. While it would be a nice improvement, it's better to make sure there isn't something more important to spend the memory on.

I thought I'll open this thread because I think I encountered a bug appearing with Firmware Version 0.4.5

Note that this affects both the UI and the transmitted CC values.
It is almost certainly caused by the touch surface picking up minuscule finger movements at the border between two values.

We could try smoothing this out by reducing the touch sensitivity and thus filtering out some of the smaller finger wobbles. This, however, can reduce the resolution of smaller controls and have a negative impact on performance, so we should keep an eye on these aspects.

Currently, the MIDI handler ignores incoming MIDI Note messages, even if there are Note controls. This can be addressed, if the memory allows and there is demand for this enhancement.

Feature request by Sigmond via our download page comments:

Custom Off Value for controls.

This bug is only present when "Individual Brightness" is disabled.

Factory scripts don't draw the UI unless the Block is connected, which probably saves a bit of battery charge. Maybe we should do the same?

If the channel and the CC number of an incoming MIDI message coincide with those of a "latch"-mode Note control (despite it not using the CC number), the control will respond to such a message.

Function execution with Lightpad firmware 1.1.0 is slower than what we measured using the same exact scripts in July 2019 (firmware version 0.4.4).

After manually downgrading my Lightpad to firmware version 0.4.4, I obtained the same test results as in July 2019. This suggests that firmware 1.1.0 is the cause of the problem.

Littlefoot performance: firmware 0.4.4 vs firmware 1.1.0 | API Mode

By manually downgrading my Lightpad to firmware version 0.4.4, I was able to directly compare the performance of Littlefoot features between firmwares 1.1.0 and 0.4.4.

1000x data retrieval operations

Benchmark script: BMK_DataRetrievalPerformance.littlefoot.zip

In this test we measure the time it takes to perform 1000 assignments of integer data to a variable from:

1000x empty loop iterations

Benchmark script: BMK_LoopPerformance.littlefoot.zip

1000x empty function calls

Benchmark script: BMK_FunctionCallPerformance.littlefoot.zip

1000x empty conditional statements

Benchmark script: BMK_ConditionalPerformance.littlefoot.zip

Dynamic Controls 2.0.4 performance: firmware 0.4.4 vs firmware 1.1.0 | API Mode

Dynamic Controls

Benchmark script and modes: BMK_DC_204_NS.zip
Test points are marked with BENCHMARK in code.

100x touchMove() executions: Ctrl 1, no ctrl layering

100x touchMove() executions: 16 XYs, latch, pressure

10x repaint() execution: 16 XYs, latch, pressure

10x handleMIDI() executions: 16 XYs, latch

Dynamic Controls LE

Benchmark script and modes: BMK_DC-LE_204_NS.zip
Test points are marked with BENCHMARK in code.

100x touchMove() executions: Ctrl 1, no ctrl layering

100x touchMove() executions: 25 Faders, latch

10x repaint() execution: 25 Faders, latch

10x handleMIDI() executions: 25 Faders, latch

Benchmark comparison: July 2019 (firmware 0.4.4) vs May 2020 (firmware 1.1.0) | API Mode

Note: running the same benchmarks as in July 2019 today on firmware 0.4.4 gave the same results.

Dynamic Controls 1.2.9 Alpha

Benchmark script and modes: DC_129Alpha_Benchmark.zip
Test points are marked with BENCHMARK in code.

100x touchMove() executions: 16 XY, momentary, pressure

10x handleMIDI() executions: 16 XY, latch

Dynamic Controls 1.2.8 Alpha

Benchmark script and modes: DC_128Alpha_Benchmark.zip
Test points are marked with BENCHMARK in code.

1x repaint() execution: 16 XY, momentary, pressure, no overlaps

100x touchMove() executions: Ctrl 1

Littlefoot MIDI functions

Benchmark script: midiPerformance.zip

Note:
I’ve noticed weird behaviour with Lightpad sending Note On messages via both sendMIDI() and sendNoteOn() functions.

When attempting to repeatedly send identical Note On messages (same channel, note number and velocity), Lightpad stops transmitting these messages after sending a seemingly random number of them. Sending the same message becomes possible again only after a Note Off message for the same MIDI channel and note number has been transmitted. This behaviour occurs regardless of the useMPEDuplicateFilter() state.

I can’t imagine a situation where this behaviour can cause any issues, but it seems weird nonetheless.

Andreas:
Save Modes to BLOCKS and cycle through than via the Mode button (I think this was missing from your list? This would be probably my personal most wanted feature.) If we can’t make that possible the functionality to save modes on the BLOCKS should be blocked (like you already suggested).

In some cases (e.g. Blue-Magenta and Purple modes at 100 contrast and 0 brightness) you will see differently coloured pixels on inactive buttons or faders even when shading is off. This has nothing to do with shading adjustments from #13 and was present before them.

This is caused by the default blendARGB(baseColour, overlaidColour) function sometimes changing the baseColour even when overlaidColour is completely transparent (which is the case when shading is set to off). Here's a script to demonstrate this:

void initialise()
{
    clearDisplay();
    
    int base = 0xff201922;
    logHex(base);
    
    int test = blendARGB(base, 0);
    logHex(test);
}

Log output:

ff201922
ff1f1821

Therefore, this is a Littlefoot issue. Correcting this behaviour on our side would take a significant memory investment that is not viable at this stage, so we should leave this as is. I'm creating this issue to acknowledge the problem and provide an explanation.

Affected parameters: Note, On Value, Velocity, Y Axis CC.

Currently investigating.