V4.0 testing [was V3.7]

@martin - I had mentioned in a couple places that I could not roll back to an earlier OS.
The root cause seemed to be a corrupt SD card. In USB mode, I could not even delete all the files on the card.

I had to do a format (fat32) of the card, then copy the sd.zip contents, then add various OS versions.
After doing all that, the Electra is fine once again.

Naturally, during preset development, I have locked up the E1 from time to time and possibly during those times I somehow got the SD card corrupted.

The ctrlv2 folder was one of the folders that Windows said was corrupt and could not be read.

I’ve just finished the Macro integration to 4.0 beta firmware. A macro can control up to 16 parameters. For each parameter, you can pick either an “set value” mode (parameter’s value follows the Macro’s value) or an Elektron style modulation (relative with the +/- depth control).

6 Likes

When Electra crashes and it has a file opened, it may lead to corruption of the file system. The firmware uses “journaling” to recover from most of the problems, but there are occasions when the journal does not fix things. In such case, formatting the card is the only good solution.

Two notes to that:

  • The recent Electras, shipped as of December 2024, have the SD card accessible from outside to make it a bit easier.
  • we discovered that Lua uses a longjump (low level C instruction) for handling some exceptions. Calling a longjump causes an instant crash of the firmware. We’re working on handling such situations gracefully. I am sure that this is causing part of the mysterious freezes when developing Lua scripts.
3 Likes

Makes sense. I remember longjump() from my C programming days for sure. :slight_smile:

It seems a lot of the hang-ups occur when I do stupid things like change a function call from ‘external’ to ‘internal’ (in other words, the parameter list changes from valueObject,value to just value). In those cases, trying to access the scalar value when the first parameter is an object causes much lockups and reboots. Table out-of-bounds access attempts also cause significant problems.

Basically, when I do the wrong thing too often, the Electra says - take a break and reboot me.

2 Likes

Running the 4.0.0c, cool updates! Will the documentation be updated at the time of the official release?

The new routing options are awesome, but I think in it’s current state, it’s a bit confusing graphically and/or naming wise. In the External control settings; MIDI Control (i suppose this is to control devices connected to E1), Remote Control (I suppose this is the CTRL port for controlling the E1? I’m confused though) I think the very different nature of these parameters could be clarified through more distinct naming difference.

The Remote outbound interface can only be assigned to any i/o, but only one. Same for the USB-devices connected to the E1 (but ports, instead of directly to the i/o)

On the Router page however, I can route any port to any port, including Remote and USB devices that can even be connected to it’s own port (!) or forwarded to the other device.

How do these seemingly exclusive routing selections interact?

What does the “All Channels” toggle mean, as opposed to not engaged? Is only ch1 sent? Why are full midi channel selection only available on some ports?

The new USB-device handling is super awesome. I’ve connected a Keystep pro and a Blokas Midihub through a USB-hub to the E1’s host port; I’ve never really thought about connecting USB-Midi interface to the USB of the E1, as my main interface (Motu Midi XT) isn’t class compliant. But the Midihub is, and so are probably the CME U6MIDI Pro’s I have lying about, used for other duties. This is a much cooler way to expand the E1’s midi interface, than splitting and merging the existing ports.

On the USB Host Devices page there are 8 slots for each of the ports. The Blokas, when connected, have 4 USB ports so take up half of the slots on one side. But when I try to connect Arturia Keystep Pro and a Befaco VCMC (both also class compliant), I can only use one at the time, chosen by the one connected first to the hub. No away to use more devices simultaneously?
Quirk of USB? All those empty slots are suggesting there’s room…

Either way the possibilities are mind boggling

1 Like

So when my USB-devices (either through each their USB port, or on the same) are all connected to both Midi ports on the routing page, the signal is still only sent to the port number equivalent with the port selected in the USB-Device properties…? So what does the router do, isn’t that the “old” behaviour?

1 Like

yes, I am still trying to find an optimal way how to make the user interface more clear. But of course, whole thing also needs to be explained. I will briefly explain it here, maybe some of you will have suggestions on how to organize the UI:

MIDI Control (CTRL). It has been part of the firmware for a while. Users could use it to switch pages and presets using MIDI messages. The feature has been extended so that almost any action that you can do with the LCD touch and buttons can be now triggered over MIDI (thus over the MIDI Control). Examples of such actions are: opening the main Menu, Router config, switching to Alt mode, and so on. The purpose of this is to make it possible to map these actions to external MIDI controller to provide easier direct access to them. The MIDI Control listens to incoming data only.

Remote feature is meant to give users an easy way to map knobs of the external MIDI controller to Electra’s on-screen controls. When Remote is enabled, Electra will translate incoming CCs (both absolute and relative) to “knob movements”. This allows users to control up to 36 controls on the screen directly. Remote, on contrary to MIDI Control, works in both directions. It listens to incoming data to provide the “virtual knobs”. It can also be configured to send Remote CC messages out - ie. it sends out a CC message when you turn a knob on Electra or when you change values with LCD touch. Note such an outbound remote message is sent is parallel to the message assigned to the control. eg. if you have a Sysex control and the outbound Remote is enabled, turning the knob will send out both: sysex messages as well as Remote CC. The bidirectional nature of Remote makes it possible to record automations and such.

The router The matrix meant to make connections between MIDI data sources (left side) and the destinations (top). Both MIDI Control (CTRL) and Remote are here listed as destinations. You can pick several sources and route them to CTRL and/or Remote. The idea is to allow more MIDI controllers to be used.

