(Use This) Panel Start-up Blocking Code

[subv0x]

apparently the following do not work in drafted exe and VST instances. @dnaldoog made something for this, linked below, but he's going to have to explain it.

	-- This stops issues during panel bootup
	if panel:getRestoreState() == true or panel:getProgramState() == true 
	then return 
	end

	-- This stops issues during panel bootup
	if panel:getRestoreState() or panel:getProgramState() then return end

post:
#564 (comment)

https://ctrlr.org/forums/topic/standalone-images-not-loading/
( good read )

[dnaldoog]

apparently the following do not work in drafted exe and VST instances. @dnaldoog made something for this, linked below, but he's going to have to explain it.

All it is is a fancy way of setting a variable to true at boot and then setting to false after a timer has run; 300ms seems to be enough.

Then one checks for true or false at the beginning of each function that would otherwise be triggered on starting the program.

The object is created in constructor using myPanel:init(true) and so you run if myPanel:getBootstrapState() then return end instead of if panel:getBootstrapState() then return end. It is designed to look very similar.

The lua class syntax aims to emulate Atom's if panel:getBootStrapState()==true then return end using colon syntax. But you could just as easily do something like:

• In before any modulators are created: x=true
• In when panel has finished loading: timer sets x to false
• In a function run when modulator changes: if x then return end

myPanel_1_0.zip

[subv0x]

ok done that and panelLoaded isn't crashing now. also prompted me to root out mysterious multiple console print of partial reserve values that was bugging me ...

[subv0x]

EXCEPT if i include if myPanel:getBootstrapState() then return end in the panelLoaded, and then it crashes. previously i had the old method there and no problem. should it be in the panel loaded method/function ? or is that a split point in the loading process? it hasn't seen 'constructor()' yet?
what is the 'load' order ?
it needs to find 'Panel()' before it runs 'constructor()', am i rite?
need to square this up. ... then i'm very happy to go copy 'myPanel' everywhere :-)

[dnaldoog]

You would never put it in an init script - only any function that loads when you don’t want it to load at startup - this code only applies to 5.3.201 or macOS 5.3.198.

[dnaldoog]

It wouldn’t make sense to block the init script at load. It’s supposed to load on boot! 😂

also the timer that frees up the blocking code is run in init so it would completely not make sense to be blocking that init script.

Of course the run order is constructor, init and any code to be run in constructor and init but 5.3.201 also runs functions attached to when value is changed so that’s all this code does- that is block those functions from running. After several milliseconds all is well and those functions can be freed up and run when the user changes a value.

[subv0x]

ok so it's only 'when value is changed', not mouse down ? i've been putting it for everything, worried that buttons would trigger, etc.

• and then nothing worked when i drafted exe instances :-)

[subv0x]

so 'Panel' is a 'class' ? n00b does not actually know what it means. a macro? something like that? defined by?
looks like a table, and then some stuff with a double '_' ... i don't recognise this syntax. (looks supercool though, very artistic)
what is 'cls'? ( 'class'? ) ( or just a chosen variable name )
ok, so 'Panel. ...' etc., that's a way of addressing a table (that i've seen but not familiar with using yet) (looks cool too)
...
the 'setmetatable' form ...

setmetatable(Panel, { stuff } ) end
followed by 3 functions with an unfamiliar nomenclature: 'function = Panel: etc' (all referring to content of 'stuff', above)
i didn't know you could name functions like that.

still somewhat over my head :o)

[dnaldoog]

It’s Lua’s emulation of OOP where a set of variables and functions (methods) all belong to the same family. It can allow for data hiding (encapsulation ) and inheritance . You are already using it when you see code like panel: getModulatorByName() or panel: getComponent(“name”):setProperty() etc. even code like s:sub(-1) or string.sub(s,-1) is using it. But it’s confusing if you’re not familiar with OOP and usually not necessary. I might be using it in the Juno Alpha panel in places. I think also the TX81Z panel uses it.

