V4.0 testing [was V3.7]

[Brahms]

Same issue for me, the 4 pots control the first parameter.

[Brahms]

Hello Martin

In version 4.0.0i , when I set the screen brightness to its lowest setting and restart the controller, the setting isn’t saved and reverts to maximum.

Thank you again for this truly superb update.

[martin]

collections of fixes of reported issues, plus further improvements:

firmware-4.0.0k.srec.zip (2.0 MB)

@Phommed

After re-loading a preset from beta.electra.one, the onPotTouch callback is triggered with multiple potId = 0 calls:

hmm, I think the original issue was that a callback with valid controlId and controlId=0 was called. I tested current version and I can see that the callback with controlId=0 is called only when the pot does not have any control assigned (ie. control not visible or slot is empty). But maybe I am not seeing the issue.

@Phommed

I would appreciate if you could share some info on the new onPotTouchChange callback as I asked here in January. When I try this code, the callback never seems to be triggered (this happened in 4.0.0c, and still seems to happen in 4.0.0i):

The callback should be called now. It is identical with the original onPotTouch(). The only difference is that the pots are using index starting with 1 (not 0)

@jhh

Funny. For me the toggle buttons work less well than in version 3.x of the firmware. They respond erratically: sometimes not toggling. Sometimes toggling very quickly off and then on again.

The pads should be debounced now.

@jhh

Also, assigning ‘toggle sensitivity’ to a button doesn’t seem to make much difference. Also it is unclear how it works: is the sensitivity increased only while the button is pressed, or is it a real toggle?

I made the decreased reading less sensitive. Also, the low sensitivity mode is indicated in the bottom bar.

@jhh

Third, for lists controls, if you are on the first item and turn further left, the value jumps to the last one in the list. Is this configurable somehow? It is nice in certain cases, but I’m not sure I always like this as the standard behaviour

It is an intended change. I will think about adding a customization option.

@jhh

Also I see erratic ADSR behaviour. When the popup opens, all 4 pots control the first parameter, i.e. Attack. Value updates (sent using sysex command 0x14, 0x0E) also behave weird. The redraw for the first control is larger and above the actual control:

Fixed.

@Brahms

In version 4.0.0i , when I set the screen brightness to its lowest setting and restart the controller, the setting isn’t saved and reverts to maximum.

fixed.

I tested this version with Bitwig and Ableton. It seems to work ok. I have not had a chance to test with VCV Rack - @Phommed please give it a try and let me know. Thanks!

[Phommed]

HI @martin .

The additional duplicate controlId = 0 onPotTouchChange callbacks are still being fired in 4.0.0k. They happen after hiding then showing a control. Example below is tapping just one control which was first shown, then hidden then shown again and logging the parameters of the onPotTouchChange callback

12:50:52.270 lua: potId: 2.0, controlId: 3.0, touched: yes
12:50:52.274 lua: potId: 2.0, controlId: 0.0, touched: yes
12:50:52.275 lua: potId: 2.0, controlId: 0.0, touched: yes
12:50:52.401 lua: potId: 2.0, controlId: 3.0, touched: no
12:50:52.405 lua: potId: 2.0, controlId: 0.0, touched: no
12:50:52.406 lua: potId: 2.0, controlId: 0.0, touched: no

Also, I am not sure reporting the controlId = 0 if the control is hidden is a good idea … if a control is actually mapped on that page on that slot, shouldn’t it always report that control ID, even if the control is temporarily hidden? If necessary, the code could check whether the reported control is hidden or not if the author wanted to suppress the pot touch action.

** Edit - also just wanted to say that the on-screen controlUpdate sequence rendering is now back to as it was in 4.0.0c and before, looking good (it was almost as if the window.stop / resume was broken in 4.0.0i, but seems fine in 4.0.0k).

[martin]

Hi @Phommed,

This is the preset I am using to replicate the issue: Electra One App

Can you test it out and possibly make mods to it so that I can use it to replicate it?

Regarding the control=0. The function is designed as a callback for a pot event. The information about control is provided if there is a visible control assigned to given pot. I do understand that it can make things more complicated in some cases. On the other hand, the current implementation allows to implement functions that are not strictly bound to the controls. Maybe, you can create a wrapper that fires the callback when non-zero control is present?

[Phommed]

Hi,
Thanks for the preset, I could not reproduce the problem (repeated controlId = 0 onPotTouchChange callbacks).

But I can keep reproducing it with my VCVRack2 preset. The big difference between the two is that in the VCVRack2 preset, when changing between mapped modules, it first makes all controls on all first 6 pages invisible (via lua) , then the controls of the new module are made visible via Sysex controlUpdate commands being sent from VCvRack2 (from my OrestesOne module). See rsbatech-modules/src/OrestesOne.cpp at 3cd01cb7f644d1609a4a59ce15651abdf29afd12 · rjsmith/rsbatech-modules · GitHub

Could there be a different codepath affecting the underlying control state when controls are updated via external controlUpdate commands? Is it possible to test this out by building and sending an updateControl sysex command in the pot touch test preset, looping back back into the E1 ? Appreciate your help with this, everything else is working very nicely now on 4.0.0k.

