Ah, it’s great to hear someone else with a programmer brain working with this device. I’m not much of one, but this script is an exercise in my first open source project.
I’ve been testing cases for building out the logic and hoo boy there are many cases, some of which have no real solutions atm. Basically, your last held note blows out previous notes, whether reducing their magnitude or silencing them entirely. This means holding two notes will reduce the first pressed note greatly, while the second note will be roughly 1/3 its magnitude. Each additional note reduces the range of aftertouch values for previous note, and after 4 notes it’s very difficult to get any output. What is even more annoying is pressing hard will completely blow out the other notes aftertouch data, so with each note, you have to press lighter and lighter to not blow out their output. You might have already discovered this with your discussion with the manufacturer.
What this all means is the best strategy is to use values 0-30 for aftertouch data and throw out the rest. This reduces the dynamic range of aftertouch for single notes but allows each key to be sensitive, up to around 4 notes in the same horizontal zone (as the player adapts to this reduced range). Alternative strategy one is to detect colliding aftertouch data (this can be detected by a sudden drop in aftertouch output for a note, followed by another note on event) and use its output for all notes, until the collision stops. This means single notes will have a lot of dynamic range, and you can modify your playing to play across all 4 horizontal zones to avoid collisions. Alternative strategy two is to detect the collision and replay the last inputs. This might be interesting, especially coupled with a weight factor and inertia, to add a lot of dynamics to all the notes. You should also be able to adapt your playing to make ad hoc LFO effects.
Ultimately, we are still limited to 4 notes per horizontal zone, and 4 horizontal zones, but judging by the play-styles of many MPE players, that might not be a problem (also probably why Joué decided to set up their boards this way). My main critique of Joué is that simply making the limits transparent to players like us would have gone a long way in fully utilizing our boards, regardless of firmware limitations. On that front, I tried finding a whitepaper on the multiplexer chip that takes the board input, to maybe see if that was the source of the problem, but I came up with nada.
I think I might make a separate thread for ongoing discussion of development, if nothing else to keep me sane while I grok a new skillset. I think my first target is my idea for the “best” strategy, and apply some inertia function to help make up for the lost dynamic range. I’m kinda impressed by your js script so it’s inspiring to keep working on this project. I intend to keep the script extremely simple and performant so I can use it on my rpi 0 which takes care of the wireless connection currently. I chose python because I can use it natively in FL Studio as an instrument handler, making development a bit easier, otherwise I would love to do it in js.