[dnaldoog]

ok so it's only 'when value is changed', not mouse down ? i've been putting it for everything, worried that buttons would trigger, etc.

• and then nothing worked when i drafted exe instances :-)

I have never had this experience. You might have to ensure all your code is watertight!

Sometimes I have had to use it in mouse down functions- I don’t know why, but in theory it shouldn’t be necessary.

[dobo365]

If I may also shine in in this topic... I'm using 5.3.201 but also 5.6.23 (=5.5.9)

You should only check for if panel:getBootstrapState() == false
and not for panel:getProgramState() == false . This last one is giving issues in VSTs if I well remember.
Use it only in the "Called when modulator value change" methods, not in the MouseDown.
Sometimes, you also need to do an immediate return based on the source variable. This is the case when using DAW presets and trying to replace one preset by another one.
I'm not using John's trick but as I said I'm checking for that panel:getBootstrapState() but also for a variable that I called bPanelLoaded and that is set when my initial panel load timer has done its job initializing several things.

My "called when panel has finished loading" looks like this:

--
-- Called when the panel has finished loading
--
PanelLoaded = function()

	bPanelLoaded = false
	bLoadingProgram = false

	-- Reset Midi INPUT devices to avoid having MidiMessageReceived method called twice
	-- If resetting Controller devices then the bidirectional behaviour is loss (most probably a bug)
	sMidiDevices = panel:getProperty("panelMidiInputDevice")
	panel:setPropertyString("panelMidiInputDevice", "-- None")
	panel:setPropertyString("panelMidiInputDevice", sMidiDevices)
	iPro800MidiChannel = panel:getProperty("panelMidiInputChannelDevice")

	AssignModulators()
	Tables_Init()
	BasicProgramData_Init()
	About_Init()

	timer:setCallback (2, timerCallback)
	timer:startTimer(2, 200)

end

Then in timers callback, at the end of the timer 2 code I set bPanelLoaded = true

In Miscellaneous I have this:

--
-- Check if the panel is not busy to load
--
isPanelReady = function()

--	if panel:getBootstrapState() == false and panel:getProgramState() == false and bPanelLoaded == true then
	if panel:getBootstrapState() == false and bPanelLoaded == true then
		return (true)
	else
		return (false)
	end

end

In _OnChange methods I have this:

--
-- Called when a modulator value changes
-- @mod   http://ctrlr.org/api/class_ctrlr_modulator.html
-- @value    new numeric value of the modulator
--
PositiveValue_OnChange = function(--[[ CtrlrModulator --]] mod, --[[ number --]] value, --[[ number --]] source)

	-- No action while loading a program or if the panel is in bootstrap state
	if bLoadingProgram or not isPanelReady() then
		return
	end	

	local sName= L(mod:getName())

etc...

In _OnClick methods, I'm not checking for isPanelReady()

[dnaldoog]

Hi there @dobo365 !

Thanks for your input.

	-- Reset Midi INPUT devices to avoid having MidiMessageReceived method called twice
	-- If resetting Controller devices then the bidirectional behaviour is loss (most probably a bug)
	sMidiDevices = panel:getProperty("panelMidiInputDevice")
	panel:setPropertyString("panelMidiInputDevice", "-- None")
	panel:setPropertyString("panelMidiInputDevice", sMidiDevices)

Can you explain this a little? I have seen it but never used it. Maybe I have this problem in my panels, but I've never noticed it.

avoid having MidiMessageReceived method called twice

[dobo365]

Some long time ago, I remember getting two times the same Midi messages in the Midi monitor.
This trick is used to avoid that.
I guess that I posted some topic in the old forum about this.

[subv0x]

thank you, dobo365.
what is 'b' ? bPanelLoaded, bLoadingProgram.

[dobo365]

