V4.0 testing [was V3.7]

[jhh]

@martin

ok, this is most likely the last beta:

firmware-v4.0.0s.srec.zip (2.0 MB)

• persisted JSON up to 1MB (@manu)
• persisted JSON issue resolved (@rkram53)
• RAM usage indicator added to Settings / System info
• Lua drawElipse corrected to drawEllipse
• Buttons made lighter at their “off” state (@kx3)
• Completed firmware support for multiple Lua files in one preset (@Electrolove)

I am still busy with @Mint-Gecko’s “slow response”. And I need to pay attention to issue that @cryingboyscafe reported - freeze when Squarp sequencer is connected. Both issues seem to be somewhat specific and not affecting the majority of setups/presets, therefore I am gettings things ready for releasing 4.0 officially this week.

With this firmware version I no longer see a difference in brightness between controls that are currently in the selected control set (controlled by the knobs) and those that are not. Is that by design? Or is there a (UI) setting that I can tweak to make them more visually distinct? (Would be good because I do like the fact that the controls are more clearly visible).

[martin]

oh, I forgot to mention that. It is important change. Due to performance reasons (to improve rendering of pages), the active control set is indicated with the white bars on the screen sides. The dimmed sections and the solid background options are no longer supported. I am sure that some of the users will miss that, but I have to make that step to be able to make important changes.

PS: but it has been in the 4.0 betas like that for quite a while now…

[rkram53]

Martin - what’s the easiest way to clear the persist tables - that is make it seem like it has not been persisted once persisted (for testing)? Also if your table is too large to be persisted will some error message come up? Thanks.

[rkram53]

But 1 million thanks for the new Persist/Recall feature (and most recent array of tables fix which seems to work fine with a big table). I scaled it up for production and it lets me store 30 user configurations of 85 or so parameters in this array of controls that I can name and then select once created. This lets me create a fully functional EaganMatrix Overlay synth application - Osmose Users are going to love what I can do with the Electra One and I am sure having many of them want the Electra One!

[Mint-Gecko]

@martin

I am still busy with @Mint-Gecko’s “slow response”. And I need to pay attention to issue that @cryingboyscafe reported - freeze when Squarp sequencer is connected. Both issues seem to be somewhat specific and not affecting the majority of setups/presets, therefore I am gettings things ready for releasing 4.0 officially this week.

Really sorry to be so persistent. I just realized that I never shared how I actually came to the conclusion that the bottleneck is somewhere in the E1 Lua API and not somewhere else (MIDI transmission, my plugin, my E1 script itself). So this is not to demonstrate that there is a bottleneck, but to show where the bottleneck is probably located:

1. Use this alternate preset which is functionally identical with the main version but skips all calls to the E1’s Lua API (more specific it’s set* calls)
2. Compare the performance with any of the repro cases I shared above
3. Monitor the USB/MIDI activity while reproducing the slowdown
4. Note how instead of the device freezing for several seconds, the script is mostly finished when I change my eye’s focus from my computer screen to the E1, at max rarely half a second later
5. To verify what noted in step 4, also immediately wiggle the knobs to check the device is indeed responsive

The fact that skipping all E1’s Lua set API calls fixes these slowdowns suggests that it’s caused by a set of functions’ implementations on the E1’s Lua API.

[rkram53]

I need to check on Midi output. I’m getting unpredictable behavior when outputting data to my EaganMatrix DSP target. I thought it was the EaganMatrix DSP I’m sending data to that is not handling data correctly as that firmware is new too. But perhaps it is related to this issue. The target is changing based on Midi messages I’m not actually sending. I need to check if perhaps the E1 is sending garbage data sporadically. My program is very heavy on Lua Midi API calls. Has anyone seen that 4.0.0 occasionally sends bad or unexpected Midi data from midi.sendControlChange(…) calls when you send a lot of them in sequence? I need to test Midi output to confirm (though still likely the target may be garbling it)

[rkram53]

Also seems like when I clone a project and rename it. If I run that the persist/recall starts fresh, but the original preset it was cloned from also resets persist if loaded. I though Each preset gets its own serialized JSON file - or is this because it was cloned? A clone should be a new preset from the perspective of persist/recall.

[1overf]

4.0 is really feature rich and I am trying to explore the various menu options. I am able to use the randomize setting using usb midi device as an external controller but whenever I enable it I can’t seem to still be able to use the same external device to also control the various onscreen controls using cc’s. How do you route an external controller to control both the random feature and still have it sync and update the onscreen controls on the e1. Also the custom button settings make the device feel really natural and a joy to use. Being able to set to users preference is fantastic.

[oldgearguy]

@martin , have you thought about lower case letters for control and group labeling? I know I can rename things in Lua if I really want mixed case, but it would be nice if it could be done directly.

[jhh]

I would love that feature too!

[nuipb]

@martin

implementing v3.7 on mk1 is possible only at the expense of using more memory. I do not want to do that.

To know which presets would be too large for MKI and best on a MKII would it be possible to display the size of each presets in their respective page in the PRESET LIBRARY ?

[davehouse]

@nuipb

arge for MKI and best on a MKII would it be possible to display the size of each presets

This would be useful. I’d also love to know if the Mk1 will be getting any of the 4.0 features, I think I remember it being said that a final FW update would be out at some point for the mk1

[1overf]

