midi-components-0.0.js: Pot support for arbitrary maximums in 7-/14-bit handlers #4495

Swiftb0y · 2021-10-30T21:06:17Z

previously, it was not possible for 14-bit controls to have maxima
that are not (2^14)-1. Some controller might only have 3-bits of
resolution in their MSB. This commit allows for arbitrary precision
in MSB and LSB by specifying an appropriate value as the components
max property.

Be-ing · 2021-10-31T03:56:09Z

res/controllers/midi-components-0.0.js

+                // this with non-7-bit inputs. We cannot detect
+                // that in the constructor so set the max
+                // appropriately here


Why can't that be detected in the constructor?

Because we don't know how the component is being used until either the input handler (for regular 7-bit precision) or the inputLSB/inputMSB handlers (for 14-bit precision) have been called.

Adding this requirement later is a breaking API change, so something we should reserve for the ES6 rework.

Initial commit of a mapping for the Reloop Ready controller. The Padmodes are not implemented and just default to the hotcues right now. The mapping currently depends on mixxxdj#4474 and mixxxdj#4495

Initial commit of a mapping for the Reloop Ready controller. The Padmodes are not implemented and just default to the hotcues right now. The mapping currently depends on mixxxdj#4474, mixxxdj#4495 and mixxxdj#4512

github-actions · 2022-01-30T00:33:45Z

This PR is marked as stale because it has been open 90 days with no activity.

Swiftb0y · 2022-01-30T00:48:33Z

ping. I am using this in the pending Reloop ready mapping and it works so far.

Initial commit of a mapping for the Reloop Ready controller. The Padmodes are not implemented and just default to the hotcues right now. The mapping currently depends on mixxxdj#4474, mixxxdj#4495 and mixxxdj#4512

github-actions · 2022-05-02T00:07:03Z

This PR is marked as stale because it has been open 90 days with no activity.

Initial commit of a mapping for the Reloop Ready controller. The Padmodes are not implemented and just default to the hotcues right now. The mapping currently depends on mixxxdj#4474, mixxxdj#4495 and mixxxdj#4512

daschuer

Thank you I have left some comments.

daschuer · 2022-06-29T08:25:52Z

res/controllers/midi-components-0.0.js

+                // this with non-7-bit inputs. We cannot detect
+                // that in the constructor so set the max
+                // appropriately here
+                if (this.max === Component.prototype.max) {


I do not understand the condition. When does this happen.

It checks if the user did not specify a custom max value. If that is the case, the maximum is not 2^7-1 but 2^14-1 since we're in the MSB handler. If the user did specify a custom max value, then this was intentionally chosen to be correct. As explained in the comment, this is a workaround for the flawed API.

daschuer · 2022-06-29T09:17:41Z

res/controllers/midi-components-0.0.js

+                }
+                var maxSaved = this.max;
+                // maximum value of MSB
+                this.max = this.max >> 7;
                this.input(channel, control, value, status, group);


Temporary change a member to before calling a function looks hacky.

Why is this code required? Is this an initial call with low precision?

Let's say we have 8 bit precision, than the MSB is 1 for the max value.
inValueScale() has div by 0 with that and will not work well with other small bit counts.

Can this call be removed?

Alternative we may leave max untouched just set the this.MSB before and pass 0 as value.