I'm just trying to use a letter to indicate the type of variable I'm using even if in Lua there is no actual types.
Comes from the time when I was doing some Visual Basic and Excel programming.
So, I have bXXX for boolean, iXXX for integer, sXXX for string, mbXXX for memory blocks...
But actually, I'm not following this 100%. Maybe 80-90%.
It allows knowing what can can usually be expected as a boolean is true or false, etc...

[dnaldoog]

So actually that bPanelLoaded is exactly the same logic. Set false with timer.

One problem I found is when opening two of the same panel in Ctrlr, then popup objects or utils.warnWindow() may display- you then might need to block with ’source’ parameter.

[damiensellier]

Hi John, I never ever had to use those blocking scipts, but I always run a source condition for all my LUA scripts.

as a reminder when using the source filter in LUA script :

value(“initialValue”, 0),
value(“changedByHost”, 1),
value(“changedByMidiIn”, 2),
value(“changedByMidiController”, 3),
value(“changedByGUI”, 4),
value(“changedByLua”, 5),
value(“changedByProgram”, 6),
value(“changedByLink”, 7),
value(“changeByUnknown”, 8)

Here is an exemple

yourFilteredScriptByOperationSource = function(mod,value,source)
    if source == 4 then -- 4 is for changedByGUI which is an action of the user on the panel GUI
      -- your script
    end
end -- end of function

[dobo365]

Thx for the reminder, Damien! I'm using that reference all the time.

Exactly. You need to block source==6 and source==1 all the methods that are containing a utils.xxx command.
Then you may need to block some other ones.
Just try to save a preset in DAW and try to reload it and you will understand the "fun".
ReadStateData and SaveStateData are also important (all labels should be saved and restored).

Blocking with source==5 is also useful when you want to change a modulator WITHOUT running its "called when value change" method.
It is required sometimes to avoid loops and Ctrlr getting blocked due to infinite loop.

[dnaldoog]

Also, I’m getting a lot of source =2 coming in with the Korg M3R which I understand and sometimes clicking on a button gives me source =6, but not 4 - I haven’t yet worked out why it sometimes does that.

I think Damien is using 5.6 so he might not need to block on start.

[monophreak]

Hi Everyone, I'm working on a panel release for VST3 and AU and just wanted to see if this code is still the best way of working in July, 2025! Thanks

[dnaldoog]

I don’t think version 5.6.* needs panel:getBootStrapState()==true, but if you load another instance of the same panel in CtrlX then it will block popups and AlertWindows, I think. 🤔

[damiensellier]

You're absolutely right, it's working only for callbacks assigned to modulators when their value change, not on mouse events callbacks etc

[monophreak]

You're absolutely right, it's working only for callbacks assigned to modulators when their value change, not on mouse events callbacks etc

Just played with this in my panel and source really provides fantastic control. I thought I'd try this route first since everything has been written with (mod,value) and so it's easiest to change. I'm pleased to say it has made a significant difference! When changing via the Lua from a master script which loads modulator values from a received sysex message, it was not updating before (it did manually via the GUI) but by specifying source and IF == 5, it seems to be working really well. I am using a combination of

local switchDelayPlusChorus = value if source == 4 or source == 5 then...

I appreciate the local variable switchDelayPlusChorus is not needed but I put it in for speed and testing since I previously called a modulator value, held inside this variable and used it to trigger the IFs.

Part of me wonders if it would have been fine with (mod, value) but I had a fail somewhere and restart would have fixed it but I don't think this is the case (but I could be wrong). I'll see how it pans out after updating everything and if I do not have any luck, I'll try Dnaldoog's approach.

[monophreak]

After checking my code with a fine tooth comb, I found another bit of code that knocked out a Lua based value update on one of the modulator attached scripts which possibly explains why I had an inconsistencies with (mod, value). Learning about source has been a real win here though! Thank you so much for your support Damien and Dnaldoog!

Really can't wait to update all of my code. My experiments with there were great and I think it's what I'm looking for.

[dnaldoog]

