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