sometimes a cue won't be stored.

BECOME PART OF THE COMMUNITY - Sign up here
  • Hey all!

    I have a question about the syntax of storing cue's. I have a macro wich picks a group of fixtures, select an matricks interleave and go at preset 21.1. Then it needs to be stored at different cue's in an sequence. But fore some reason som cue's won't be stored and then i miss a step. In the screenshot below you can see the syntax i'm using and what's going wrong. I have read the manual and the release notes but can't find the solution.

    Thanks in advance!

  • 1. add /nc to macroline 2 to prevent the macro-execution from being interrupted by delete confirmation popup

    2. use separate macrolines for each command

    you should not combine several commands into one macroline with semicolon, if any of them depends on the previous one being completed for the next one to function. When they are all in one line, they will practically be executed simultaneously.

  • In addition to what Andreas said, I would add a short Wait time (start with e.g. 0.1s and then adjust down from there) to each line that Stores something if the next line is ClearAll.

    You could also streamline this in other ways. For example:

    1. ClearAll
      • From what I can tell, this macro doesn't rely on Blind being on or off anyway, so you don't have to turn it off here
    2. Delete Sequence 999 /nc
      • Is there a reason that you're specifying cues 1 thru 100 rather than the whole sequence? Especially when you have macro lines later on that assign it to an exec and change other settings?
    3. Group 1 At Preset 21.1
    4. Set Selection MAtricks "XGroup" 4
    5. Next
      • I put "Next" rather than "Set Selection MAtricks 'X' 0" in case your selection doesn't start with a Selection Grid X-coordinate of 0
    6. Store /activeforselected Sequence 999 Cue 1
      • Because this uses the option "Active for Selected", it only stores the active information for the first 1/4 of your fixtures (even though all of them have active data)
      • Since you've already Deleted Sequence 999 anyway, no need for the /overwrite option
    7. Next
    8. Store /activeforselected Sequence 999 Cue 2
    9. Next
    10. Store /activeforselected Sequence 999 Cue 3
    11. Next
    12. Store /activeforselected Sequence 999 Cue 4
      • Could add a short wait to this line
    13. ClearAll
    14. Assign Sequence 999 At Exec 476
    15. ...
  • Hi Benoit,

    I have no clue if there are any plans to implement the equivalent of gma2 [conditions] and $systemvars, and if so, any timeframe for this to happen.

    Nevertheless below are my personal opinion on this topic:

    ------

    I think everybody (both users, the software developers and last but not least the commandline interpreter and the realtime engine) would benefit (in the long run) from not implementing gma2 commandline loops, conditions and systemvars.

    All this (and so much more) is already accessible via the Lua API and possible with plugins, so rather than re-implementing a fraction of the functionality as commandline to use in macros, I think it would be better to document and streamline the Lua API and improve the Plugin Editor and its user experience.

    Commandline loops, conditions and systemvars.could take your gma2 macros to the next level - but they will get stuck there (at level 2)

    gma3 Lua API and Plugins goes to 11 - and beyond.

    Focus and dev-time should be used to lower the entry level of the Elevator that goes to 11, not to put out some soapboxes that lets the user easily climb to second level, but not any further.

  • [...] LUA is not so simple for anyone and as you say, the GUI is not friendly.

    For now. Dev time would have to be spent on implementing the more limited macro functionality in the command line anyway. So I believe Andreas is saying he would rather that same dev time instead be spent on improving the Lua UI and maybe adding tools to the macro editor to easily insert Lua snippets or something along those lines.

  • Here's a few relatively simple plugin scripts replicating Ryan's macro


  • I agree but LUA is not so simple for anyone and as you say, the GUI is not friendly.

    Writing Lua directly on the console, while doable can be a pain. However using VSCode and onPC makes is quick and easy to iterate. You can as Andras posted copy the code directly into the Lua Component Line, but I feel that's really good if you are copy and pasting code you know works. If you are making your own plugin or new with plugins/lua altogether it can be a hard way to work and troubleshoot (let's face it you spend more time fixing issues then actually writing code)

    I have been wanting to add a "Getting Started with Lua" on the wiki but just no time at the moment so here are a few hints to get started.

    I'm writing this from my Mac but the process basically the same on Windows.

    First the tools:

    You will need a onPC and a text or Code editor. While you can easily edit lua via Notepad or TextEdit life is much easier using VSCode, Sublime text, Atom, Notepad++ or any other IDE. This way you can add Syntax highlighting and lint checkers to aid in writing working code.

    I personally use VSCode. If you are using an IDE with extensions often you have lots of Lua options for helpers you can add.


    Once you have both onPC and your Editor (in this case VSCode) installed its time to configure:

    First we need a workspace for your lua programming on the console. Since 1.6 things have become much easier and all you need to do is add the plugin folder to:

    ~/MALightingTechnology/gma3_library/datapools/plugins on the mac or

    C:\ProgramData\MALightingTechnology\gma3_library\datapools\plugins on windows.

    To do this from VSCode go yo File > Add Folder to Workspace... and choose you plugin directory.

    Now open the file Explorer on the left hand side of the VSCode window by Shift + Command + E (mac)

    Or clicking on the Top left icon


    Now you can open the plugins folder by clicking on the disclosure arrow next to the plugins and you should see a libcache.dat file as well as any other plugins you currently have loaded on the console.


    Let's write some code

    So how do use use all of this to our advantage? because we are editing code directly in the consoles file system we can quickly edit, save and reload the plugin to see results. iteration, the new programmers best friend.


    Let's start by writing Andrases Level 1 code:

    There are a number of ways of starting a plugin project but we will start here by creating both a lua and xml file.

    First Right click on the plugins folder in the VScode Explorer and choose new file end enter the name level1.lua. Next right click on the plugins folder again and create a new file called level1.xml.

    Now lets edit the XML file, this file tells the console lua object about your code. it's mostly boiler plate code you can copy and paste and replace the Names, versions and files to fit your needs.

    For example here is the XML for our level1 example:

    XML
    <?xml version="1.0" encoding="UTF-8"?>
    <GMA3 DataVersion="1.6.1.3">
        <Plugin Name="Level 1" Author="Hoss" Version="1.0.0.1">
            <ComponentLua Name="Level 1" FileName="level1.lua" Installed="No"/>
        </Plugin>
    </GMA3>

    Some of these XML options might be incorrect but I'm sure someone will correct me.

    Save the XML file and next lets edit our Lua code. I'll just copy and paste the code from the forums (though I had to make updates to make the external LUA work, but the business logic is the same.


    Now with all of your files saved open onPC and lets import the plugin. Edit a plugin -> Import and select Level 1

    Close the Edit window and use the plugin.

    While I'm writing a plugin I normally have a macro right beside it that reloads the plugin after I have made a code change and saved

    Something like:

    Import Plugin 1 "level1.xml"

    Once you press that macro you can call your macro again and see the changes.


    Once the Documentation is available writing plugins can be a ton faster then trying to make it fit into a macro, and if you get your development environment setup you can quickly make new plugins with ease.

    on my development machine I have it show all syntax errors and I have a file in my workspace that includes all the MA spacific APIs so I can actually tell when I'm making a mistake (often), but hopefully I can find some time to update the wiki with that info.

  • hoss Very nice work on the explanations. The point here though is that this could be made easier to do in the console so that you don't have to pull out your computer to do it in a separate IDE (when you're already in front of a console), or even know how to write Lua generally, to be able to integrate relatively simple conditions, loops, math functions, and so forth into grandMA3 macros.

  • I agree the UI needs work; but with finite development time something's got to give.

    In a perfect world the Lua window would syntax highlight, lint check, and intellisense so you could just enter it on the console and easily debug, without having to lookup documentation.

    In the meantime if you have an idea, log your onPC into session, write the plugin onPC then and export it from the console to the console when your done, but I also get it the issue.

    Id so much rater do this directly on the console:

    But I'm guessing at API calls. The console should help in that regard, but if it looked like this that would go a long way.

    Edited once, last by hoss (October 15, 2021 at 5:56 AM).

  • While I'm writing a plugin I normally have a macro right beside it that reloads the plugin after I have made a code change and saved


    Something like:

    Import Plugin 1 "level1.xml"


    Once you press that macro you can call your macro again and see the changes.

    You can do this even faster. Just execute the ReloadPlugin command. When the external lua file has changed, the new content will automatically imported to the plugin in the pool.

  • I recommend to use ReloadPlugins.

    - not for speed, but for proper debugging.

    example

    Code: Iteration 1
    return function()
    local VarName = 1
    -- lots of code
    VarNane = 5
    -- lots of code
    Echo(VarNane)
    end

    seems ok, Echos 5 as expected, but for some reason you see the spelling error in line 4 and fix it, and re-import the plugin

    Code: Iteration 2
    return function()
    local VarName = 1
    -- lots of code
    VarName = 5
    -- lots of code
    Echo(VarNane)
    end

    seems ok, it Echos 5,

    However this is only because of the existence of global VarNane, with a value which was set by the first iteration of the code, and is still in the plugin engine.

    Once you reload your show (and therby the pluginengine) the plugin fails, as you didn't notice that there was a second spelling error.

    by calling ReloadPlugins, instead of just doing a reimport of Plugin, you will cleanup any potential mess made by previous iterations, and capture more potential issues with the latest iteration of your code.

  • However ReloadPlugin vs ReloadPlugins that makes the world of difference.

    When dherderich mentioned ReloadPlugin I thought he meant something like ReloadPlugin 1, without looking at any documentation that seemed sensible.

    Now that you said ReloadPlugins and I looked in help makes sense, dump ALL the plugins and reload them. Again sensible but not exactly what I was reacting to.

    Either Way good to know, Having a Linter in VSCode would have caught the syntax error (just not MY spelling mistakes :)

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!