Beta release version 3.5 / testing needed

The work on upcoming firmware version 3.5 is almost completed. As the v3.5 brings many changes and I would like to ask for help with testing before it is released officially to all users.

The beta version can be used with It is also the place where it can be downloaded:

Once downloaded, you can proceed as with any other update. Use your credentials to log in to

Note, it is a beta release and it is meant for testing - if you start using it for real, you take the risk of running into issues… possibly

Ok, what is in it:

New features:

  1. E1 can now run presets in parallel. Users can “pin” presets to keep them running even when user is not using them. Pinned presets listen to MIDI data, trigger Lua callbacks, run timers.
  2. Support for using relative CCs with any type of controls has been added. Remote integrations can take advantage of receiving relative CCs from the E1 controls and setting their values using absolute CCs.
  3. control:setSlot() can optionally move controls between preset pages. Preset pages mayt be marked as invisible. User do not have access to invisible pages, therefore they become pools of controls for Lua scripts.
  4. Overlay lists can be created in Lua (using Lua tables) and assigned dynamically to controls.
  5. Lua closures can be easily mapped to parameterMap entries with function.
  6. parameterMap.modulate() function allows modulation of parameterMap entry with external data without tedious procedure of reading-changing-writing parameter values.
  7. Data pipes have been added. They allow passing of float numbers between active presets. This a very early draft, mostly meant to get feedback from Lua developers.
  8. controller.uptime() added to get number of milliseconds since the system start.
  9. Lua message object can be modified now. It was read-only till now.


  1. More stable behaviour in general.
  2. Pot reading improved for smoother operation.
  3. Pot touch calibration improved.
  4. onMessage() callback always called on incoming MIDI.
  5. MIDI indicators fixed.
  6. Sysex template checksums fixed.

Things that I have not been able to resolve yet:

  1. USB Host has troubles with multiple devices connected with hubs.
  2. timers are effected by preset loading and page rendering

Both problems are being worked on.

Starting today, I will be updating docs and providing examples of the new features here in this thread. The firmware will be released as soon as it is confirmed to work fine.

The release is available for mk2 only now. Once it is released to production, I will try to port as much of the functionality to mk1. Unfortunately, not everything will be possible.

  1. How does this affect the memory available to a given preset? Are any limitations imposed on it for memory as the result of adding a pin or is it more dynamic?
  2. Are these forked off the same process with most of the library stuff in memory to take advantage of the os memory sharing?

So you could theoretically use the fact presets are separate os processes to coordinate?

1 Like

all presets share a common pool of memory. It is around 24MB.

Each preset maintains a completely independent Lua environment. It should not represent problems. A basic lua instance eats around 20kB RAM.

Yes, it is mean to exchange messages between presets and to allow development of presets that generate data that can modify values in other presets. eg. MIDI LFO. I will post an example later today.

@oldgearguy came with a brilliant idea of having (A) presets that can generate “modulation/sequence” data. Then (B) ordinary presets that communicate with synths. And (C) intermediate presets that can establish links between A and B. A and B could be shared with the community, while C would be more about environment of individual users.

Note, at this moment only low-level access to data pipes via Lua functions is implemented.


Yeah I was thinking some of the more timery stuff could be offloaded to another process to not get in the way with the main stuff BUT you may also want to gate some of the timery stuff behind the main stuff at times.

Say if you want an envelope triggered by NoteOn. Although both presets can respond to MIDI, you’d probably want the one that’s doing NoteOn handling to signal to the timer one it’s safe to start sending the envelope.

Out of curiosity how many CPUs are on the MKII? Not that it probably matters, most of these things are IO bound not CPU bound so there should be ample time to context switch between them.

Thanks for the great work on this Martin - amazing updates.

Something strange with Preset Banks / Slots:

I tried renaming / resetting them on the slots screen but they don’t get updated on device and I get the above in the web settings.


What browser are you using and which version?

NOTE - I have not looked at any of Martin’s new examples yet -still getting back to the computer…

My original thought was that the (C) thing would be a factory-supplied ‘patchbay’ with 16/24/32/whatever empty slots. The user would then say on any preset ‘read from slot XX’ to receive data and any sending preset would say ‘send to slot XX’ to connect the two.

That way, the OS could manage the number of connections, verify there’s no infinite loops, and allow the users to be able to specify generic read/write locations without having to constantly flip back and forth between presets. At some point in time, the density of the MIDI modulations that can be sent out will either overwhelm the receiving device or be so strung out serially that it becomes unusable.

Infinite loops are a feature not a bug, bidirectional communication is useful.

I could see a case though, for an easy/advanced mode but it’s the lack of guardrails that makes a lot of the cool stuff possible.

With great power comes great responsibility.

That said I think there’s talk about more PORTs in another thread and if you can send specifically to certain ones and not others then it’s less likely to clog up any given one. Also makes the possibility of an extra docking unit with more connectors more of a value proposition :slight_smile:

I generally agree with no guardrails. There’s a time and place for “one big sweet spot”, but a lot of interesting results comes out of abusing the MIDI spec (learned that a long time ago w. the Notron).

My only caveat is – there’s a lot of users eager to jump in and use the Electra One for many different purposes. Doing customer support has been, in some sense, a community effort so far. However, the amount of back and forth trying to debug why some preset(s) are locked up or not doing what they are supposed to so may be a consideration, especially when you add the parallelism and data routing.

For infinite loops, I was not thinking of the useful things like the receiving controls sends back a ‘stop/reset’ after receiving a certain amount of data or modulating the sending control’s speed or something, but rather the more common - “the thing is locked up” which ends up being accidentally routing MIDI out to MIDI in and trying to process it all at full speed.

Yeah I think the default should be a simple view and presets could be marked somehow that you’d know you are entering the danger zone.

I’m going to go off the beaten path with my stuff but I probably wouldn’t share those more broadly as they aren’t plug and play for everyone.

I shared the WindTool preset for code sharing purposes only so some people could look at the sort of thing that is possible.

If there was an Informational/Code Sharing category for the presets I could put stuff there, it also could come with a warning.

Is this file named right?


  1. Copy the update file to the boot folder

Copy the “Controller-vx.x.x.srec” file that you downloaded in step 1 to the “boot” folder on the Electra One disk. Please be aware that this process may take a moment to complete.

I copied it as firmware-. and loaded it from the Electra One boot choices just fine.

1 Like

Thanks I’ll try that in a bit, I’m just always leery with any deviations from the firmware documentation as it’s the riskiest procedure for these sorts of devices.

Edit: Looks like it worked and is just using the filename for display at the boot menu.

Yes, that is something that I was trying to describe in my original statement :wink:

I see it like: this “preset way” is for ordinary users, using on-screen components that will do all the checks. And they will be able to save the preset state by using snapshots. With Lua, I will leave the responsibility on developers.

1 Like

There is one-single core main CPU and another GPU for handling graphics and display.

1 Like

Wow this is great.
So now we can assign CC’s to control any parameter in a template?

Lots of great stuff! I’ll try to look into this soon.

Are there any details on how this function can move a control to a different page? The docs still say it should move the control to the current page but that isn’t the case.

Edit: there’s a demo for this that I didn’t notice before: Beta v3.5 - Hidden pages and moving controls between pages

I am preparing an update of the docs. It will go out along with the official release. For now I just dumped examples and some info to the forum :slight_smile:

1 Like