I have lagging response on the E1 Mk2.
It has nothing to do with version 4, as I had it before, but I didn’t investigate it till now.
The following behaviour is noticed on the Mantis preset Electra One App. :
When starting the E1, it happens a lot of times the controls aren’t changing via the parsing. However the characters of the preset name stored in the Mantis are set on the E1, so the SysEx string is arriving. it’s just that none of the controls adapt themselves to the incoming data.
Then, when I reload the preset from the PC, all works well again, but all incoming MIDI data is delayed, whether it’s note data or Sysex.
After the first preset reload , the delay is 2 counts, after the second reload is its 4 counts, third reload the delay is now 6 counts.
It doesn’t matter if the E1 is directly connected to the Mantis Synth (via DIN MIDI) or is connected with a Mio XL in between. When connections are established via Mio XL, I can look at the passing traffic, and we can see the Mantis outputs its MIDI messages without any delay.
So why is the E1 waiting with processing incoming messages? Why does it not have its controls parsed as intended as long as the preset in not reloaded? And why is that delay worsening with each additional preset reload?
I will take a look at this. I am busy with version 4.1.2 right now, which is a bug-fix release for recently reported issues. I will try to get a fix for this in there too, if I can reproduce it. Will use the steps you described.
Electra.syx: this contains 8 patch dump requests (8 bytes), followed by their 8 responses (114-115 bytes). These are patches 00 to 03 from bank A, followed by patch 00 to 03 of bank B. HOWEVER: this is a recording of the MIDI SYSEX as it is provided at the MIDI OUT of the Electra One, and I noticed that the responses are of incorrect length!
The original Sysex as output by the Mantis is always 116 bytes. So I redid the exercise: The second recording Mantis.syx is exactly the same but this time the SysEx is recorded at the MIDI OUT of the Mantis, and here we get the correct 116 byte length.
Especially for these recordings, I’ve let the Electra One route any DIN 1 IN to its DIN 1 OUT. And I now see it is not only a delay in the transmission; the routed through data is also not following the same note on/note off (or aftertouch) message rhythm as it was offered, but it is retransmitting these at a (slower) fixed pace between any two messages (I can count to 3 for a group of 25 messages). A played sequence of 1 second of aftertouch messages, may for instance take 4 seconds for the E1 to retransmit them at its MIDI OUT.
I am having troubles with replicating this. I will describe here what I have done. it might help to spot a difference in what you do and what I do.
I do not have Mantis. So, I pretend to be Mantis by sending your sysex messages to Electra One MIDI IN using the computer and MioXL. ie. I send the messages:
from the computer to MioXL USB device
MioXL routes the messages to one of its MIDI DIN outputs
these messages go to MIDI IN 1 on Electra
Then, I have my Electra One configured and connected, so that:
it forwards all messages received on MIDI IN 1 to MIDI OUT 1
MIDI OUT 1 is connected to mioXL MIDI DIN port
mioXL sends those messages to my computer over USB
This way I can send your MIDI messages to E1 and see what comes out of E1 on the computer.
I also created a file with a bulk of 64 note on and off messages. using the note number to distinguish the order of messages.
my observations:
no matter how many times I send the 116 bytes sysex to electra, I always get 116 bytes out and the preset updates on the screen. I did that immediately after the boot, as well as after preset reloads. I did not see any difference there.
I rebooted my E1, send the 64 messages to it (via the connection scheme described above). I received all messages back on my computer within around 60msecs. I sent the patch dump, everything refreshed as expected. I ran the 64 messages again, I received them in around the same time of 60msecs. I reloaded the preset. I ran the 64 messages, again 60msecs. I reloaded the preset again. I sent the 64 messages, again 60msecs.
I repeated this many times, the forwarding time stays the same and the order of messages is correct.
Of course, this not identical to what you do but I tried to get as close to it as possible.Let me know if you have any suggestions on how to adjust must test setup. Thanks!
MIDI messages inbound to the E1 is as you describe.
But I have no route DIN-MIDI port 1 IN to DIN-MIDI port 1 OUT. instead it is a DIN-MIDI port 1 IN to USB device Out.
That USB is connected via a powered Elektro Overhub to the Windows PC. The connection is use for two things: uploading presets to the E1 and monitoring what E1 received.
The route "DIN-MIDI port 1 IN to USB device Out. " is a temporary one for the sake of monitoring. I only set this up a few days ago.
I’m a bit lost! As you know, I don’t code — I just describe what I want, and ChatGPT creates the code for me. Then we fix any bugs, inconsistencies, design together until it matches my goal exactly.
Now I’m wondering: “Is the lag on my E1 fader coming from the Lua code , or is it something else entirely?”
And also: “Should I try to look into it now, or just wait for more experienced people like Martin or NewIgnis to see what’s really happening?”
I won’t be able to work on it for about a week, but I’m so excited to get back to it right after that and make it work perfectly! .
I’m a bit lost! As you know, I don’t code — I just describe what I want, and ChatGPT creates the code for me. Then we fix any bugs, inconsistencies, design together until it matches my goal exactly.
.