V4.0 testing [was V3.7]

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

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.

collections of fixes of reported issues, plus further improvements:

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

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.

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)

The pads should be debounced now.

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

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

Fixed.

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!

2 Likes

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).

1 Like

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?

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.

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

The are, almost :wink: 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).

Works now.

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

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)

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

I like that idea.

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.