Can you post the panel because something is wrong with the logic of if source == 4 or source == 5 because 4 means the user changed the value and 5 means the value was changed by lua which almost means every possibility therefore redundant. Also assigning a local variable to value, presuming value is a function parameter will do nothing, not even change the scope of value, because it’s already local.

if my code suggestion is correct ie enable/disable controls based on the MIDI value then you probably don’t need any of that filtering in callback methods attached to various controls; just address the issue when in midiReceivef.

Something like that, but I’d like to see the panel to understand what you’re trying to achieve. :)

[monophreak]

Can you post the panel because something is wrong with the logic of if source == 4 or source == 5 because 4 means the user changed the value and 5 means the value was changed by lua which almost means every possibility therefore redundant. Also assigning a local variable to value, presuming value is a function parameter will do nothing, not even change the scope of value, because it’s already local.

if my code suggestion is correct ie enable/disable controls based on the MIDI value then you probably don’t need any of that filtering in callback methods attached to various controls; just address the issue when in midiReceivef.

Something like that, but I’d like to see the panel to understand what you’re trying to achieve. :)

thanks Dnaldoog, I'll aim to knock up a snippet to show you what I'm up to at some point. I suspect it's because I'm doing something elborate due to my project being a Boss VF-1 effects unit sending large chunks of sysex rather that a synth that has lots of small sysex chains being regularly sent. I am working with split (255, 155) 410 byte chains which are then carved up through lots of smaller scripts. I do fear the complexity will come back to bite me when I roll out the VST3/AU plugin and then I'll need to re-evaluate my approach but so far, things look good and I have been testing as I go. As a postive, I commented out the source == 5 and it did indeed make an impact but this could be because I have dual scripts to update modulators by Lua code and by GUI.

[dnaldoog]

Here is a post I wrote a while back, except step 2 won’t work in CtrlrX .

Instead place that timer code in an init function when the panel has finished loading.

I’ll update that post later.

timer:setCallback(111, TimerCallback) -- TimerId 0
timer:startTimer(111, 300)

[monophreak]

Here is a post I wrote a while back, except step 2 won’t work in CtrlrX .

Instead place that timer code in an init function when the panel has finished loading.

I’ll update that post later.

timer:setCallback(111, TimerCallback) -- TimerId 0
timer:startTimer(111, 300)

Brilliant! thanks for this dnaldoog, especially for for the CtrlrX guidance.

[dnaldoog]

Great I uploaded a new example panel that uses midiBlock() and midiAllow()

myPanel Script Blocker_2_0.zip

[dnaldoog]

Also source can get a bit confusing

Also, I’m getting a lot of source =2 coming in with the Korg M3R which I understand and sometimes clicking on a button gives me source =6, but not 4 - I haven’t yet worked out why it sometimes does that.

Other solutions include:

• Disabling controls (see my example above)
• Setting a control with panel:getModulatorByName("n"):setModulatorValue(,false,false,false) -- to avoid triggering callback
• Setting a control with panel:getModulatorByName("n"):setModulatorValue(,false,true,false) from a function with pause MIDI then reenable - MIDI before and after
• Using source -- probably just if source ~= 4 then return end if you only want user to change values, not lua.
• Use a global variable as a switch. When midi received GBLOCK=true. In your callback if GBLOCK then return end -- code won't run in function
  • After processing MIDI received set GBLOCK=false, Declare GBLOCK=false in init or constructor.

example: midiReceived:

midiReceived = function(--[[ CtrlrMidiMessage --]] midi)
    local s = midi:getSize()
    if s == 24 then
        update(midi:getData():getByte(6))
    end
end
-------------------------------------------------
update = function(val)
    panel:setPropertyInt("panelMidiPauseOut", 1) -- MIDI cannot be sent
    panel:getModulatorByName("SPACE CHORUS"):setModulatorValue(val, false, true, false)
    panel:setPropertyInt("panelMidiPauseOut", 0) -- reenable MIDI can be sent
end