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:
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.
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.
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.
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.