It’s very annoying (and unpredictable) the way all this initialization gets done in the background triggering controls when you want nothing to be activated until your program really begins. Seems if I put flags in OnLoad they are run before or during the initialization process. This should be changed so that all internal initialization is done before OnLoad so we can put flags in there to ignore all the auto initialization that triggers things to happen when you don’t want it to and set proper initialization sequences. Terrible that all these controls are firing on initialization. There needs to be a simple way to get around that. Maybe there is? Thanks.
It’s something we’ve all addressed in different ways. I set a global to -1 and check it in the formatter() functions. I typically unset it after receiving a sysex dump or something similar. You can also check the current page and do nothing if the formatter is called when on a different one.
I want to experimant with putting a function at the very bottom of all the code that unsets a flag because I think the LUA is processed serially
Thanks!! It’s suboptimal design. The OnLoad function should only be called after all initialization is done. At least that way I can easily initialize all my controls to expected values and reset anything that was mangled because of the initial triggering of all the controls. This really has to be looked at. Got to be a better way to deal with this.
1 Like
The initialization goes like this:
- preset (JSON) is loaded. All Lua functions are ignored. Default values are set (as they are part of the preset JSON)
- preset’s Lua script is loaded
2.1 Everything in the global context is executed. It does not matter where it is placed in source file
2.2 The preset.onLoad() is called
2.3 All the functions and formatters are called
ie. onLoad() is called prior to the function / formatter calls. I do remember there was a moment when I was considering added something like preset.onReady() that would be fired when everything above is set and called.
this is a snippet that demonstrates handling one control with the default value 10 (set in JSON).
print("global")
function preset.onLoad()
print("onLoad")
local value = parameterMap.get(1, PT_CC7, 1)
print("onLoad default value: " .. value)
parameterMap.set(1, PT_CC7, 1, 20)
end
function runFunction(vo, value)
print("function value: " .. value)
end
function runFormatter(vo, value)
print("formatter value: " .. value)
return value .. " %"
end
print("global end")
output:
09:45:13.103 loadLua debug output:
09:45:13.105 ---- START ----
09:45:13.107 lua: global
09:45:13.108 lua: global end
09:45:13.109 loadLuaModule: Lua extension file initialized: file=ctrlv2/slots/p004.lua
09:45:13.110 ----- END -----
09:45:13.111 lua: onLoad
09:45:13.111 lua: onLoad default value: 10.0
09:45:13.112 lua: function value: 20.0
09:45:13.113 lua: formatter value: 20.0
Note, this is happening when the preset is loaded for the first time. (ie. upload from the editor or switching to it for the first time on the controller). If you switch back and forth between presets while the controller is running, the presets that have been already used are considered to be initialized already.
Hi Martin.
This is really nasty as all that firing can cause havoc with real time controls I have loading presets and other things.
There needs to be a call that is done after all that initialization so you can properly set initalization of things.
OnLoad should come last - or please add another loading function like you say. The Electra One Lua community would be forever grateful.
I can’t have control firing preset loading for example before the user asks for it.
How can I stop Lua functions from firing during this initialization?
Also why can’t I compare a string to “#”. That;s not supposed to be a special Lua character. Putting a “%#” before it does not work. It seems it is simply not considered in a comparison (and I need it because it’s an internal terminal indicator). Is there some special treatment of “#” in Electra? Can you check that out please.
Thanks
Rich
Please consider that.
Richard Kram
rkram53@verizon.net
| martin
July 17 |
- | - |
The initialization goes like this:
- preset (JSON) is loaded. All Lua functions are ignored. Default values are set (as they are part of the preset JSON)
- preset’s Lua script is loaded
2.1 Everything in the global context is executed. It does not matter where it is placed in source file
2.2 The preset.onLoad() is called
2.3 All the functions and formatters are called
ie. onLoad() is called prior to the function / formatter calls. I do remember there was a moment when I was considering added something like preset.onReady() that would be fired when everything above is set and called.
this is a snippet that demonstrates handling one control with the default value 10 (set in JSON).
print("global")
function preset.onLoad()
print("onLoad")
local value = parameterMap.get(1, PT_CC7, 1)
print("onLoad default value: " .. value)
parameterMap.set(1, PT_CC7, 1, 20)
end
function runFunction(vo, value)
print("function value: " .. value)
end
function runFormatter(vo, value)
print("formatter value: " .. value)
return value .. " %"
end
print("global end")
output:
09:45:13.103 loadLua debug output:
09:45:13.105 ---- START ----
09:45:13.107 lua: global
09:45:13.108 lua: global end
09:45:13.109 loadLuaModule: Lua extension file initialized: file=ctrlv2/slots/p004.lua
09:45:13.110 ----- END -----
09:45:13.111 lua: onLoad
09:45:13.111 lua: onLoad default value: 10.0
09:45:13.112 lua: function value: 20.0
09:45:13.113 lua: formatter value: 20.0
Note, this is happening when the preset is loaded for the first time. (ie. upload from the editor or switching to it for the first time on the controller). If you switch back and forth between presets while the controller is running, the presets that have been already used are considered to be initialized already.
Hi Martin,
This is really nasty as all that firing can cause havoc with real time controls I have loading presets and other things.
There needs to be a call that is done after all that initialization so you can properly set initialization of things.
OnLoad should come last - or please add another loading function like you say. The Electra One Lua community would be forever grateful.
I can’t have a control firing preset loading function for example before the user asks for it.
How can I stop Lua functions from firing during this initialization? Is there a config to somehow do that? Should I use the -1 method described above?
Thanks
Part of the underlying issue (as I understand it) is that the parameterMap is the central clearinghouse for MIDI data and on-screen controls and ties it all together.
So, any time the parameterMap is changed, the formatter() and function() calls associated with that parameter number are triggered.
As the code is loaded (as explained above by Martin), the parameterMap entries are getting set and that is causing the functions to get fired off.
I have/had a related problem in that if I have data in the parameterMap and then a user downloads a different patch, if the data for a control didn’t change, the functions won’t get called.
In my case I needed it because it was calling other things that were changed and different.
sorry for the digression …
I was hoping that there could be a way to delay/suspend the parameterMap updates during the load process, but I have not been able to get anything to work in that regard. yes - putting various blocks/tests in front of the code for the formatters() especially - how many “value is nil” errors do you want to see during a load is not a great answer, but at this point I’m guessing any major changes to the underlying structure and processing would cause a large ripple effect.
Other notes I’ve gleaned - if you have a momentary button and only want to process on the press (and not the release), not setting any value in the control seems to work. This prevents any functions tied to the control from firing on startup because the parameterMap entry is set to 0.
Obviously Martin has the final say on all this, but I’m just chiming in to say you’re not the first (or last) person to run across the issue. There’s probably a general philosophy of “how things should be coded” that minimizes the extraneous effects of functions firing before the environment is set, but coming from many many years of assembly/C programming, I tend to fall back on what I know and have done in the past.
Thanks for the great info! This will be very useful (as I have a lot of them and this is an issue I’ve seen): If you have a momentary button and only want to process on the press (and not the release), not setting any value in the control seems to work. This prevents any functions tied to the control from firing on startup because the parameterMap entry is set to 0.
Sorry I can’t edit or reply directly during the day (lovely firewalls and such here) - my post should say “don’t enter any value for the off condition”
By default I’d put 127 for on and 0 for off and I’d get 2 calls
If I put 127 (or 1 or whatever) for on and leave the off field empty, I only get 1 call.