I have a preset that uses quite a few virtual controls with functions assigned to them
The functions are firing when the preset is sent to the Electra from the web editor or the first time that a preset is loaded on the Electra following a reboot of the device
Is there a way of stopping this?
Short answer is not really.
This is something people have discussed with Martin a lot. Same with not triggering when you want them to.
One way to think about it is this - if the parameterMap is updated with a value that is different than before, the functions will trigger. I think that the parameterMap is initialized with the default values for each control and that is what causes the triggering.
I have resorted to putting conditionals in the functions like “if the current page is not 2 then return” or “if the sysex dump is not loaded yet then return”.
Of course you have to supply something if returning from a formatter function, but you get the idea.
If there was a way to initialize the parameterMap on load so nothing triggered, that might help.
Yes I think triggering is caused by the initialisation of controls. The initialisation seems to occur after the preset.OnLoad. So I can’t turn on or off a flag there.
I’ve kind of got round it with a hidden control that I know through print statements is initialising last and I use that control to call a function that turns off a DontTrigger flag. Obviously if I add more controls this could upset that I I will need to include some text about that when I publish the preset. A bit hacky but hey it works.
In fairness the initial triggering works in my favour on some controls in terms of the functionality that I want to implement. So I don’t necessarily want to blanket turn it off for everything. It would be useful though to have some way programmatically of knowing that a preset is fully loaded and initialised
yeah, the idea here is that setting the default value is identical change as if the value is set with midi or user later on. The function can do the processing, eg. hiding controls, etc. As I work with E1, I am kind of developing this pattern when I use functions for maintaining the state of the preset (visibility, locations, state changes) while messaging and the preset data is handled by the parameterMap.