The Outbound Remote can transmit data to one Interface / port only. We were looking for ways to include that “route” on the router screen, but it seemed to be confusing. I agree, however, that the current way is not ideal either.

USB assignments . The first important thing to mention is that Electra cannot connect more than two USB MIDI devices at one time. The limit comes from number of USB endpoints that the USB host controller (inside the device) can handle. A USB MIDI device may have up to 16 MIDI ports (MIDI cables it is called). When you connect a USB MIDI device with more than 8 ports, Electra will use different layout to provide access to all 16 ports. The picture bellow shows the MRCC and MIDIhub connected in the same time:

Routing the USB Host device is done in two steps:

  1. you need to assign the USB Host device ports (up to 16) to Electra’s internal port (Port 1 or Port 2). This is done in the USB Assignments window.

  2. You route Electra’s USB host port (Port 1 or Port 2) to other Electra’s interfaces and ports. This is done in the Router configuration.

A side note, the router supports routing incoming data back to the same interface / port. This is done on purpose. Electra can act as a loopback or echo, which can be useful in certain situations.

3 Likes

Thanks for the explanation, it’s all very exciting.

But how would one route say both USB devices to both MIDI ports? I seem to only be able to do one or the other (or one to each), but never both to each (even though both USB devices are routed to both MIDI ports). Or route from both Midi Ports to the same USB device (I’ve got it mapped in the router, but don’t seem to be getting any copies of the signal at destination).

I would still need to do more testing/learning before concluding it to be an E1 problem though, might be something specific to the Midihub or smth.

Either way, great work

I’m probably confusing myself with the router…
I have a Midihub as USB device two. I have made a simple patch on the Midihub that forwards any data on it’s Midi input to it’s respective USB output (so Midi In 1 to USB Out 1…M4 to U4, and USB In 1 to Midi out 1…U4 to M4), verified working as it should.

I’ve gotten bidirectional control with the device connected to the Midihub, but my routing settings on the E1 makes the output from the E1 ending up on Midi output 2, instead of 1. Otherwise, everything works.

So afaik the signal flow goes from hardware device, through midi port 1 on Midihub, through USB device 1 to E1, then routed (automatically) to port 1 (?) (so coming out of Midi Out port 1) but through my E1 routing also to Midi port 2, which is what I want (any device # should be forwarded to both Midi outputs).

However, the midi from the E1 comes out of Midi output #2 on the Midihub.

Some kind of drawing of the routing possibilities between USB devices and hosts, with their defaulted routings, would be appreciated. I’ll probably understand it better tomorrow, been fiddling around with this for a while now :grin:

Edit: with all routing off (blank page), it’s only changing the device port + USB device together from port 2 (that they were originally set to) to port 1 that seems to affect any routing at all :clown_face: I’m not smart enough or there’s something up with the router…? It seems to behave as the default routing (each of the ports are routed to all other i/o’s with the same number) and not affected by the routing page at all.

One question for @martin - in your roadmap for the Lua functionality, will there ever be a way to query a control to return the formatter() or function() methods attached to the control?
(Similar to how you can do control:getName(), control:getColor() I would like control:getFormatter() and control:getFunction() )

If not, I can (and have) worked around it, but if I don’t have to do a lot of extra coding that would be great.

Use case – any piece of gear with a Mod Matrix. You can typically select a source and a mod target and often there’s a range or initial value associated with the target. I use one control to select a target for other controls and ideally when the target is selected, the range of that target control is adjusted to have the correct min/max set and is adjusted to call the correct formatter() function to display the appropriate value and units.

So if the target is FX level, the range control might need to display -60 dB to +6 dB and if the target is FX Panning, the display might be 100% Left – Center – 100% Right

Some Mod Matrix implementations use an Amount control instead which is typically a simple scaling, but the general need for dynamically adjusting a control’s range and displayed value is something I find useful and currently challenging to implement correctly.

Hi Martin,

I’ve just done a test with the 4.0.0c firmware, and I noticed that uploading a preset via sysex is very slow for me now, up to 6-7 seconds, where it was almost instant before.

Edit: seems the same issue @jhh is having.

I tried adding the accelerated flag. However I did not see any messages have values aside from 0, 1 and 65. Could it be it does not work with nrpn? I tried adding relativeMode=“noSign” as well.

Very excited to hear about the hunt for that Lua error bug, that sounds like a big discovery that can help make things much more stable!

PS: minor side note, I prefer the design of the old buttons. I liked being able to see that a button is latched on, and the more substantive look with the shadow. I do understand that the new look gives more contrast to text, but it also feels less like a button to me, as well as less informative.

Any progress on this? And on the setSlot bug?

I know it’s taking ages, but it’ll be worth it. The findings in 4.0.0c made me to make some more structural changes in the firmware. I keep working on it.

Issues mentioned in this thread (@Phommed @jhh @christianvogel @fragletrollet @oldgearguy) are reflected and worked upon.

I reviewed what you wrote and when I work with the router it seems to work as expected. There could be possibly an issue with migration of the old configuration file and the new 4.0 format. That would explain why you are getting different behavior.

The initial 4.0 is focused on delivering non-developer features. Things that users without coding skills will be able to use immediately. I do feel it is needed to balance things. Later in the 4.0 line of work, I plan to address the gaps in the Lua API, including the missing parts you mentioned.

7 Likes

These changes sound important for stability. Thanks for the hard work.

5 Likes