Electra One version 5 on beta.electra.one

[martin]

My work on the firmware and web editor, originally aimed at version 4.2.0, eventually grew into a major update: v5.0.0.

This release is a collection of my feature ideas, unfinished work from the 4.x releases, and reflections on what has been discussed here on the forum.

The beta version is intended for testing, experimentation, and feedback. I will be very happy to have users try it out, but at this stage it should not be used for day-to-day work unless you are willing to accept the risks.

Presets created with the beta version of the editor cannot be used on controllers running firmware older than v5.0.0. This is intentional. When editing an existing project in the beta editor, users are warned that the preset will be upgraded. In other words, to use beta, you must upgrade to 5.0.0 beta firmware. It is available in the beta.electra.one.

For now, I recommend working with copies of your projects and keeping them private.

Changes in the web app:

• added support for multiple controllers connected in the same time. Users can select the controller that the editor will work with.
• added faster way to navigate and organize presets in the controller (Preset slots and Current menu items)
• finished implementation of snapshots, captures
• fixed project / preset imports
• added an option to backup and restore projects to local files
• allowed users to change the passwords and user name in the app
• improved layout of the editor, allowing to open control editor in the splitview tab
• added basic/expert edit mode switch, Basic exposing cut down functionality
• captures extended to allow recording a sequence of midi data
• allowed groups to listen to a MIDI data and reflect upon it (overlay list assigned)
• allowed controls to listen to events such as knob touch, know switch presses and releases.
• added an option to customize text/font for certain types of controls/groups (where it makes sense)
• default control values names can be changed in the preset.
• extended the Lua API
• improved the Lua debugger
• added take over mode for Remote knobs
• introduced (beta feature) Surfaces - Remote knobs allowing to manually assign up to 128 CCs to preset controls

Documentation will be updated when the 5.0.0 leaves the beta phase. The change log is not complete, I will make more edits later.

please keep the beta 5.0.0 discussions here in this topic

note on the opensource: beta 5.0.0 firmware has the proprietary Renesas source code removed. It will be the basis of the opensource firmware. We still need to tackle the USB VID/PID before it goes opensource. Regarding the repository, we decided to follow the proven path of Synthstorm Deluge - we will host a community driven repository.

last bit, the firmware is 5.0.0b, it is an early beta, some things may not be 100% okay and I expect compatibility issues. That is the area I will focus on now.

To update your controller to 5.0.0 beta, make sure it runs 4.1.4 first.

[martin]

https://docs.electra.one now include the documentation of 5.0.0 beta. Handy for anybody who wants to test or preview what is coming…

Use the version selection to switch to the 5.0.0 beta docs.

User guides are human-written, ai assisted, and heavily human edited. Developer documentation is mostly ai generated. It is fairly complete, but still needs editing, cleanup, and more prose. The important technical information is there, though.

[jhh]

Excellent. Now checking whether changes to the remote script are needed to support 5.0.0 and whether it offers opportunities for new functionality. One thing already pops up. For ‘Execute LUA command’ (SysEx implementation | Electra One Documentation) it says that

commands shorter than 65 bytes are executed significantly faster than longer ones.

Is that shorter than what it was in 4.0.0 (for which I use 128 in my code) or was it actually always this low?

[martin]

It is a regression, I just extended it to around 300 bytes (aligned with the longest message passed internally). To explain: under 300 bytes, it is processed with a pre-allocated buffer, above that, memory needs to be allocated on the heap. Slower, but still it is rather fast. The fix is in the 5.0.0d, I am deploying that version to beta now.

[martin]

firmware 5.0.0d is now on beta.electra.one.

There are a few notable updates on Documentation of 5.0.0 beta :

1. For users developing more complex presets (@oldgearguy @NewIgnis @jhh @SimonORorke @moss @Phommed @Mint-Gecko @Electrolove and many others), there is now a description of Electra One’s internal architecture It explains how messages and events are processed internally, including their order and priority. The document reflects 5.0.0 firmware, but the overall architecture is fully consistent with all previous firmware versions.
2. The Tutorials section has also been expanded. It still needs doing, but it already serves as a useful overview of what is new in the 5.0.0 release.

@NewIgnis @kiwigrass and other susing the “versions” along with their presets: take a look at Revisions, Versions, and Releases It describes how to create versions of your presets and official releases - allowing you to work on your preset while other users use stable official version.

@Phommed reflecting upon your input on the debugging the Lua script.

@HaPe might want to read Control events.

Note, it all is still beta. Be cautious, test stuff on copies of your presets. Of course, you can always revert presets back, but you do not want to waste your time on it.

and a small teaser for 5.0.0.

We are about to start shipping another batch of Electra One Mini, it will be shipped with the 5.0.0 on board.

[kiwigrass]

The 3rd and 4th links were dead for me. The first two worked.

[martin]

reload the page and try again.

[kiwigrass]

Love the scheduler functionality in 5.0 for patch requests etc. Frees up the timer function for more fun things without having to perform coding contortions. Nice!

[HaPe]

Thank you so much for sharing. That looks fantastic. I just wish I had more time right now to take a closer look at it. Hopefully, that will change soon.

