V4.0 testing [was V3.7]

Ahh - the bounding boxes. What are the maximum dimensions of the Electra one? (in bounding box values).
So if I wanted to have all touch area inside a box and started at 0,0 - what are the x,y for the other end? I don’t remember if that is posted anywhere in the documentation.

Also - I guess I was confused. I thought the control used (start x, start x, end x, end y)
I think you are saying the control uses (start x, start y, size x, size y)

1 Like

an updated version. Can you give it a try?

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

You can go up to bounding box [0, 0, 1024, 550]. It represents full width between the top status bar and the bottom bar. This latest version of the firmware will trim the width and height to make sure that it never goes beyond the limits.

yup, it is (start x, start y, size x, size y)

I will make sure this is in the new documentation pack.

EDIT: test the preset without making any modifications to it. the firware should handle that.

1 Like

tested it with @Mint-Gecko’s KnobConnector. I can see a minor flaw there - the Module button keeps the “active” state (underlined). For the rest it looks ok. @Mint-Gecko would you give it a try? You know the KnobConnector better than I do :wink:

1 Like

@martin will check this out tonight, thanks for mentioning!

1 Like

@martin - the OS update handles the out-of-bounds case correctly.

I will update my code and continue testing with 4.0.0.o

1 Like

That’s the exact same graphical issue I had with the previous v4 beta using the pcm81 preset

@Mint-Gecko this is corrected version after working with the KnobConnector extensively:

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

1 Like

@martin works great using v4.0.0p!

I don’t know if you remember but you said you had spotted some performance issues with my plugin here. Did those improvements already land in the current version and does that mean I can disable those stop-repaint calls? If I recall this conversation correctly, I was never able to spot a noticeable difference on my end and I think the performance part of my last post about this went without further response here.

I’m bringing this up again because of two things:

  • with v4.0.0p, the behavior when the E1 lags behind due to changing a parameter page. When it lags behind, the screen stops updating until it has finally caught up again. This was not yet the case with v4.0.0k. I didn’t spot any change between k and p related to this but this seems to reduce the time the E1 is lagging. A concrete example: load up DMGAudio Compassion (demo/trial is here), run the action KnobConnector: Toggle controller View and then keep the arrow right key pressed to go from the first to the last module. With v4.0.0k, the E1 would need about 3 seconds to become responsible again. With v4.0.0p, the E1 needs about 2 seconds. Which version introduced this change and was it intentional?
  • can you spot any other bottlenecks when navigating the modules as described in the previous point? I’d really like this to be more instant but I’m a bit out of ideas what I can improve there. The E1 script already compares incoming messages with the control states to prevent any unnecessary Lua calls causing expansive repaints and the Reaper plugin usually avoids resending the same text data for the same controls.

Quick update: I’m currently working with @jhh - we’re trying to figure out some strange behavior between Ableton and the E1. I’ll follow up on the other stuff later.

1 Like

The internal renderer has recently been updated so that it consolidates multiple queued repaints into one repaint - given that they take place during one framebuffer switch. It basically does the same was as window.stop() and window.resume() do. The difference is that with the window control the consolidation may span accross multiple framebuffer switches.

now, I did install the ReaImGui and DMG Compassion. I can use the submodule prev - next on the controller. Which seems to work ok and it is quite responsive. Cliking the “Next” button on the KnobConnector::Controller view does not seem to do anything. I guess I still need to set something up somewhere?

I do not see any IO/OUT activity in the MidiMonitor when I press that button.

1 Like

@martin - I’ve been meaning to bring this up, but NOTE - this is not specific to the 4.x.x release; it’s been happening consistently for me over the years.

This is not a showstopper since I don’t regularly develop on the Mac and multiple send attempts eventually do succeed.

On the Mac (currently Monterey 12.6.3), using Chrome, and the app.electra.dev URL, I will see these kinds of errors trying to send edits to the Electra One. It happens with most of my larger presets. In this particular case, it is with the current PCM 80 preset.

06:09:26.729 transport disabled 
06:09:30.892 loadLua debug output: 
06:09:30.892 ---- START ---- 
06:09:30.919 loadLuaModule: error loading file: filename=ctrlv2/slots/p000.lua, error=ctrlv2/slots/p000.lua:73: unexpected symbol near '18' 
06:09:30.919 ----- END ----- 
06:09:47.832 transport disabled 
06:10:04.390 loadLua debug output: 
06:10:04.390 ---- START ---- 
06:10:04.416 loadLuaModule: error loading file: filename=ctrlv2/slots/p000.lua, error=ctrlv2/slots/p000.lua:63: malformed number near '999p' 
06:10:04.416 ----- END ----- 

05:31:15.072 loadLua debug output: 
05:31:15.072 ---- START ---- 
05:31:15.094 loadLuaModule: error loading file: filename=ctrlv2/slots/b00/p00/main.lua, error=ctrlv2/slots/b00/p00/main.lua:33: syntax error near 'change' 
05:31:15.094 ----- END ----- 
05:31:33.226 loadLua debug output: 
05:31:33.227 ---- START ---- 
05:31:33.276 loadLuaModule: error loading file: filename=ctrlv2/slots/b00/p00/main.lua, error=ctrlv2/slots/b00/p00/main.lua:85: syntax error near ']' 
05:31:33.276 ----- END ----- 

