anthonyalfimov / swonic-dynamic-controls Goto Github PK
View Code? Open in Web Editor NEWDynamic Controls turns your ROLI Lightpad BLOCK into a flexible MIDI control surface
Home Page: https://swonic.com/dynamic-controls/
License: MIT License
Dynamic Controls turns your ROLI Lightpad BLOCK into a flexible MIDI control surface
Home Page: https://swonic.com/dynamic-controls/
License: MIT License
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.
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.
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.
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:
Data source | 0.4.4 | 1.1.0 | Average δ |
---|---|---|---|
int literal | 8 - 10 ms | 16 - 18 ms | +89% |
int constant | 8 - 10 ms | 16 - 19 ms | +94% |
int variable | 9 - 10 ms | 17 - 19 ms | +89% |
metadata int variable | 9 - 10 ms | 17 - 19 ms | +89% |
heap | 12 - 13 ms | 21 - 24 ms | +80% |
metadata vector element | 22 - 23 ms | 36 - 39 ms | +67% |
local config item | 33 - 36 ms | 39 ms | +13% |
Benchmark script: BMK_LoopPerformance.littlefoot.zip
0.4.4 | 1.1.0 | Average δ |
---|---|---|
7 - 8 ms | 13 ms | +73% |
Benchmark script: BMK_FunctionCallPerformance.littlefoot.zip
0.4.4 | 1.1.0 | Average δ |
---|---|---|
9 ms | 15 - 16 ms | +72% |
Benchmark script: BMK_ConditionalPerformance.littlefoot.zip
0.4.4 | 1.1.0 | Average δ |
---|---|---|
9 - 10 ms | 15 - 16 ms | +63% |
Benchmark script and modes: BMK_DC_204_NS.zip
Test points are marked with BENCHMARK
in code.
touchMove()
executions: Ctrl 1, no ctrl layering0.4.4 | 1.1.0 | |
---|---|---|
16 XYs, latch, pressure | 147 - 148 ms | 227 - 238 ms |
16 XYs, latch, no pressure | 138 - 141 ms | 221 - 232 ms |
16 Faders, latch, pressure | 139 - 141 ms | 220 - 232 ms |
16 Buttons, latch, pressure | 123 - 128 ms | 197 - 207 ms |
16 Notes, latch, pressure | 123 - 128 ms | 197 - 208 ms |
touchMove()
executions: 16 XYs, latch, pressure0.4.4 | 1.1.0 | |
---|---|---|
Ctrl 1, no ctrl layering | 147 - 148 ms | 227 - 238 ms |
Ctrl 16, no ctrl layering | 100 - 102 ms | 155 - 161 ms |
Ctrl 1, ctrl layering | 147 - 148 ms | 227 - 238 ms |
Ctrl 16, ctrl layering | 157 - 160 ms | 250 - 262 ms |
repaint()
execution: 16 XYs, latch, pressure0.4.4 | 1.1.0 |
---|---|
40 - 43 ms | 58 - 64 ms |
handleMIDI()
executions: 16 XYs, latch0.4.4 | 1.1.0 | |
---|---|---|
Correct channel and ctrl | 6 - 7 ms | 11 - 12 ms |
Correct channel, wrong ctrl | 6 - 7 ms | 11 - 12 ms |
Wrong channel | 3 - 4 ms | 5 - 6 ms |
Benchmark script and modes: BMK_DC-LE_204_NS.zip
Test points are marked with BENCHMARK
in code.
touchMove()
executions: Ctrl 1, no ctrl layering0.4.4 | 1.1.0 | |
---|---|---|
25 Faders, latch | 192 - 197 ms | 303 - 319 ms |
25 Button, latch | 179 - 180 ms | 283 - 301 ms |
25 Notes, latch | 180 - 181 ms | 284 - 301 ms |
touchMove()
executions: 25 Faders, latch0.4.4 | 1.1.0 | |
---|---|---|
Ctrl 1, no ctrl layering | 192 - 197 ms | 303 - 319 ms |
Ctrl 25, no ctrl layering | 100 ms | 153 - 162 ms |
Ctrl 1, ctrl layering | 192 - 197 ms | 303 - 319 ms |
Ctrl 25, ctrl layering | 192 - 197 ms | 304 - 320 ms |
repaint()
execution: 25 Faders, latch0.4.4 | 1.1.0 |
---|---|
64 - 67 ms | 98 - 104 ms |
handleMIDI()
executions: 25 Faders, latch0.4.4 | 1.1.0 | |
---|---|---|
Correct channel and ctrl | 7 - 8 ms | 12 - 13 ms |
Correct channel, wrong ctrl | 7 - 8 ms | 12 - 13 ms |
Wrong channel | 3 - 4 ms | 6 - 7 ms |
Note: running the same benchmarks as in July 2019 today on firmware 0.4.4 gave the same results.
Benchmark script and modes: DC_129Alpha_Benchmark.zip
Test points are marked with BENCHMARK
in code.
touchMove()
executions: 16 XY, momentary, pressure0.4.4 (July 2019) | 1.1.0 (May 2020) | Average δ | |
---|---|---|---|
Ctrl 1, no overlaps | 148 - 149 ms | 229 - 239 ms | +58% |
Ctrl 16, no overlaps | 100 - 102 ms | 157 - 161 ms | +57% |
Ctrl 1, overlaps | 148 - 149 ms | 229 - 239 ms | +58% |
Ctrl 16, overlaps | 157 - 161 ms | 250 - 264 ms | +62% |
handleMIDI()
executions: 16 XY, latch0.4.4 (July 2019) | 1.1.0 (May 2020) | Average δ | |
---|---|---|---|
Correct channel and ctrl | 7 - 8 ms | 11 - 12 ms | +53% |
Correct channel, wrong ctrl | 7 - 8 ms | 11 - 12 ms | +53% |
Wrong channel | 4 - 5 ms | 5 - 6 ms | +22% |
Benchmark script and modes: DC_128Alpha_Benchmark.zip
Test points are marked with BENCHMARK
in code.
repaint()
execution: 16 XY, momentary, pressure, no overlaps0.4.4 (July 2019) | 1.1.0 (May 2020) | Average δ |
---|---|---|
4 - 5 ms | 6 - 7 ms | +44% |
touchMove()
executions: Ctrl 10.4.4 (July 2019) | 1.1.0 (May 2020) | Average δ | |
---|---|---|---|
16 XY, momentary, pressure | 147 - 148 ms | 229 - 239 ms | +59% |
16 XY, latch, pressure | 147 - 148 ms | 229 - 239 ms | +59% |
16 XY, latch, no pressure | 139 - 142 ms | 221 - 231 ms | +61% |
16 Faders, latch, pressure | 139 - 141 ms | 220 - 232 ms | +61% |
16 Button, latch, pressure | 124 - 128 ms | 197 - 208 ms | +61% |
16 Notes, latch, pressure | 124 - 128 ms | 198 - 209 ms | +62% |
Benchmark script: midiPerformance.zip
0.4.4 (July 2019) | 1.1.0 (May 2020) | Average δ | |
---|---|---|---|
100x sendMIDI() (CC) |
3 - 4 ms | 3 - 4 ms | - |
100x sendCC() |
3 - 4 ms | 3 - 5 ms | - |
100x sendNoteOn() |
22 ms | 3 - 4 ms | -84% |
100x sendNoteOff() |
22 ms | 5 - 6 ms | -75% |
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.