[kiwigrass]

Successfully replaced the timer.onTick() callback I was using for parsing all patch names on the Peak with schedule.after(SCAN_PERIOD_MS, scanNextPatch) or scanHandle = schedule.every( SCAN_PERIOD_MS, scanNextPatch ). Both worked perfectly!

[kiwigrass]

@martin what does this error message mean: ParameterMap::forget: cannot remove file: ctrlv2/maps/ssJrEXmHDKsO0Tjokp0S.map ? Running fw5.0.0d

[oldgearguy]

With all the newness in the recent releases, it’ll be great to get back to working with them.

At the moment, still have much coding burnout, so taking a break. You know it’s bad when untangling pachbay cabling after a move is more enjoyable.

[HelenMarsh]

The scheduler examples make a strong case for moving periodic patch scans out of timer.onTick(). For beta testing, I’d keep one copied preset per experiment and log the interval plus the returned handle, especially when switching between schedule.after and schedule.every; that makes it easier to distinguish a duplicate callback from a missed one. For the ParameterMap::forget warning, I’d preserve the named map file and report the exact preset and firmware combination rather than deleting it manually, since that path may help reproduce the issue. Once a patch is stable, I use a frequency reference to keep audio checks consistent across presets.

[martin]

I am starting to wonder whether @HelenMarsh is actually human and an electra one owner… are you Helen?

[martin]

Router Lua scripting tested and okayed to be part of the 5.0.0. Aiming at the official release of 5.0.0 next week. And I know, I am drop feeding here..

[eusti]

This looks really nice, @martin ! Looking forward to adapt this for the Mirage SoundProcess project I’m working on…

[kiwigrass]

parameterMap.get(deviceId, type, parameterNumber)

Retrieves the current MIDI value stored in the Parameter Map entry. This function is equivalent to calling message:getValue() on a Message object with the corresponding attributes.

MIDI_VALUE_DO_NOT_SEND is 16537, which is not a MIDI value: it is what an entry holds before anything has been set, and what this answers for an address the map does not know. Compare against the constant rather than the number.

I was wondering why I was getting 16537 error messages. Now I know! Actually a useful debugging tool when trying to get map data for things that didn’t exist.

[kiwigrass]

@martin Is that parameterMap.updateValue no longer requires a page change to repaint controls. Hooray! Its the perfect thing for populating controls with parsed data without sending it all back to the device. Thanks.

Also, parameterMap.modulate is now my new best friend. I had been using parameterMap.set in virtual lfo blocks. Now less CPU work per tick and uneccessary callback churn. Far fewer ticks too late messages.

[martin]

the 5.0.0f is now on beta.electra.one. I verified to work ok on Mac / Windows / Linux. I am now waiting for confirmation from a few users who work on DAW integrations and complex presets. Once they okay it it will become an official 5.0.0 firmware release.

Part of the 5.0.0 functionality has been successfully ported to Electra One mk1. Therefore, the mk1 firmware update will follow shortly after the mk2/mini firmware is out.

A few demo presets will be provided with the 5.0.0 to demonstrate the new (and already existing) features:

1. MIDI remapping preset

2. LFO preset - sending output to a DataPipe or a as a CC

3. MIDI capture editor - a capture is a recording of MIDI (using the SMF format). The sequencer preset allows editing and playback of captures

4. MIDI monitor

The main purpose of those presets is to demonstrate that Electra One presets can do a lot, especually when combined with the custom controls. @Roomi did quite some work in that area.

All pictures here are screenshots taken on the controller with the new function in the web app:

[Roomi]

Updated 4.1.4 to 5.0.0f today and ported my 20-widget library over.

The nine animated widgets moved from timer.onTick to schedule.every, one named callback each. I checked two jobs side by side and both ticked 38 times in two seconds at 50 ms, no interference. That unblocks composing several animated widgets in one preset, which I could never do before. For the record timer is still there and still works, so nothing forced the move; I’d understood from this thread that it had been replaced.

While porting I hit something that isn’t a v5 regression but is worth a line of firmware. Nine of my twenty widgets got no response at all from the Lua REPL over SysEx. No ACK, no NACK, no log line, nothing. The cause was non-ASCII characters in the source: em dashes in comments, a degree sign in a readout, a middot used as a separator. MIDI doesn’t allow data bytes above 127, so the message is malformed and simply disappears. I stripped 214 of them across 29 files and all twenty answered.

A NACK with a reason when the payload contains a byte above 127 would turn a silent disappearance into a two-second diagnosis, and documenting the 7-bit constraint on the Upload Lua page would help. If it’s cheap enough to land before release, it’s worth it.

Two smaller things. The REPL occasionally drops a reply and answers fine on an immediate retry, with the device counters showing 276 dropped outgoing messages at idle. And schedule.whenNotes isn’t documented anywhere, while the luaext docs page still serves the 4.0 text with no schedule module in it.

One last thing: Chrome crashed on my machine during the firmware update. The controller was unaffected and came back on 5.0.0f. I didn’t capture anything useful, just flagging it in case someone else hits it.