Posts by hoss

BECOME PART OF THE COMMUNITY - Sign up here

    Works for me, However a few things.


    You should check the actual name of the Attribute In some cases the Displayed name is different from the actual Attribute name..


    For example, Focus might be "Focus1"



    So in that case the Command would be:

    Attribute "Focus1" at + 1 or Attribute "Focus1" at - 1



    None of that should cause the console to freeze though.

    I've been up to my eyeballs in other projects so I haven't had any time to update my wiki for a very long time, but everything that's on there is stuff I have just played with to figure out.


    Though I look forward to when the docs are fully up to date there are some core features of the console that need work before we can hope to get any finalized APIs and documentation.


    My guess is they are holding off on documenting everything since lots might change in the future, but who knows?

    I just went back a read that part of the manual and it seems very clear to me.


    The paragraph right before the one you quoted laid out the rules:



    While it's almost impossible for manuals to be perfect, I honestly think the documentation team has done a great job, and for the most part, it's very clear.


    If you have done the training then the best thing you can do is practice in small chunks until you get a handle on each concept one at a time. While it's always good to work towards a project when you are starting out repetition is king.

    The little chips (I don't remember what they are called) at the top of Encoders, Fixture sheet values and Presets and Groups represent the layer that the object that holds values.



    The actual colours form from the lines above the encoder layers:


    However, Some Caveats:

    • If only Absolute (Red) value is stored it does not show a chip in pool items, but it does in the fixture sheet.
    • Phase (Purple) does not show up in pool items but it does in the fixture sheet (I honestly hadn't noticed this until now)

    Now on the fixture sheet, there are a number of additions

    • The Chips above denote what values are in the programmer ( with the addition of Cyan and Dark Cyan at the end, not sure what they are but I'm sure it's in the manual if I were to look)
    • The background denotes if that value is active or not, its colour depends on what layer you are looking at. If you are in Auto this shows what layer you have selected on the encoder bar.

    Here I'm on the Absolute Layer


    Now the Delay Layer:


    Now the same after pressing clear twice (removing it from being active) the value is still red since it's still in the programmer:



    If I store some cues the colour of the text denotes what layer that data is coming from, with the exception of Dimmer which adds two more colours,


    • Green if the dimmer value went down from the previous cue
    • Cyan if it went up


    In the above image, we are looking at Cue 2. In Cue 1 Fixture 1 @ 100, Fixture 2 @ 0


    I'm sure there is a ton I'm missing but that is the gist of it.

    So Not sure if this is your exact issue since you did not explain how it was not working but here is my best guess, as it seems to work as it should.


    Here I have three Groups:

    1. 1 thru 10
    2. 10 thru 1
    3. 1 thru 10 wings 2

    If you look at these groups on the Selection Grid they display as follows:

    1. This is a graphical z-fighting bug, 1, and 10 occupy the same space, 2 and 9, 3 and 8, and so on.

    Now when you apply a range on the current selection it always goes from left to right on the selection grid (at least on the x-axis)


    Using Dimmer as an example typing at 0 thru 100 on each group would look like this:

    The exact same principle works with other layers such as Phase. they apply to the selection order (or selection grid) from left to right.


    And you can see this on the phase layer of the Fixture Sheet, This is Group 3 then Phase 0 through 360:



    The thing that sometimes throws people off is that the selection order is ONLY the order the fixtures are selected not how the values are interpreted. If I applied 0 thru 360 to Group 3 then I select Group 1, nothing will happen on stage, but the selection order will change leaving the values as they were.


    Again for illustration using the Dimmer, this is the selection grid after Group 3, then At 0 thru 100 then Group 1


    Notice the selection order changed but the values in the programmer did not. In order to have the values change you would need to call the range values onto the new selection.


    I hope this makes sense, and is actually your issue, again more information would be required to say Why it isn't working the way you expect.

    The issue is probably that the selection order is changing but your phase isn't.


    You can confirm this by looking at the Selection Grid and the Phase layer in the fixture sheet. Changing the Shuffle changes the selection grid but the phase values are still saved to the same fixtures (thus nothing changes) you can probably fix this using recipes.

    I'm sure there is a better way but as a workaround, you could get a random number from LUA.


    This one-liner will get a random number from 0 to 100 and store it in the RND UserVariable.


    lua"SetVar(UserVars(),'RND', tostring(math.floor(math.random()*100)))"


    The Lua expanded out it looks like this:


    Code
    local uv = UserVars()
    local name = "RND"
    local scale = 100
    math.randomseed(os.time()) -- you *might* need this at least once to avoid getting the same "random" pattern
    SetVar(uv,name, tostring(math.floor(math.random()*scale)))


    You can then use the variable in your macro

    I think the current workaround is to use a DMX remote listening for a trigger of 0


    of is you are onPC you can also do it from commandline


    One of the many ways to fix this is to hit Assign then hit the master or hit its label from the Custom Masters window or on the letterbox screen if you have one.


    From the Assign Special Exec window change to the Object Tab on the left and select what you want that master to be from the top tabs.


    Assign Object to an Executor - grandMA3 User Manual - Help pages of MA Lighting International GmbH


    or more specifically:


    SpecialExecutor Keyword - grandMA3 User Manual - Help pages of MA Lighting International GmbH

    Yes, this is correct behaviour since the delay time is a layer like any other that is called back into the programmer and in this case, there is no delay information that is stored in the second preset it uses its previous recalled values.


    So for example:

    You make a red preset with Absolute values and Delay values and it will look like this in the presets:

    The red tick at the top denotes that absolute values are stored, while the orange denotes that delay values are stored.


    Next, you make a green preset this time only storing Absolute values. This one does not show any ticks (I assume because it only holds absolute value).


    Now when you call the red preset it calls the Absolute values AND the Delay values into the programmer. Then when you recall the green preset it only calls the Absolute values keeping the previous Delay values.


    There are a few ways around this:


    • Press the Green preset a second time, this will overwrite the red preset data with the green data (thus no delay timing)
    • Store a 0 Delay time Color Preset holding only the delay time and no absolute time, then you could hit this preset first followed by the green preset.
    • Don't store the delay time in the colour preset and make a timing-only preset holding only the delay time, then you could apply the delay to red, green or neither.


    and I'm sure other ways as well.

    This is quite strange because I am using fixture x at fixture y quite often and it works fine.

    you are updating with “original content” or “add new content”?


    With Original content.


    This example is with a new show and two fixtures patched and it fails every time.


    1 At 100

    2 At 50

    Store Cue 1

    Go+

    Fixture 2 at Fixture 1 /o

    Update


    In this case Cue 1 is active with Fixture 1 and 2 Dimmer information. Fixture 2 @ 1 should copy dimmer information that already exists in Cue 1 so Original Content should work.


    Fixture At Fixture itself does work but updating with information from the fixture copy does not. The workaround is to Store Merge but given that it works in MA 2, this definitely seems broken.

    After doing another system today it seems that the USB upgrade path did not solve the issue, we just were done messing with the patch.


    Another way I was sometimes able to solve the issue was going to the node and Entering the Port menu -> Port Mode and just touching the Mode (e.g Out) at that point some of the nodes unlock and start working.


    The really unfortunate part is rebooting the desk or node via the desk does not seem to solve the issue.

    Did you by chance upgrade the firmware of the PU or Nodes via the console?


    I had a similar issue where I had 8 nodes that were all upgraded via the console, everything was working fine until some point where all of the nodes would stop outputting DMX but we're still online. Not even rebooting brought them back on line.


    I went up to one of the nodes and just adjusted the port configuration and all of the nodes started outputting again for a little while then 'locked up' again.


    I called into ACT and they suggested doing a firmware update on the nodes using the usb stick. After I did them all everything seemed to work for at least 4 hours without issue.


    I did not notice when they stopped responding but it makes sense editting the patch since we were in the process of re doing a show from MA2 to MA3 and we're starting fresh and in and out of the patch often.

    Just ran into this, and eventually, I got it working but with some jigging and poking.


    So to test, first start by doing a clean start


    Fullscreen Screen 1 on Display 1

    Fullscreen Screen 2 on Display 2

    Exit and Safe

    Restart and Display 2 goes full screen onto Display 1 not 2 as expected.


    If you don't maximize the window it does remember both the position and display. This led me to realize if I do the following It seems to remember where it should be in fullscreen.


    Fullscreen Screen 1 on Display 1

    Place Screen 2 on Display 2 (NOT in fullscreen)

    Exit and Save

    Restart

    Fullscreen Display 2 on screen 2

    Exit and Save

    Restart and Now Screen 2 is full screen on Display 2


    Hopefully, this survives a reboot.

    I honestly hadn't noticed this before, but I checked in 1.7 and 1.5 and it seems also to do the same thing:

    1 At 100

    2 At 50

    Store Cue 1

    Go+

    Fixture 2 at 100

    Update


    It works as expected.


    However, this does not:

    1 At 100

    2 At 50

    Store Cue 1

    Go+

    Fixture 2 at Fixture 1 /o

    Update


    Fixture 2 if left stranded in the programmer


    This only stores fixture 3 and not fixture 2:

    1 At 100

    2 At 50

    3 At 10

    Store Cue 1

    Go+

    3 At 50

    Fixture 2 at Fixture 1 /o

    Update