[jhh]

@martin

collections of fixes of reported issues, plus further improvements:

Awesome, thanks! Was away from my gear for a week so only now had some time to test.

@jhh

Funny. For me the toggle buttons work less well than in version 3.x of the firmware. They respond erratically: sometimes not toggling. Sometimes toggling very quickly off and then on again.

The pads should be debounced now.

The are, almost If I touch a button twice rather quickly, the first touch correctly changes state, but the second is ignored (and sometimes briefly flashes the new state and then returns to the old state).

I made the decreased reading less sensitive. Also, the low sensitivity mode is indicated in the bottom bar.

Works now.

@jhh

Third, for lists controls, if you are on the first item and turn further left, the value jumps to the last one in the list. Is this configurable somehow? It is nice in certain cases, but I’m not sure I always like this as the standard behaviour

It is an intended change. I will think about adding a customization option.

I think both modes make sense, so a customisation option (in the UI of the E1, not in the preset itself!) makes sense.

@jhh

Also I see erratic ADSR behaviour. When the popup opens, all 4 pots control the first parameter, i.e. Attack. Value updates (sent using sysex command 0x14, 0x0E) also behave weird. The redraw for the first control is larger and above the actual control:

Fixed.

Indeed. Still some minor issues though.

• If you change preset while an ADSR popup is open, it still remains open overlayed over the new loaded preset. Probably nicer to first close the open ADSR popup.
• String values sent for ADSR controls are not remembered when ADSR popup closes, so that when it reopens (or is opened for the first time) the meaningless integer value range is shown. The string value is only shown again after the control is changed (and the remote script sends new string values)

[martin]

@jhh

The are, almost If I touch a button twice rather quickly, the first touch correctly changes state, but the second is ignored (and sometimes briefly flashes the new state and then returns to the old state).

I noticed that later too. It is caused by the fact that double-tap reset the control to its default value. I made some more changes: 1) no double-tap reset to default on pads (it does not much sense) 2) I decrease the time window for the second click to be interpreted as a double-tap

@jhh

I think both modes make sense, so a customisation option (in the UI of the E1, not in the preset itself!) makes sense.

I like that idea.

@jhh

• If you change preset while an ADSR popup is open, it still remains open overlayed over the new loaded preset. Probably nicer to first close the open ADSR popup.
• String values sent for ADSR controls are not remembered when ADSR popup closes, so that when it reopens (or is opened for the first time) the meaningless integer value range is shown. The string value is only shown again after the control is changed (and the remote script sends new string values)

I will look at those.

In general 4.0 seems to work rather well now. I am currently making changes to the web app so that it handles new configurations options. I still need to review @Phommed pot touch issue but it feels that the firmware is close to an official release.

[Phommed]

Hi @martin Very happy to help out if I can, just let me know.

** Update, I switched the code so my VCVRack module sends Lua commands to call my own updateControl script function to update controls instead of the built-in preset sysex updateControl, but I can still see the multiple potTouchChange callbacks firing:

function updateControl(controlId, name, visible, displayText)

 local ctrl = controls.get(controlId)
 ctrl:setVisible(visible)
 ctrl:setName(name)
 local ctrlValue = ctrl:getValue()
 ctrlValue:overrideValue(displayText)

end

(control at slot 11 had a visible fader control, but had previously been made invisible)

14:05:43.175 lua: potId: 11.0, controlId: 0.0, touched: yes
14:05:43.182 lua: potId: 11.0, controlId: 12.0, touched: yes
14:05:43.183 lua: potId: 11.0, controlId: 0.0, touched: yes
14:05:43.339 lua: potId: 11.0, controlId: 0.0, touched: no
14:05:43.341 lua: potId: 11.0, controlId: 12.0, touched: no
14:05:43.342 lua: potId: 11.0, controlId: 0.0, touched: no

[discohead]

[martin]

@Phommed

** Update, I switched the code so my VCVRack module sends Lua commands to call my own updateControl script function to update controls instead of the built-in preset sysex updateControl, but I can still see the multiple potTouchChange callbacks firing:

I worked with VCV Rack + Orestes and identified the issue. Updated firmware is down below.

@jhh

• If you change preset while an ADSR popup is open, it still remains open overlayed over the new loaded preset. Probably nicer to first close the open ADSR popup.
• String values sent for ADSR controls are not remembered when ADSR popup closes, so that when it reopens (or is opened for the first time) the meaningless integer value range is shown. The string value is only shown again after the control is changed (and the remote script sends new string values)

Fixed both

if I may ask, pls re-test using
firmware-v4.0.0m.srec.zip (2.0 MB)

[Phommed]

Hi @martin Thanks for trying this out with Orestes - I tried and failed for 3 hours over the weekend to reproduce it using the simplified touch test preset.

In my initial testing in the VCVRack preset / Orestes it looks like the main problem has been cleared up (progress!) , but only if you don’t change the active control set. If you do change the active control set, then touch a knob, the callback (and the underlined controls on the UI that visually indicating a pot touch on a control) seems to fire x3 times, one for each of the three activity sets. I can see the mapped control id for each of the 3 controls mapped to the same slot. Hopefully you can see that too ?