By the way, every input function does
```
if (this.MSB !== undefined) {
value = (this.MSB << 7) + value;
}

That logic can be moved to inputLSB() so that value is always the truth an the single precision code dos not suffering form the penalty of checking this.MSB

Temporary change a member to before calling a function looks hacky.

I agree, but the entire this.MSB !== undefined branch is a hack...

Why is this code required? Is this an initial call with low precision?

Yes.

Can this call be removed?

Maybe. I'll look into it.

The problem with removing this call (and by extension the entire branch) is that requesting the initial controller state will break if the LSB is received before the MSB.

If the LSB received before the MSB, the whole implementation is broken!

Consider going from 126 to 129

MSB LSB 126 = 0000000.1111110 127 = 0000000.1111111 128 = 0000001.0000000 129 = 0000001.0000001

Wen the send order is actually swapped the MSB from the first value is paired with the LSB from the next:

LSB MSB 126 = 1111110.0000000 127 = 1111111.0000000 128 = 0000000.0000001 129 = 0000001.0000001

result:

MSB MSB 127 = 0000000.1111111 0 = 0000000.0000000 129 = 0000001.0000001

In the C Domain we allow both orders:

mixxx/src/controllers/midi/midicontroller.cpp

Line 318 in 7672cf1

if (mapping.options.testFlag(MidiOption::FourteenBitMSB)) {

The requirement is that both messages are send with nothing else in between.

First of all, we discussing no longer the scope of this PR.
I have not understand the controller state issue, that requires the discussed branch.

In the C domain we also do not know the order in advance. We collect MSB and LSB messages and when both is there we calculate the value. We discard a stored MSB or LSB when any other message is send. This ensures that both are actually belong together.

Of cause that can ticked as well, but at least better than always using the wrong order.

First of all, we discussing no longer the scope of this PR.

So whats the point then? I know the design is flawed. So will we agree on that and discuss whats actually in the scope of this PR or will we blow it 10x as we usually do?

In the C domain we also do not know the order in advance.

Are you sure? Thats what I figured the distinction between MidiOption::FourteenBitLSB and MidiOption::FourteenBitMSB was.

I have not understand the controller state issue, that requires the discussed branch.

Ok going back on topic. We don't know in which order inputLSB and inputMSB will be called so to basically avoid throwing an error deeper into the callstack we ignore the LSB message and then when we receive the MSB, we use that as the LSB as a single-shot workaround. Does that answer your question?

First of all, we discussing no longer the scope of this PR.

So whats the point then? I know the design is flawed. So will we agree on that and discuss whats actually in the scope of this PR or will we blow it 10x as we usually do?

That was my point, not blowing up this PR.

I have now understand the issue.

Are you sure? Thats what I figured the distinction between MidiOption::FourteenBitLSB and MidiOption::FourteenBitMSB was.

Yes, pretty sure. We even have a test for that.

So for the solution here, wan may to shift the "value" left, instead of sifting the "max" right.
If we in addition store the discarded LSB we can put it in and have a fully valid message.

Now I understand your proposal. Thanks. I just pushed the commit containing your suggestions.

Swiftb0y · 2022-06-29T12:03:07Z

Thank you for picking this PR up.

…it handlers previously, it was not possible for 14-bit controls to have maxima that are not (2^14)-1. Some controller might only have 3-bits of resolution in their MSB. This commit allows for arbitrary precision in MSB and LSB by specifying an appropriate value as the components max property.

…t scaling

daschuer

LGTM

daschuer · 2022-07-01T06:05:58Z

I have filed a bug for the pending issue:
https://bugs.launchpad.net/mixxx/+bug/1980454

Swiftb0y · 2022-07-01T08:33:38Z

Thank you

Initial commit of a mapping for the Reloop Ready controller. The Padmodes are not implemented and just default to the hotcues right now. The mapping currently depends on mixxxdj#4474, mixxxdj#4495 and mixxxdj#4512

Initial commit of a mapping for the Reloop Ready controller. The Padmodes are not implemented and just default to the hotcues right now. The mapping currently depends on mixxxdj#4474, mixxxdj#4495 and mixxxdj#4512 fix(controllers): Reloop Ready fx2 level knob Co-authored-by: majekw <[email protected]> various features (i'll squash later anyways) * Add option to correct for offset tempo fader notches * Improve LED feedback of various buttons when pressing and shifting * add eject function to load button when shift-pressing * remove dad code * turn of big pads when shutting down * fix 4th pad in ManualLoopPadMode (loop_in_goto) * Add beatJumpMode for ScratchBank * fix slip button Add pitch play mode (WIP) (untested)

This fixes a regression introduced in mixxxdj#4495 and reported as mixxxdj#11814

github-actions bot added the controller mappings label Oct 30, 2021

Swiftb0y requested a review from Be-ing October 30, 2021 21:06

Be-ing reviewed Oct 31, 2021

View reviewed changes

Swiftb0y mentioned this pull request Nov 10, 2021

Controllers: Add Mapping for Reloop Ready #4513

Draft

github-actions bot added the stale Stale issues that haven't been updated for a long time. label Jan 30, 2022

github-actions bot removed the stale Stale issues that haven't been updated for a long time. label Jan 31, 2022

github-actions bot added the stale Stale issues that haven't been updated for a long time. label May 2, 2022

Swiftb0y added the needs review label Jun 9, 2022

daschuer removed the stale Stale issues that haven't been updated for a long time. label Jun 29, 2022

daschuer requested changes Jun 29, 2022

View reviewed changes

daschuer removed the needs review label Jun 29, 2022

Swiftb0y added 2 commits July 1, 2022 01:14

refactor: reconstruct high-res input val instead of changing the inpu…

2649ef6

…t scaling

Swiftb0y force-pushed the components-pot-arbitrary-max branch from 224f73c to 2649ef6 Compare June 30, 2022 23:14

daschuer approved these changes Jul 1, 2022

View reviewed changes

daschuer merged commit d852fa1 into mixxxdj:2.3 Jul 1, 2022

Swiftb0y deleted the components-pot-arbitrary-max branch July 1, 2022 08:33

ronso0 added this to the 2.3.4 milestone Jul 11, 2022

Swiftb0y added a commit to Swiftb0y/mixxx that referenced this pull request Jul 11, 2024

fix: components.Pot producing wrong result on first value

5973848

This fixes a regression introduced in mixxxdj#4495 and reported as mixxxdj#11814

Swiftb0y mentioned this pull request Jul 11, 2024

fix: components.Pot producing wrong result on first value #13463

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

midi-components-0.0.js: Pot support for arbitrary maximums in 7-/14-bit handlers #4495

midi-components-0.0.js: Pot support for arbitrary maximums in 7-/14-bit handlers #4495

Swiftb0y commented Oct 30, 2021

Be-ing Oct 31, 2021

Swiftb0y Oct 31, 2021

Swiftb0y Oct 31, 2021

github-actions bot commented Jan 30, 2022

Swiftb0y commented Jan 30, 2022

github-actions bot commented May 2, 2022

daschuer left a comment

daschuer Jun 29, 2022

Swiftb0y Jun 29, 2022

daschuer Jun 29, 2022

Swiftb0y Jun 29, 2022

Swiftb0y Jun 30, 2022

daschuer Jun 30, 2022

daschuer Jun 30, 2022

daschuer Jun 30, 2022

Swiftb0y Jun 30, 2022

daschuer Jun 30, 2022

daschuer Jun 30, 2022

Swiftb0y Jun 30, 2022

Swiftb0y commented Jun 29, 2022

daschuer left a comment

daschuer commented Jul 1, 2022

Swiftb0y commented Jul 1, 2022

midi-components-0.0.js: Pot support for arbitrary maximums in 7-/14-bit handlers #4495

midi-components-0.0.js: Pot support for arbitrary maximums in 7-/14-bit handlers #4495

Conversation

Swiftb0y commented Oct 30, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

github-actions bot commented Jan 30, 2022

Swiftb0y commented Jan 30, 2022

github-actions bot commented May 2, 2022

daschuer left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Swiftb0y commented Jun 29, 2022

daschuer left a comment

Choose a reason for hiding this comment

daschuer commented Jul 1, 2022

Swiftb0y commented Jul 1, 2022