Thank you for the detailed description of the solution. I had overlooked the troubleshooting section. Since you wrote that USB disk mode doesn’t work on some Windows 11 systems, I tried it on a couple of other W11 PCs. On one of them, fortunately, the procedure worked.
But now the USB disk mode still doesn’t work on my music production PC. Isn’t there a solution for that? Because I want to use this for storing the presets for the XOT Ableton Remote Script. It’s a bit cumbersome to use a different PC for that each time.
You had not, I added the document when I was writing the reply for you.
I am already working on a solution for that. It will be possible to upload the files from the browser as well as I am finding to resolve that bootloader issue.
first of all - thanks @martin for all the effort you put into this release. I’ve been enjoying the new features and the overall stability of the 4.0.0 release.
Question (might just be a documentation issue) - I see that I can call:
midi.sendControlChange(port, channel, controllerNumber, value)
and
midi.sendControlChange14(port, channel, controllerNumber, value, lsbFirst)
However, there only appears to be a callback for the 7 bit version:
However, there only appears to be a callback for the 7 bit version:
Currently, the Lua callbacks are triggered for “low-level” MIDI messages. The reason is that the callbacks are executed as soon as the messages arrive. Detection of messages such as 14bit CC or NRPN is done one level higher (and later) since Electra needs to understand the context of the message (ports, channels, previous messages). I will look at the code to see how I could resolve that and add callbacks for 14bit CC and (N)RPN. I will add the idea on the list at Lua API - stuff to add?.
The way the faderbank sends the 14 bit CC value is via 2 different CCs, 32 apart. So the messages coming into the Electra would be (for example) fader 1 is MIDI CC 10 and if it is set to 7 bit mode, it sends values 0 to 127. If I set that fader to hi-def mode, now two CCs are sent when I move it. CC 10 and CC 42. The 14 bit value is spread across those two CCs.
Note that I need to get to the computer to verify all this later today as well how the 14 bit value is distributed. In theory, I can look for the second CC and combine the data value.
That’s the standard way the MIDI protocol handles 14 bit CC messages. Control change numbers 32-63 are meant to be LSB for control change numbers 0-31. Control change numbers 64 -127 are not supposed to be used in a 14 bit way. The 14 bit value is distributed with the MSB incrementing one unit after the LSB has incremented 127 units. Hope this helps and it’s clear enough (not a native English speaker) and thanks for all the great work!
Yep, it all maps as discussed. The big problem here is that the resolution coming from the Faderbank is very coarse in 14 bit mode. Partly due to the CPU being used plus the limits of a physical slider.
The E1 can generate 14 bit easily though.
Processing incoming MIDI to determine if it’s a standard 7 bit CC or the first half of a 14 bit CC is a bit tricky and requires processing more MIDI data, so not as great for real time response.
I have a couple of the Atov version, and it uses very smooth Alps faders. The original i believe use cheap Bourns or alpha faders that use carbon as the resistive material inside, as opposed to conductive plastic in the Alps. They feel completely different. Either way voltage is a continuous function, but damaged carbon track, which is easily damaged by pressure on the fader actuator on those cheap carbon faders, could introduce erratic and non-monotonic readings.
A recent 16nx running 3.1.0. Looked over the firmware code and saw the ‘shift left 2’ to filter it the low 2 bits. The 0-127 is very smooth and evenly increments. The had a chance to measure the voltage coming out per fader. Paid under $200 for 16 faders, so still quite happy with the purchase.
