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 https://beta.electra.one/. It is also the place where it can be downloaded:
Once downloaded, you can proceed as with any other update. Use your app.electra.one credentials to log in to beta.electra.one.
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:
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.
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.
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.
Overlay lists can be created in Lua (using Lua tables) and assigned dynamically to controls.
Lua closures can be easily mapped to parameterMap entries with parameterMap.map() function.
parameterMap.modulate() function allows modulation of parameterMap entry with external data without tedious procedure of reading-changing-writing parameter values.
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.
controller.uptime() added to get number of milliseconds since the system start.
Lua message object can be modified now. It was read-only till now.
Fixes:
More stable behaviour in general.
Pot reading improved for smoother operation.
Pot touch calibration improved.
onMessage() callback always called on incoming MIDI.
MIDI indicators fixed.
Sysex template checksums fixed.
Things that I have not been able to resolve yet:
USB Host has troubles with multiple devices connected with hubs.
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.
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?
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?
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.
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
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.
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.
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
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.
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.
