I don’t know if I am missing something. When I tried to send a preset to the Electra One Mk II it seems to send the preset but the web editor shows the “thinking” dots on the top left by the preset name and no longer let’s me send the preset. In order to get the web editor to see the electra one again I have to both unplug and plug in the electra one again and completely close chrome and reopen. It then sees the electra one. When I send a preset it doest the same thing. After trying different cables, plugging into new ports, deleting the browsing data and caches from chrome, restarting the computer, and sometimes just leaving it for a while it will work as it is supposed to for a while but at some point it will stop working again. There is no discernible pattern to the troubleshooting that seems to work. I have tried removing the sd card, reformatting, and copying the sd image again. Still doing the same thing. I am lost. Also the snapshot web editor is not working as expected. I don’t know if that is related. That is not as important. Does anyone have any ideas?
I finally found a method that at least gets back going. If I load the boot loader I see firmware 4.0.0 as the only option. If I click that then load up the web editor, it tells me to update to newest firmware. Once I update it starts working again for a while. But at least I can continue working until it stops working again.
That’s happened to me on and off forever, with my old mk1 as well. It’s very frustrating and I can’t see a pattern to it. I guess the system just isn’t very stable
When you hit the “Send to Electra” button, the browser will send a SysEx message containing the preset to the controller, and the three animated dots will appear in the same time. They remain visible until the a confirmation that the preset was received by the controller (ACK SysEx) is received by the browser. Along with the ACK SysEX, the controller sends a SysEx notification that its internal preset list has changed - causing the browser to ask for the new preset list by exchanging further SysEx messages. If there is a Lua script, there will be one more round - browser sending a SysEx with Lua, three dots activated again until the receipt of Lua is confirmed. So it is quite an intense SysEx message exchange.
The issue of the three dots remaining visible and the browser being unable to receive any further MIDI has been reported several times since the Electra One project started. The major difficulty here is that I was never able to replicate it, neither on MacOS, Windows, or Linux. If I am not mistaken it seems to be happening more (or only) on Windows. @Bubasis @davehouse What OS are you using?
From what has been written on the topic so far, I expect that it is not that the browser crashed, instead I would expect that there is a MIDI processing browser thread hanging in the operating system - preventing the browser or browser MIDI to be used again or restarted. Restarting the computer does the job. It would be quite interesting to see if a hanging chrome process (task) is present in the Task Manager (CTRL+ALT+Delete) and if killing that task would unblock Chrome.
A good thing is that I noticed that something similar happens when mk2 is disconnected while working with preset editor and the Mini is connected instead. Not that it would froze the connection, but the three dots stay shown after the subsequent preset upload until the page is reloaded. I will be working in that area of the application, I am hoping to discover some pointers…
With the knowledge I have I assume this is only a coincidence. You are trying hard to find a solution to that irritating issue and you are seeing a solution while it might not be. But, I will try to look at that too.
After the 5 years of developing the preset editor as a web application I have mixed feelings. I really like the idea of sharing presets and being able to deliver changes without having tens of different preset editor versions installed on the computers around the world. On the other hand, the issues like this are really hard to resolve or even replicate. I developed a firmware/preset uploader application using the Juce at the very beginning of the project. I might pick that idea up again because all SysEx communication was there fully under my control.
I understand. I also encounter this a lot. The solution then is to close the Chrome Browser under Win 10, reboot the E1 and start again. In 90% of all cases this fixes the matter. Sometimes I need to reboot the PC though.
But this is an improvement from a year ago where I had to constantly reboot the PC. I then changed the Anti Virus, because of driver issues with Novation devices, but no proof these things were related.
I typically use Windows, but I’ve encountered the issue on MacOS as well. As NewInglis says, force-quitting Chrome and rebooting E1 fixes the issue without the need for a PC reboot most times.
I’d welcome a desktop app to edit E1 but I appreciate the work that goes into such a thing. Even better would be basic preset editing on the device itself 
I also have this happen at least once an editing session on Windows 11. For me the solution is to kill chrome processes using the task manager and restarting chrome.
To make the confusion even bigger: I´m using also Win10 and have this issue when using Chrome. But when this happens and I change to Opera browser everything is ok…….
Dieter
I think it actually confirms that the MIDI processing in chrome is stalled for whatever reason. I assume Opera will create a completely new process and new connection…
Thanks (to all of you) for good pointers.
I assume you’re using webmidi? If yes then the w3c is working on it. Pete from Windows said so in the yt video from Namm about midi 2 on windows. He also mentioned security concerns
I made a few changes to the way that the web editor exchanges data with the controller. That updated version is now available on beta.electra.one. Besides the changes in the communication and behind the scenes, the beta.electra.one has a new “Session” tool added:
when opened it displays all queued, running, and failed communication transactions between the editor and the controller:
it also allows to adjust the rate of data exchange handshake by modifying the delay between individual sysex messages. until now, it was running at maximum speed, meaning it sent a new sysex message as soon as the previous was confirmed by the controller.
I set the default to 100ms on beta. It is a quite some pause, yet, one hardly notices it when uploading presets. At this rate, you will not see much there. It is simply too fast. But when things crash, I expect some data will stay in the queues. When you set the delay to 1000ms and above, you should be able to observe individual messages being exchanged. The delay can be adjusted by changing it in the form at the bottom of the sessions window:
Note, you must hit Enter key when you finish edits of that field.
Now, I am wondering what the impact of this would be on the issue we discuss in the this thread. I tested it on my win 11 and macos. As always, I could not replicate the problem. I would be super happy if anybody who is experiencing the problem gave it a try. Have the session window open when uploading the presets. (you can drag it around so that it does not restrict your view). If the browser stalls, it would be interesting to see if there are any transactions stuck in the session. When it happens it would be also great test if the issue persists with different (longer) delay time.
When testing it, make sure you start with only one instance (browser tab) open. If the issue does not pop up, try opening more tabs in the same time.
Awesome. For testing purposes is it possible to have an option to have the session view open automatically when a preset is opened? My hanging incidents are not frequent, and I’m almost sure the next time it happens I will have forgotten to have opened the session view. Or, will the session view collect que data even if not open?
unless your browser goes completely frozen, you will be able to open the sessions window when it happens and see the state of the transactions there. The application monitors the communication all the time, the window just displays it.
Having a lot of issues with connecting to Electra One. Some mix of the following steps repeated multiple times can resolve it, but not always. Been at it for a full day now and not able to connect.
- Unplug/plug in E1
- Press reset button
- Restart Chrome/Edge
- Restart Computer
- Uninstall E1 driver/ plug back in
I’ve searched the forums and found the following info:
My computer is a Surface Pro 11 running Windows 11- not sure if that changes things.
I’m about out of my depth here, but searching the forums I also saw that E1 uses Bome Midi, not sure if this is an issue considering I’ve been able to connect many times before.
Any help is appreciated.
I need a bit of extra explanation here:
Did it work for you and then it changed and you have issues now? or have you had issues since you received your controller?
There is no E1 driver. Electra One is a MIDI class compliant device and 100% relies on the web midi implementation in Chrome based browsers. What do you mean by uninstalling E1 driver?
Yes, I bought a license for Bome MIDI, but it has never been really used. I hoped Microsoft would resolve their issue instead of me doing that. It seems to be happening these days as they are rolling out the new version of their MIDI driver.
There’s an issue affecting some setups (most frequently on windows). I recently made changes that could help to resolve or at least identify the issue. They are available on beta.electra.one. If you had a moment we can try / review it together using the chat system on this website. I can be available tomorrow.
@kiwigrass @davehouse @HDV @NewIgnis have you had any chance to test the changes I installed on beta.electra.one?
Been testing all day but haven’t had a hang event yet. I could be wrong but I had a feeling it was happening after I had connected another midi device. It is possible that the new midi services implemented in windows 11 has resolved those potential conflicts. But will keep testing.
It’s been this way since the beginning, started with Edge browser, that started to work less and less consistently. Moved to Chrome, but that seems to be less consistent now too.
Started with Opera today.
Driver may have been the wrong term- looks like I uninstall the device when I get this symbol in device manager.
Noted on Bome. Was trying to self serve the issues before coming to the forums!
I’ll try the beta site tonight. Thanks!
@martin Success?! I managed to hang the web app sending a preset to the E1. As I suspected, it happened after I opened another app that communicates with a device via sysEx. Attached is the screen shot of the session view
After closing the other app and restarting the web editor I was able to send.
Brilliant! What was the other application? And will the same happen when you open second browser tab?
It was the Expert Sleepers configuration tool for the FH-2 eurorack module - basically that module is how I get midi into my racks. Of course, I have not been able to replicate. I will now try by powering off and starting from scratch.