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).
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…
1 Like
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.
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!
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:
- 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)
- Compare the performance with any of the repro cases I shared above
- Monitor the USB/MIDI activity while reproducing the slowdown
- 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
- 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.
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)
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.