Posts by A_art


    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

    Lua "MyFunction('helloworld',42,'Yippee')"

    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

            --function code
            --function code

    Now you can call them from a macro with

    Lua "MyPlugin.Myfun1('p1','p2')"
    Lua "MyPlugin.Myfun2('px','py')"

    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").

    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 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)

    if the groups are equal, then it returns


    object comparation success

    if not it returns


    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.

    This code prints the macro numbers and names to the commandline history...

    return function()
        local macros=DataPool().Macros:Children()
        for _,macro in ipairs(macros) do
            Printf('no:%d, name:%s3',,

    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

    it returns:




    You have to extract it from the UserVars object (…/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...


    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: