Posts by Andreas


    Sure, the workaround is to put your macros or whatever youd like on said executors on, say, exec page 1. Then fix them so they always are present. However, the problem with that is 1. I then only effectively have 16 x-keys instead of 40 as I had on MA2 (though I'm NOT saying I want the desk to be exactly as MA2, so dont bother starting that discussion). 2. The executors are obviously not user specific, so if you and me where sharing the programming on a show, then we would have to agree on what stuff we would want to have on there.

    While executors are shared, Executor fixation is user-specific. you can fix executors from one page, while another user can fix executors from another page.

    To mimic several userkey pages, you can create several macros, that each fixes executors from different pages:

    Macro Userkeys1

    Fix Off Executor 191 Thru 198 + 291 Thru 298

    Fix On Page "Userkeys1" Executor 191 Thru 198 + 291 Thru 298

    Macro Userkeys2

    Fix Off Executor 191 Thru 198 + 291 Thru 298

    Fix On Page "Userkeys2" Executor 191 Thru 198 + 291 Thru 298


    regarding the original topic of this hijacked thread:

    to allow requiring modules that reside under:


    - Does anyone see any potential issues with using LUA's require module, from this folder?
    - Why doesn't MA3 already include this folder in the package.path ?

    with the latest release v2.0, this is included..

    the manual describes LuaFile as a commandline keyword, not as a Lua API function

    LuaFile is just a variant of the commandline keyword Lua, to execute raw Lua:

    Lua "Echo('Hello World!')"

    LuaFile "c:/hello.lua"

    Be aware of the difference of raw lua, and a lua plugin component definition:

    hello.lua file content requirements for being executable with the LoadfFile commandline keyword:

    Echo('Hello World!')

    hello.lua file content requirements for being loadable as a plugin component

    return function() Echo('Hello World!') end

    to my understanding:

    Recipe and playback speed controls the speed of an attributes phaser-steps

    - a generator is not a phaser, it is dynamic step-value.


    Group 1 Full
    Step 2 Zero
    Step 3 Full
    Step 4 Zero
    Step 5 Full
    Step 6 Zero
    Step 7 Generator "RandomFlicker"
    Step 8 Zero
    Step 1 Thru 8 Transition 0 Measure 4

    This creates a 4 beat phaser at the given playbackspeed, where the fixtures randomly flickers instead of flashing together, on every 4th beat.

    Adjusting the playback speed, will change the BPM of the 4 beat phaser as expected, not the flickerspeed of the 4th beat (which is a property of the actual generator)

    I am certain we will see further options to control generators in cues, presets and recipes in upcoming versions.

    1. Open Phaser Editor in SheetView
    2. Select the destination steps along with the source step
    3. rightclick the transition-value of the source step
      -> Calculator opens populated with its transition value
    4. Press Please in calculator
      --> source transition value is applied to all selected step (including the destination steps)
    5. Repeat 3+4 for Width or other layers

    I have seen your other thread on this topic and it is really hard to make any sense of your approach to solve your problem

    Unless I have totally misunderstood the essence of your workflow-issue, try this small plugin:

    Plugin "Create or update Plugins" (not tested on mac)

    As far as I know, the Lua canbus-emulator of gma2 is not documented, and can only be considered as an unclosed backdoor, not an actual/intended public feature.

    With that in mind, I wouldn't hold my breath waiting for the same to appear in gma3.


    Personally I would not expect gma2 action-buttons to reappear in gma3, if anything it would be more likely that the sequencepool and its elements gets more display and action/playback options,