05:16:25.904 loadLua debug output: 
05:16:25.904 ---- START ---- 
05:16:25.927 loadLuaModule: error loading file: filename=ctrlv2/slots/b00/p00/main.lua, error=ctrlv2/slots/b00/p00/main.lua:50: unexpected symbol near ',' 
05:16:25.927 ----- END ----- 
05:16:49.183 loadLua debug output: 
05:16:49.183 ---- START ---- 
05:16:49.213 loadLuaModule: error loading file: filename=ctrlv2/slots/b00/p00/main.lua, error=ctrlv2/slots/b00/p00/main.lua:79: syntax error near 'algType' 
05:16:49.213 ----- END ----- 
05:17:03.934 loadLua debug output: 
05:17:03.934 ---- START ---- 
05:17:04.829 loadLuaModule: Lua extension file initialized: file=ctrlv2/slots/b00/p00/main.lua 
05:17:04.831 ----- END ----- 

1 Like

Sorry, should have clarified that I meant to press the right/left arrow key on you actual keyboard. When the visualizer window has focus, you can use the arrow keys to navigate the modules.

1 Like

The latest 4.0.0p (I think) seems to run my large Continuum presets ok, though default colors are different/darker (not sure where the master color file is to change them - a minor issue).

But I am not sure how to create internal preset configurations that get stored with the preset that I can have a user select to restore an internal configuration (that will then set the COntinuum accordingly with code I’ll add). I need to store about 24 of these each configuration I’ll tie to a page with buttons of which might have maybe 50-60 parameters that define the current preset’s configuration. Can someone please point me to how that new function works?

Also is there a function to bring up a text tool to allow a user to label a button with a meaningful preset name in 4.0.0 (or do I have to figure out some way to do that with rotaries and presses, etc).

Thanks.

There is no documentation on any new 3.7/4.0 lua changes yet, this is all we have at the moment earlier in this mega-thread:

Here is a code snippet from my “VCV Rack2” preset to save some state (triggered by user pressing a button on a preset page):

  log ("Saving settings")
  local saved = {}
  saved["settingDoubleTapEnabled"] = settingDoubleTapEnabled
  saved["settingPageNavEnabled"] = settingPageNavEnabled
  saved["settingRackEnabled"] = settingRackEnabled
  saved["settingApplyEnabled"] = settingApplyEnabled
  saved["settingSelectModulesEnabled"] = settingSelectModulesEnabled
  saved["settingPrevEnabled"] = settingPrevEnabled
  saved["settingNextEnabled"] = settingNextEnabled
  saved["settingResetEnabled"] = settingResetEnabled
  saved["settingReloadMMLEnabled"] = settingReloadMMLEnabled

  persist(saved)

My code to read it back from E1 storage:

  log("Loading saved settings")
  local saved = {}
  recall(saved)

One gotcha I have noticed is that this state appears to get wiped everytime you upload a change to the preset from the app.electra.one preset editor. Not sure if that will happen in the final 4.0 firmware version … hopefully users will not lose their preset state when updating the preset with a new version… @martin ?

Thanks!! I’ll give it a shot and experiment. Hopefully I can save and restore all Midi values, etc. What I need to do is store a lot of control information values per preset button. I assume I can do this now with this function?

OK so let’s say I have a couple Dial controls (tagged Parameter 12, 13, etc).
I want to store the value of that in the persist table.

So when my store button is pressed I call a function
local userTable = {}
userTable [“Control1”] = value
userTable [“Control2”] = value
…, etc.
persist (saved)

But I’m not sure how the saved function maps the table tag “Control 1” to the actual value stored.
Can I do something like this to get a dereferenced value:
userTable [“Control 1”] = x.valueObject:getMessage():getValue()

Then later when I recall a table to restore the values I assume I have to go through the table and reassign the values in it to my Controls?

Really need a manual entry for this ASAP.
Thanks

Note that in the previous example, “saved” is the name of the table to be saved. For yours to work, you would need to say: persist(userTable)

1 Like

Oops. Yea that’s a copy and paste bug. I don’t do that in the real code. The main question really is that my assumption is that the table value can be any valid control value. Seems editing is turned off on posts after a while.

The general idea (which I will play with when I get back) is that if you use some type of structure to store things like an init patch or user configuration, you can now save and recall it.

The mapping between the table entries and various controls is managed by your code. You would have Lua code to populate the table and then when you recall the table you will need code to read that table and update the various controls with those values.

Thanks. That’s kind of what I assumed. Need to start testing it now.
One thing that will be very valuable now that we can create these user-based configurations is to have a text naming control that pops up to let the user name the internal preset configuration that they have stored. I assume there is no such call to open up a simplified text editor/generator in real time the user can use to easily name something which you then can grab that string and apply to controls, etc.