Something weird while on FW3.1.7: controls are triggered unwantingly multiple times/
Compare these two Waldorf Pulse Versions:
I’ve set aside the original preset, that is showing the bug, as Electra One App, named " Clone of PULSE NIG V1.2".
And I corrected the published one as Electra One App, named " PULSE NIG V1.2" so everyone can keep using it.
The difference between both presets is that virtual controls 12034 and 12036 (the ones encircled below) exist 3 times in the clone. These controls serve to move the program change one up or down.
I’m using this set of program change controls in almost all my presets. But in the latest firmware version the control is being executed as many times as the control parameter exists in the preset !
So when the patch number is on 40, and in the Clone preset, you press ‘+1’ control 12036, you see it executes program change 41, 42 and 43.
The expected behaviour naturally is a single execution of the control.
I’m not sure when this behaviour has exactly been introduced, as I skipped some beta versions.
EDIT: c hecked some other presets: same result: the program change controls are also executed as many times the same control exists in the preset. For instance in the Mopho V2.1 preset, the command is executed twice.
1 Like
The short answer is that since the controls share the same parameter number, the Electra One sees a change to the parameter number and there triggers the functions associated with that program number.
There are solutions to this. Very short on time today, but things to think about - use different parameter numbers, or check the control ID or check to see if the function is being used from a non-active page.
there’s a clean way to do this, but I’m drawing a blank at the moment.
What you want is – use a single function (like you are), and use the same parameter number and only send when you are on the visible page.
alternately, use different base parameter numbers but adjust them based on which page is sending it
1 Like
There may be solutions yes. Thing is, it is different behaviour as before affecting many presets.
Before I go and change all of them, it is better to check if behaviour can be brought back to what it was before.
Yeah, I took a bit of time to review this before answering. There has been a change in the behaviour indeed. What was done in recent releases is that the Lua function is triggered on value changes coming from all types of sources. Originally, it is run on human interaction only. So, in the original setup it was triggered only for the control that was used. In the new setup, the function is triggered also when underlying parameter value changes. This allows functions to be run when eg. incoming data changes the state of the control. It seems to be a useful change in the electra internal system. Before having this, formatters were abused to serve the same purpose.
The new way of processing the events (it is fired by the internal parameterMap.onChange) feels to be more consistent. I understand, however, that when used purely for handling UI, it may cause unneeded hassle.
I could possibly limit execution of the function to just one per change. That could affect other presets too though.
What I could possibly do, would be adding an optional parameter to the function telling it where the change came from (User interface, MIDI, reading snaphot, etc). Like origin in parameterMap.onChange (valueObjects, origin, midiValue).
1 Like
what I ended up doing was in the parameterMap.onChange(), put a conditional at the top saying basically
if (origin ~= INTERNAL) then return end
If I needed to know when a value is changed by MIDI or LUA, I could also capture it there and do something different.
2 Likes
I’m still not sure how to solve this elegantly.
The program change function “selectIt” , which is in all my presets practically, uses that function on the 3 select buttons. It behave differently for these three buttons, due to the parameterNumber associated with the pads. But I typically have these select buttons on more than one page, to avoid swapping pages when browsing patches.
How can I resolve it with the new method? I mean, the execution is not dependent wether it comes via MIDI or via the UI. All the controls are UI based. And I actually use the parameterNumbers to create context between the patch number and the three select buttons, so giving each set different parameter numbers is not a solution.
And I guess rewriting lua so it uses a parameterMap.onChange method won’t resolve, because I expect the value increment change would still be triggered multiple times if the same pad with the same number is multiple times in the preset…
If you want to keep most of the code the same – AND – the various selects are on different pages, you can add this:
(I grabbed your Korg M3R preset to use and test)
function selectPgm(ValueObject, value)
if value==0 then return end
local ctlId = ValueObject:getControl():getId()
local curPage = pages.getActive():getId()
if (curPage == 1) and ((ctlId == 112) or (ctlId == 113) or (ctlId == 115)) then
goto continue
elseif (curPage == 3) and ((ctlId == 104) or (ctlId == 105) or (ctlId == 138)) then
goto continue
elseif (curPage == 6) and ((ctlId == 171) or (ctlId == 172) or (ctlId == 180)) then
goto continue
else
return
end
::continue::
parameterMap.set (deviceId, PT_CC7, 64,0) -- switch off Hold
Yes - not the most elegant, but it prevents functions that are triggered “off page” from running.
With a more careful selection of control IDs on each page when creating the preset, the if conditional can be cleaner.
1 Like
Thanks for the suggestion, i’ll take that route. But the disadvantage of it is that it makes tweaking someone else’s preset much harder. Imagine someone without lua knowledge moves those controls to other pages. Behavior can change drastically and it’ll be hard to help the fellow. I find the new way of working therefore not entirely in line with the community sharing principles.
In my opinion it was more intuitive when a function assigned to a control, is only called triggered by that very control, and that if you want a function to be called anytime a parameter is changed you then use the parameterMap.onChange.
Just my 2 cents.
I agree in general with the idea that presets should be sharable and able to be modified by others.
A basic design principle seems to be that the parameter number only determines the execution of the functions.
We all have had those moments creating presets where we copy controls and then during testing we see all copies changing in sync.
I don’t know if many presets take advantage of that feature.
Maybe if under the hood the OS was changed to only call the function if the control is on the current (visible) page?
I wonder if that change would break anyone’s existing preset?
In any case the solution you provided works 
I learned again some lua !