20:26:28.259 lua: potId: 9.0, controlId: 22.0, touched: yes
20:26:28.264 lua: potId: 9.0, controlId: 34.0, touched: yes
20:26:28.273 lua: potId: 9.0, controlId: 10.0, touched: yes
20:26:28.456 lua: potId: 9.0, controlId: 22.0, touched: no
20:26:28.458 lua: potId: 9.0, controlId: 34.0, touched: no
20:26:28.460 lua: potId: 9.0, controlId: 10.0, touched: no
20:26:28.690 lua: potId: 9.0, controlId: 22.0, touched: yes
20:26:28.693 lua: potId: 9.0, controlId: 34.0, touched: yes
20:26:28.694 lua: potId: 9.0, controlId: 10.0, touched: yes

Many regards!

[jhh]

Works nicely! Thanks!

[martin]

fixes, visual tweaks, added non-destructive 3.n → 4.0 upgrade procedure.

If you’re currently using version 3.n (and haven’t updated to 4.0 before), the first run of v4.0 will convert your existing data to the new format, but will also keep the original 3.n files in place. This means downgrading back to 3.6 should be easy and won’t result in any data loss.

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

I also updated beta.electra.one. There is a updated configuration section for v4 under the Controller. New controls have been added (XY pad, envelopes, checkbox).

@oldgearguy would you be willing to test it out with your presets? I tested it with Ableton, Bitwig, VCV rack, and presets for gear I have. But none of my presets is as complex as yours.

[oldgearguy]

@martin - I’ll give it a runthrough later today (30 March) and let you know.

Tom

[jhh]

Runs smoothly and like the extra ADSRs. What’s the checkbox though (couldn’t find/see it). And any documentation on how to use the performance page? (Would be cool to add support for this for complex Ableton devices)

[Phommed]

Hi @martin , just tested 4.0.0n on my VCVRack 2 preset, the pot touch issues have been resolved! Had a play, tried different settings with buttons config (all on the device, which is great), couldn’t find any issues. I was able to remove some guard code in my preset which was mitigating the previous bugs. Wonderful, thanks so much for your hard work on this new firmware.

[jhh]

P.S. Looking forward to the updated documentation on how to program custom controls ;- )

And I was wondering whether there is also a possibility to override the drawing functions for existing controls (especially the ADSR family, including what is drawn in their popup window). (I am looking at a way to elegantly support the different ADSRs Abelton uses, making it possible to change all their parameters in the popup, while showing a reasonable approximation of the actual ADSR in the main preset display and also in the popup)

[oldgearguy]

ok, some initial things. OS 4.0.0n, using app.electra.dev (the only way I can consistently see all my debug messages in Windows 11/Chrome).
In general, the new OS seems solid (after 1/2 hr of quick tests, more testing later).

Initial thoughts are the button touches I use to jump from page to page seem less responsive (have to hold my finger down a little longer to get it to recognize.

I have this weird, repeatable thing happening with a page. The Levels/Delay page is dynamically adjusted with controls and groups being hidden or shown, depending on the algorithm used in a PCM 80 preset. If I load the Electra PCM 80 preset and download something from the PCM 80, if I press the Levels/Delay page button, I’ll most often get the first picture (empty top half). Sometimes it will flicker and stay, sometimes it will flicker and be blank.

One time after the blank, I pressed the Electra ‘Show Pages’ soft button and then the screen was like the second picture. Everything I pressed resulted in that kind of ‘no text, but a color bar’ display.

The way it should appear is like this:

I also do a lot of dynamic re-coloring of controls on currently non-visible pages. So if a patch target is selected, I color it dark purple and if a patch target is then changed, I revert the control color back to it’s original value. Sometimes I go to a page where the control color has been modified and I’ll see it toggle between the two colors and usually end up as the default rather than the Mod target deep purple, but not always. It appears that the OS is queueing up things like color changes, control placement and hide/show and then doing everything in the queue when the page is displayed. This appears (from the outside) like different behavior from 3.7.0f

The commands I am using for these things are the control:setVisible(), control:setColor() and group:setVisible(), group:setColor() and targeting controls on multiple pages across the preset.

[martin]

@oldgearguy I was able to replicate it using your instructions. Thanks! I will take a look at that in more detail today.

EDIT:

there a sequence of commands that adjust boundary boxes of components in preset.onLoad:

09:08:41.536 lua: x: 0 y:0 w:1000 h:281
09:08:41.537 lua: x: 20 y:478 w:1000 h:540
09:08:41.538 lua: x: 0 y:0 w:177 h:540
09:08:41.539 lua: x: 187 y:118 w:344 h:191
09:08:41.540 lua: x: 0 y:0 w:177 h:80

some of these adjustments result in bounding boxes extending beyond the graphical canvas, eg y: 478 with height: 540 exceeds the canvas area. I willmake sure that the firmware trims such bounding boxes, but you may want to verify this on your end as well to make sure the trimming does not break the functionality