Posts by Andreas

BECOME PART OF THE COMMUNITY - Sign up here

    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.

    For a predictable result add the unit Percent everywhere you address phaser-layers like width, transition, phase etc

    e.g.

    At Width Percent 30

    Unfortunately in version 1.6 commandline, when no unit is specified, the Natural readout of each attribute is used, not only for Absolute/Relative layer as desired and expected, but also for other layers like Width, Transition etc,

    If the natural readout for the attribute is e.g. physical, the syntax At Width 30 is interpreted internally as At Width Physical 30 which is an undefined value for width

    Please disable AutoRemoveXgaps in your SelectionGrid window, to see if that gives a more expected gridselection result according to the actual placement of your fixtures.

    From the picture it sure looks like your bottom right fixture is not perfectly aligned in the x-axis with the others.

    Thus the lasso-tool will correctly place that fixture at e.g. xgrid 99, while the two above are placed at xgrid 100.

    This misalignment would be severely amplified when combined with the RemoveXgaps function, as the difference between these fixtures (one cell) will be maintained, while the overall size of the grid may be reduced substantially.

    1. I have a macroline that uses LUA syntax . How can I hold the macro until the actions in the LUA lines are completed(for example waiting for a user text input)

    to my knowledge you would need to either

    set Wait=Go for the macroline containing Lua, and append code at the end of your Lua to call and resume your halted macro, e.g.  ; DataPool().Macros['macro name']:CommandCall()

    or

    use Cmdline rather than Lua for user-input, and set a $variable e.g. SetUserVar myinput (your number?) which your Lua-code can access via the GetVar() function,

    or

    use a Plugin instead of a Macro, so that it is Lua that executes commandline rather than macrolines that executes Lua.
    Lua can wait for commandline via the function CmdIndirectWait(), while macrolines does not have a function to wait for Lua.

    This is technically still possible via command line - if you do "List Exec" you'll see all the properties are there. It's just that the GUI for assigning it is missing. (The button function assignment GUI had to get reworked for other reasons prior to v1.0 being released, and this part hasn't made it back in yet.)

    Technically, it is still possible via GUI as well

    - it is just not possible via the same menu as used in the Youtube video ;)

    Swipe and edit in the Page-pool, to open the generic page editor, which would give you access to the children of the page, - aka executors - and all their properties, including these.

    ----

    Be aware that MA-press-actions (e.g MAKey property ) and custom key-syntax (e.g. KeyCmd property) is not yet supported by the Executor Configuration Pool, so these settings must be defined individually per executor, and might not survive emigration to a future software-version where ExecConfigs has be refactored to support these settings as well.

    Here's a different approach, which will enable crossfade when changing colors

    Create your global static colorpreset (Red, Green, Blue, etc)

    Create an additional global static colorpreset with release-values and label it Transparent

    Create same number of global phasers, which integrates each static color as step 1 and "transparent" color as step 2

    (Red/Transp, Green/Transp, Blue/Transp etc)

    Create cues with each of your static presets in Sequence 1 "Background"

    Create cues with each of your "transparent" phasers in Sequence 2 "Foreground"

    For both sequences disable OffWhenOverridden, so they can play simultaneously without switching each other off

    Set sequence 2 to High Priority, to prevent "background" colors to overwrite and take precedence

    In your macros, use Goto Cue x Seq 1 to choose background(lowprio) color, and Goto Cue x Seq 2 to choose foreground(fx) color.

    Assuming you create the cues with recipes, all above is a one time operation, and you can update them all at once via cmdline e.g.

    Assign Group "Spots" At Sequence "Background" Cue * Part *.*

    Set Sequence "Foreground" Cue * Part *.* Property "XWings" 2

    Christof To achieve your desired mask behavior, define an ID-type (and CID) for every fixture, not only for your dimmerchannels.

    rename e.g. ID-type "Media" to "Moving" (via splitview->id-type)

    assign ID-type 'Channel' to your conventionals, and ID-type 'Moving' to the others

    This should enable you to give everything a FixtureID, while still being able to mask sheets by unique ID-type e.g. Channel and/or Moving

    You're right, this doesn't work as expected.

    from commandline-list perspective Attributes looks like a property, however from xml-export perspective Attributes looks like a child with subchildren

    I don't know if and how such a hybrid structure can be accessed with the Lua API.

    Select Filter 2 ; SaveShow ; Reboot

    -> no filter is selected

    my conclusion:

    Last selected filter is transitory and not persistent.

    If this information had existed anywhere in the object-tree it would have survived the reboot.

    Depending on why you want to know the last selected filter, this approach could possibly find it for you:

    Code
    local needle = CurrentProfile().AtFilter
    local haystack = DataPool().Filters:Children()
    for i=1, #haystack do 
      if needle.Attributes == haystack[i].Attributes then 
        Echo(haystack[i].Name)
      end
    end

    Both Export and List are functional commands, which cannot be combined like this

    General Syntax Rules - grandMA3 User Manual - Help pages of MA Lighting International GmbH

    Nevertheless, the wheel property you are looking for is fully get-able via Lua via .wheel, it just doesn't merely contain plain text like e.g. the name property, but rather returns a reference to yet another object, so you will need to again specify which property of that object you actually want

    e.g. try

    .Wheel.Name

    You can recognize such object references by using the generic Lua type() function on the returned property-value, which would give 'userdata' instead of e.g. 'string' or 'number'

    if we have access to the selection grid column count

    to create a commandline variable (e.g. $MyGridSizeX) with the current grid size you can use this Lua snippet:

    Lua "local min, max = SelectionComponentX() ; SetVar( UserVars() , 'MyGridSizeX' , max - min + 1 )"

    to create a commandline variable (e.g. $MySelectionCount) with the current selection count you can use this Lua snippet:

    Lua "SetVar( UserVars() , 'MySelectionCount' , SelectionCount() )"

    rather than trying to use such $variables as base for further calculation via commandline (which has very limited math-functionality), I recommend to include the desired calculation in the Lua snippet, e.g.

    Lua "SetVar( UserVars() , 'Step1Width' , 100/SelectionCount() )"

    Lua "SetVar( UserVars() , 'Step2Width' , 100 - 100/SelectionCount() )"

    This is a known limitation, and how recipes and matricks-phase currently works (v1.6).

    To get an even phase spread on different selections, you will need to either:

    A)

    Combine the matricks phase with a matching matricks grouping,

    e.g. [group=4, phase=0-270] or e.g. [width=6, phase=0-300]

    B)

    use the "0 thru 360" / "0 thru -360" buttons in the attribute calculators, the "360" button in the PhaserEditor or "At Phase Percent 0 Thru 360" / "At Phase Percent 0 Thru -360" in commandline.

    Only these interactions will (in v1.6) trigger the special internal function that automatically calculate and apply the actual phase-range needed to give an even spread, instead of applying the specified range literally (giving first and last equivalent phasevalues, 0 and 360)

    I want, whatever the selection is, a dimmer chaser, fixtures one by one. Not by range.

    This is not (yet) possible with recipes and/or universal presets

    I don't understand what you say : phase and width don't depend of my selection count.

    What I tried to emphasize is that distributed values depends on your selection GRID, not selection COUNT

    e.g

    Open a selection grid window and disable auto-remove-x-gaps

    ClearAll

    Fixture 1

    Fixture 2

    Fixture 3

    At 0 Thru 100

    -> SelectionCount = 3

    -> F1 = 0%, F2 =50%, F3 = 100%

    ClearAll

    Fixture 1

    Fixture 2

    Grid 10

    Fixture 3

    At 0 Thru 100

    -> SelectionCount = 3

    -> F1 = 0%, F2 =10%, F3 = 100%

    In both scenarios selection-count (and selection order) is the same, but the values distributed to e.g fixture 2 is different.

    Could you explain when stored in a sequence and assigned to a speedmaster which step the phaser starts on a go?

    There seems to be an issue in the current release with phaseclock in combination with speedmasters.

    After you have assigned the sequence to an external speedmaster, all bets are off regarding where in the cycle the phaser starts, even if you remove the speedmaster assignment again.

    If you need a dedicated startpoint of the phaseclock more than the speedmaster, you can copy the sequence to a fresh new sequence slot, and remove the speedmaster assignment (before you start it)