What is the benefit of setting up remote knobs seeing as though knobs are already controlled remotely when using a remote midi control that sends cc’s to e1 without the additional usage of remote knobs page. Sorry I’m just trying to understand the usage of some of these newer features and I’m probably thinking about them incorrectly to begin with so my apologies. After using the various routing pages for awhile I’ve ran into situations where a remote midi controller that is plugged into the e1 has its incoming cc messages correctly forwarded to the connected synth but the onscreen controls on the e1 that have matching cc’s don’t update to reflect the external changes which I wouldn’t expect. If I then change the routings the visible preset controls are updating as expected. In either case the same messages are correctly sent but the onscreen display of the messages are different.
I almost feel like there should be only 1 master routing page that is comprehensive and has selectable routings for sending all the various messages to and from e1 such as those that are internal only (ctrl), those forwarded to external midi ports, as well as connecting presets to external knobs. Currently these pathways are on 3 different routing pages and it’s not always easy to see how they interconnect and some connections feel redundant. I think it would be perhaps better if all routes were displayed on one rather deep page of all various pathways and it had a selectable path for ctrl.

[martin]

@davehouse

This would be useful. I’d also love to know if the Mk1 will be getting any of the 4.0 features, I think I remember it being said that a final FW update would be out at some point for the mk1

yes, it is still part of plan. I know that things go very slow - I have to juggle E1 work with other personal matters. I consider mk2 firmware version 4.0 ready to be released. I am updating the docs now. see below. After that, I am going to make one more release of mk1 firmware. Do expect to get full blown 4.0, but some stuff will be there, what it will be is still TBD. A preset compatibility check for sure.

@1overf

What is the benefit of setting up remote knobs seeing as though knobs are already controlled remotely when using a remote midi control that sends cc’s to e1 without the additional usage of remote knobs page. Sorry I’m just trying to understand the usage of some of these newer features and I’m probably thinking about them incorrectly to begin with so my apologies.

Some of those new features need extra explanation. That is why I am putting quite some effort in making sure everything is well documented this time. The progress of my work can be found at: https://beta-docs.electra.one/.

Description of the remote knobs is still to be written. In short, you can think of it as an additional way of changing value of an on-screen Controls (next to the twelve knobs and touch). It gives you:

• a generic way of extending number of knobs you can use with the E1
• a way map E1 controls to another MIDI controller (I will later show an integration with SL49)
• a way map certain controls to true faders (eg. Akai MIDIMIX) to be have better way of doing fade ins/outs during performances
• and as remote knobs feature supports both ways of communication (listening to external controller and sending remote knobs messages out when E1 knobs are used), it can be used to automate (record in DAW) any type of MIDI messages, including sysex.
• for E1 Mini, it is one of the top features.It allows the little box to add NRPN/sysex/whatever support to other, larger, 3rd party MIDI controllers.

@1overf

I almost feel like there should be only 1 master routing page that is comprehensive

I agree, I spend quite some time on designing the router page. So far, I have not found a good way to fit it on one page - it was getting extremely busy when the remote knobs and MIDI control were added. I do consider the current version good for now and I am expecting it will evolve over the time.

@oldgearguy

@martin , have you thought about lower case letters for control and group labeling? I know I can rename things in Lua if I really want mixed case, but it would be nice if it could be done directly.

I will add that. The limitation comes from old times when electra had fonts with capital letters only

@rkram53

Also seems like when I clone a project and rename it. If I run that the persist/recall starts fresh, but the original preset it was cloned from also resets persist if loaded. I though Each preset gets its own serialized JSON file - or is this because it was cloned? A clone should be a new preset from the perspective of persist/recall.

I have noyt noticed anything like that during the testing. I will take a look at it.

[Phommed]

HI @martin . very excited to see the work in progress beta documentation, I’m trying to quickly read it to find out about any other features that have not yet been mentioned in this mega-thread. OK if I ask a few questions already ?

1. The control.set/getVariant() call seems to be for changing the cosmetic appearance of a category of control dynamically which is useful. But, as far as I can see, there is still no way of programmatically changing , say, a fader to a button ? That would be so useful (e.g. on my VCVRack preset, I could change a fader to a button if the control was currently mapped to a VCVRack module’s button).

2. Data pipes! I don’t recall that being mentioned before. Look forward to finding out more about this. The pipe.send() documentation says “a floating-point number to send.”. Does this ONLY works for floating point numbers, or can a pipe transmit any lua number (ie can it send integers also) ? Suppose I wanted a pipe to send discrete values (say a choice of 5 values 1->5)?

3. Preset lifecycle callbacks. I understand from the docs that the preset.onLoad and onReady do not re-fire if user switches between presets that have already been opened once. Is there any way for a preset’s lua code to detect when a preset has just been selected / switched to by the user?

4. There is a typo in the this heading “events.onPotTouchChange(potId, countrolId, touched)”

Best wishes…

[Mint-Gecko]

In the beta docs at SysEx implementation | Electra One Documentation, there’s a paragraph that repeats its info twice:

The control-update-json-data may consist of four optional attributes name, color, visibility, and name. Upon receiving the control update command the fields will be set accordingly. It is possible send only attributes that need to be changed.

The control-update-json-data may include up to four optional attributes: name, color, visibility, and value. When the control update command is received, any provided attributes will be applied to the control. You only need to include the attributes you want to change — all others can be left out.

Updating the value attribute allows you to set value.text only, which is equivalent to using the SysEx call for overriding the value text.

I also think that the name name or value (whichever is correct) is misleading. It should be called valueText or value_text (depending on style).