I was able to upload this preset: Electra One App
Can you give it a try?
Did you see this?
Yes. It has been working before. Just as a test I also removed that option and I am getting the buffer overrun error, so it is definitely still doing something.
Then I can’t help you, but @martin can 
Is it possible to upload presets when ELECTRA NOT CONNECTED?
Maybe I misunderstood but I took it that your Electra was detected in Firefox but uploading didn’t work.
If your Electra is detected in Firefox, then try to send the preset I linked to it and report back with the result.
No, sorry if I didn’t explain myself well. Firefox doesn’t detect it at all, and Chrome shows this:
What I had said is that, regardless of what the browsers say, PipeWire and Bitwig handle the E1 just normally as a connected device.
From the pictures I’d say that the MIDI ports are detected just fine. They can are recognized in the browser too:
I’d suggest to try to transfer sysex manually to the controller and observe what it sends back.
Do you have sendmidi / receivemidi tools installed?
Ok, do you happen to have copy&paste instructions or similar at hand? 
No, I’m one of those who went to Windows whenever had to transfer things to/from a synth just because that’s what their instructions supported…
(PS: not urgent; I can keep working with Bitwig just fine.)
Just as a sanity check where I uploaded a preset SysEx file directly without the browser and it worked as expected.
Here is a preset file in SysEx format: preset.syx (30.7 KB)
If you have a librarian application, you can try to upload it with that, otherwise you can upload it via command line.
- Find the Electra control port
$ amidi -l
Dir Device Name
IO hw:4,0,0 Electra Controller Electra Port
IO hw:4,0,1 Electra Controller Electra Port
IO hw:4,0,2 Electra Controller Electra CTRL
Note down the hw:X,Y,Z part because you will need it in the next steps. X, Y and Z will potentially have different values on your machine.
Also make sure that nothing else is using the CTRL port of the Electra, by closing all other apps and the web editor.
- Start listening on the control port
$ amidi -d -p hw:4,0,2
- Send a preset as raw SysEx
$ amidi -p hw:4,0,2 -s preset.syx
The preset appeared on my E1, and this is what the E1 sent back:
F0 00 21 45 7F 00 6C 75 61 3A 20 74 72 61 6E 73 70 6F 72 74 20 64 69 73 61 62 6C 65 64 F7
F0 00 21 45 7E 05 F7
F0 00 21 45 7E 01 00 00 F7
Translated from SysEx the response is:
log message - lua: transport disabled
preset list changed
ack
Uploading presets from the browser fails of course.
Whatever this is, it only seem to affect SysEx on my machine. If I open Web MIDI Test, select an E1 port under Receive MIDI and start turning knobs then I can see the messages coming in both in Firefox and Chrome.
@icaria36 could you perform the tests above and report back with the result?
1 Like
Yes, I could reproduce all your steps. Still, I can´t connect via browser.
Also, I should have thought this before. Your preset took the slot of the Driven by Moss preset, which is now gone. I could stioll use the E1 with Bitwig normally, and now I can’t. It’s ok, I don’t need to deliver a Grammy this week. But how can I send the DrivenByMoss.epr preset to the E1 via command line?
Edit: never mind, I will use that Windows partition that I use for emergencies.
Ok, progress (I guess?)
I got exactly the same screen with Chrome on Windows (last official release). I was so confused that I opened Bing (which I never used, and… bam, same screen.
Then I remember that I had logged in to the beta version. So I logged, and… that works, and I got DrivenByMoss back.
Strange, or maybe not. Maybe the beta leaves some cookie or something?
EDIT: nevermind, beta on Ubuntu and Chrome doesn’t work for me. But I’m starting to think that this might be related to cookies or something, more than Ubuntu or Chrome. Sorry for the noise.
The steps were not supposed to fix the problem, just narrow it down. Looks like it is something related to browsers and SysEx.
I have a Novation Launchpad and I will try that next to see if it is specific to the Electra somehow or it is a general problem that would likely affect other SysEx based workflows.
1 Like
I have been testing uploading presets through a variety of browsers, with the usual increase in buffer size in the kernel module, and I observed the same thing on EndeavourOS (Arch based distribution) with Firefox 119: small presets can be uplodaed but not larger ones.
I am curious about how you managed to turn a E1 preset into a syx file to be sent through amidi on Linux, would you please mind sharing your process?
I’m not near a computer but I will try my best.
The SysEx file is basically just a file with all the SysEx bytes in it in binary format.
I looked at the documentation for the bytes I needed to send: SysEx implementation | Electra One Documentation
You can get the present file from the app and you need to write the SysEx bytes + the bytes from the preset file into a new file, in binary format. You also need to make sure that the bytes are not larger than 127, otherwise it won’t be a valid message.
There are more ways to go. One is edit the file as @szszoke described above. It is important to make edits with an editor that handles binary data.
The other is use any type of midi monitor or midi data capture application and hit the “Send to Electra” button in the browser. That way you will be able to catch and save the sysex data of a preset upload. It is also a way to see if the data is corrupted already at that moment.
as for the apps receivemidi is available for linux/macos/win. Midi Monitor and Sysex Librarian are good options for macos. MidiOX on windows.
1 Like
I have the same problem since upgrading to 23.10 using kernels with version 6.5.x.
After some fiddling and also trying to adjust the midi output buffer as suggested earlier ( and which helped when I had electra connection problems back then) which didn’t help, I started the system with an older kernel from before I upgraded to 23.10.
That was a version 6.2.x, and it worked.
I also had the same effect with Novation Components, which does similar things as the electra one app.
There it was detected that a novation product was connected, but unable to do any of the management actions. It showed some error, dont remember the exact wording.
These problems are reproducible on two Ubuntu 23.10 systems I have running Kernel 6.5.x and go away reproducibly when booting back into an older Kernel.
I tried vanilla Kernels from Kernel.org and all versions from 6.5. and above show the same behaviour.
Problem is there are no other errors I spotted anywhere that seem to be related to the poblem - not in dmesg, not in journal.
I reported a bug about it, but I think it’s difficult to reproduce for Kernel developers, because it requires only occurs when having the real device and trying to use it with this specific web app.
osprober-gnulinux-/vmlinuz-6.2.0-1012-lowlatency–22c25e4a-7670-4597-b84d-646f50a4b5b3
I’m a bit in fear that we will have difficulties in the future to use the electra app (and others) on current and upcoming Linux / Kernel versions, so i will try to do what I can to analyze this further - at least make it reproducible so Kernel hackers without the specific devices will be able to check it out somehow.
There are a few things to do to get there - not necessarily in that order:
- test with another distributions but also a Kernel 6.5+ that currently seems the point when the problems start
- test Kernel versions 6.3 and 6.4 to better understand which version introduces the behaviour
- test with more apps - I have one more device that does similar things, the management software for the Blokas Midihub - it’s different in terms of being a native application that’s not webMidi, so it’s quite interesting if it has the same problem
- get in touch with the kernel sound subsystem developers
- file a proper kernel bug
1 Like
interesting - how do you use Firefox with electra app / webmidi?
I thought it doesn’t support it, but reading your comment I checked again, found something that said it is possible since version 108 or so, but neither electra nor Novations components work for me at all in Firefox.
I just searched around quite a bit, but did not find a usable explanation what I need to do to enable it. Just many articles telling how great it is that it’s now available and the original bug ticket where it has been developed…
I’m a bit curious if it even works with the standard snap installed firefox, because at least for chromium that doesn’t work.
EDIT / ADDITION:
I remembered trying to use webmidi with the standard snap installed firefox might not work just as it doesn’t with the snap installed chromium.
So I tried it also with a firefox installed locally via NixOs (which does work with chromium ) - but smae thing.
The docs of the webmidi api say something like " API access is gated by installation of a site permission add-on (user prompt), secure context, and Permission Policy: midi."
is necessary to use webmidi in firefox, but I dont understand what I can do to get there
Gosh @henning, thank you for putting time into this and for filing the bug to Ubuntu (which I seconded, and maybe this helps bringing it to devs’ attention). This is deep (I mean, deep in the software stack).
Maybe the problem is less about devs being able to reproduce (it’s a regression, so someone caring maybe could find it even without testing with actual gear) and more about finding the Kernel developers who would care. Let’s hope this bug affects bigger fish, like whoever was paying for the development of MIDI something that broke this feature.
All this assumes that what broke was a MIDI component and not some middleware talking to the browser, or… Well, at least I could connect with Windows and install DrivenByMoss again. With this, I should be ok until the next firmware/Moss update.
1 Like
If you can compile your kernels, you could try to find the commit that broke things via bisecting.
You would need a known good kernel version and a known bad kernel version. You would then start compiling the individual changes in-between until you find the exact commit which broke things.
My hunch is that something broke when MIDI 2.0 support was merged so I would start with that.
1 Like