To move a temp fader on any page you can use this syntax:
FaderTemp Page 5.205 at 50
Unfortunately it only accepts absolute values (so far)
To move a temp fader on any page you can use this syntax:
FaderTemp Page 5.205 at 50
Unfortunately it only accepts absolute values (so far)
Display Morejfarrow A_art
Are you interested in developing in TypeScript?
(Using the TypeScriptToLua library)
I personally would use LUA for small projects,
but when a plugin gets big, I would use TypeScript.
Personally I never use TypeScript. Just try to keep my plugins small enough to handle them nicely with Lua in VS Code.
Completely agree with the danger of using global variables. (I even reacted with a warning about this in another thread some weeks ago) Sorry for not mentioning this at the first time and thanks for correcting me.
Now, The way I use globals:
- Exclusively for tables that hold functions or universal constants for all my plugins
- Each table has a unique name that start with [author]_[plugin]
- Only for functions that need to be called from other plugins or from macro´s
During development I use a special plugin that reloads the current project with the loadfile Lua command. Since all global variables I use are given their value on declaration the are reset in the process so I never encountered any problem of persistent globals between version updates. All show dependent information I store in objects that are saved with the show, so persistent globals between shows do not cause any problem either.
Nevertheless global variables do have their function in plugins and should not be ignored. The mere fact that something is dangerous does not mean that one should never use it, only that one should be careful. The label or number of a plugin can be easily changed by the user and a plugin might have many functions that are intended to be called from macro´s or the command line. Therefore I prefer to implement direct calls to functions in global tables assuming the obvious risks of this construction.
Instead of calling a plugin, you can also call directly any global function inside the plugin
If you have several functions in your plugin you want to call from macro's or from the command line, you can call them individually.
You can also 'bundle' all the functions of a plugin in a table for a better identification
MyPlugin={
MyFun1=function(param1,param2)
--function code
end,
MyFun2=function(paramx,paramy)
--function code
end,
}
Now you can call them from a macro with
I took the grandMA3_lua_functions.txt file and reworked it for use as a library with Visual Studio Code.
Great, I´ve been working at a similar project. I have included also the object API functions, the Enums table and a GMA3 table holding handles to all Object-Free API functions but all of this is still in a testing phase struggling with similar problems as you described. When I have working tested beta version I will publish the link here.
You return notempty as second function to the MA plugin call. This second function is only for cleanup purposes and does not gave access to the API DataPool() therefore returns an error for calling a nil value. I tried your second function separately and it works fine.
I created a workaround that closes the progress bar without user intervention. A second function will check every 0.2 seconds if the man function has crashed. In this test I call the second function with a plugin call, but you could also use an asymmetric Lua function call. Beware that if you want to try this, that the plugin calls itself by it´s name ("Crash Test").
local b_crashed=false
local b_success=false
local b_secondcall=false
local f_crashtest=function()
b_secondcall=false
repeat
if b_crashed then
Confirm('Main has crashed')
for i_pb=0,100 do
StopProgress(i_pb)
end
return
end
WaitModal(0.2)
until b_success
end
local f_main=function ()
if b_secondcall then f_crashtest() return end
b_secondcall=true
CmdIndirect('Plugin "Crash Test"')
b_crashed=false
b_success=false
local i_progress=StartProgress("main progress bar")
if not Confirm('Main Routine') then
error('some error occured')
end
StopProgress(i_progress)
b_success=true
end
local f_cleanup=function ()
if not b_success then
b_crashed=true
end
end
return f_main,f_cleanup
Display More
Just curious, earlier this thread you say that the cleanup function (here the local function exit) does not have access to the API, but is Echo not a part of the API then?
Totally spontaneous reaction as a programmer...
How can func2() know about mybar?
mybar was defined in func1()...
My mind would read this as StopProgress(null) - unless mybar had been defined at an upper level and object-transferred when the functions were called. - of which the code does not show.
mybar is not declared local, so it is global and will 'live' until you restart the console or perform 'everything off'
Just had a quick glance at your +1000 lines plugin, so this comment is more of a guess but you could try it.
With respect of your first question, You might try to call the lua function directly from lua instead of calling it with the go plugin command.
The main problem I believe that you have in your plugin might be some global variables. Every variable that you use that is not specifically declared local with the local keyword in the first use, is declared global. Probably you use a variable called 'type' somewhere in the plugin that overwrites the lua keyword type. When this type variable is global, this will create a conflict when the console software uses the lua type keyword.
Try to declare all of your variables, including functions and sub-functions local, except for those that you really need to be global (that might be none) In this case you might have to have the main function to be global so that you can call it from inside itself. Be especially careful with the names of any global function or variable (a function is in fact hold inside a variable). These names must be globally unique and you don´t know what other names are used by lua code inside the MA software, so use names that are not likely used by someone else.
Now that this thread has come back to live, I am wondering about this workflow. I don´t understand why you would like to merge everything to the main sequence. One of the nice things from time-code in my opinion is that you can keep your sequences (or songs) separate while editing only the offset of the timecode. This makes it easy to adapt your show if a song is skipped, inserted or altered...
Just tried it in 1.8.8.2. I have the same effect. When I set my fixtures to a press and then store this in a sequence, the reference arrow appears. This I accept as a normal behavior, since the preset is referenced to (by the cue). However, when I Oops to undo the store action the referenced sign stays. When I try to delete the preset, the warning appears that the preset has references although it does not have any anymore.
try this code
return function()
local g1 = DataPool().Groups[1]
local g2 = DataPool().Groups[2]
local equel,result = g1:Compare(g2)
Printf(equel)
Printf(result)
end
if the groups are equal, then it returns
1
object comparation success
if not it returns
0
object comparation failed: compare class Group.
The following function is probably slow not very elegant, but it returns the cue parts where the fixture is used. As parameter in needs the fixture id in string format. It loops thru all fixtures of all parts of all cues of all the sequences and holds a record of where the fixture you look for es encountered. Finally it prints the results to the command line history. Maybe this can be the base of a more elaborated plugin, but hopefully someone comes up with a better solution.
FixRef=function (s_fixid)
local t_ref={}
local t_sequences=DataPool().sequences:Children()
for _,u_seq in ipairs(t_sequences) do
local i_seq=u_seq.no
local t_cues=u_seq:Children()
for _,u_cue in ipairs(t_cues) do
if u_cue.no then
local i_cue=u_cue.no
local t_parts=u_cue:Children()
for _,u_part in ipairs(t_parts) do
local s_part=u_part.name
local t_phasers=GetPresetData(u_part)
for k,v in pairs(t_phasers) do
if k~='count' then
local uichn=GetUIChannel(tonumber(k))
if tostring(uichn.sf_index)==s_fixid then
local s_key=string.format('sequence %d cue %d %s',i_seq,i_cue,s_part)
t_ref[i_seq]=t_ref[i_seq] or {}
t_ref[i_seq][i_cue]=t_ref[i_seq][i_cue] or {}
t_ref[i_seq][i_cue][s_part]=true
end
end
end
end
end
end
end
for i_seq,t_seq in pairs(t_ref) do
Printf('found in sequence %d',i_seq)
for i_cue, t_cue in pairs(t_seq) do
Printf(' cue %s',tostring(i_cue/1000))
for s_part,_ in pairs(t_cue) do
Printf(' %s',s_part)
end
end
end
end
Display More
Yes, of course, and many thanks for your patience. I finally got the origin of my confusion and it was at a very different place.
To check the results before using them in the plugin I have a small function that prints the content of a table. In this function I used the Printf API function. For all number values I user the %f placeholder and now I discovered that the Printf function does not print the expected result with the %f placeholder. When I run the following code:
return function()
local k="test"
local v=1
Printf('%s=%s',tostring(k),tostring(v))
Printf('%s=%f',tostring(k),v)
Printf('%s=%s',tostring(k),string.format('%f',v))
end
it returns:
test=1
test=0.000000
test=1.000000
You have to extract it from the UserVars object (https://help2.malighting.com/P…a_uservars/en/1.8/uservar)
Lua "local s,p,o=2,2,GetVar(UserVars(), "Offset" for _,w in ipairs(ObjectList('ScreenContent '..s..'.*')) do if w.Name=='WindowPresetPool' and w.PresetPoolType==p-1 then w.WindowScrollPositions.ScrollV=o..','..o end end"
Ok, just saw that Andreas responded the same thing before on the same question. Seems that this thread is been posted in two different places...
Great, that works. Still I wonder what the difference is between the OK and the Cancel button without the commands...
Hi,
I created this thread an hour ago and deleted it because I thought I had it resolved, but I have not. Sorry for the inconvenience.
The thing is that I am using a messagebox in a plugin and I want the plugin to stop if the user cancels out of the messagebox. To my surprise the result from the messagebox is the same on Cancel or OK. In both cases 'success' in the return table is true. Only if I hit the escape key (on a pc keyboard) to exit the messagebox success´´ turns into false. Do I miss something? Is there a way to know if the user has hit the OK or Cancel button or is this a little bug?
This code will print the content of a preset to the command line history:
PrintTable=function (t_table,s_prefix)
s_prefix=s_prefix or ''
for k,v in pairs(t_table) do
if type(v)=="number" then Printf('%s%s=%s',s_prefix,tostring(k),tostring(v))
elseif type(v)=="number" then Printf('%s%s="%s"',s_prefix,tostring(k),v)
elseif type(v)=="boolean" then
if v then Printf('%s%s=true',s_prefix,tostring(k))
else Printf('%s%s=false',s_prefix,tostring(k)) end
elseif type(v)=="table" then
Printf('%s%s-----',s_prefix,tostring(k))
PrintTable(v,s_prefix..' ')
else Printf('%s%s=%s',s_prefix,tostring(k),type(v))
end
end
end
local presetdata=function()
local my_preset_handle = DataPool().PresetPools[4][1]
local content_table = GetPresetData(my_preset_handle)
PrintTable(content_table)
end
return presetdata
Display More