Posts by hoss


    So, I've got a question about Timecode Ranges.

    In the example below I have one track with 3 ranges (Intro=red, Verse=green, Chorus=blue) and each range has 3 Go+s.

    Since Events are applied to a range and the time shown in the text view is relative to the range start the first cue in each range starts at 1 second then 20 seconds and so on.

    Sorting by Time arranges all the events based on their relative time from the start of their applied range, so all of the first events in each range are lumped together. Sorting by any other header seems to maybe sort by when the event was stored so not necessarily in any usable order.

    Since you can't see what range an event is applied to there is no option of sorting by range then perhaps time.

    Might it be possible to either show the range that an event is part of in the text mode and if you sort by this field it sorts by range then time or, (and this is probably hard) show the absolute time of the event in the text view (maybe disabling editing of that field to avoid issues when you move the range) so you can sort by time and have the events show up in the correct order. Even allowing to filter the text view by Track or Track Group would help.

    Originally I thought this could be fixed using Tracks or Track Groups but these run into the same sorting issue.

    I still see Ranges as very helpful if you want to copy/paste a range to multiple parts of your timecode, as long as you only refer to the start of the range it's kind of like a black box, but then you later go and try to edit the event timing from the Text list it's not very intuitive, it's easy enough from the Timeline View using the Encoders but it seems like The Text view is a missed opportunity for flexibility.

    Not sure when this issue was introduced but it seems that some windows don't allow you to save more than one window preference.

    In the fixture window, you can make some window adjustments then go to the MA>Save>Save to add a new entry if one does not exist. The UX is a bit inconsistent (sometimes you can just save others you need to insert and then save) but it works.

    However on some other windows (only tested System Info, DMX, and Color Picker, Preset/Pool Items) the Insert button causes an error meaning you are only able to save a single entry.

    For example from the DMX window I go to MA>Save>Insert it enters this into the command line Insert Type DmxSheetSettings UIGridSelection that causes an Illegal object error.

    This is further complicated in pool items it seems since if the list is empty and you insert you get an error so you must save first to add and save in one go; then the next config you would like to save the Insert button works, but that same process does not work on the DMX Sheet.

    Nothing big just odd and inconsistent.

    Hey all, it's been a while 🙋🏾‍♂️

    So I haven't dropped maintaining the wiki over on Git Hub, but I've been busy with other projects in lots of languages other than lua, and haven't had much time to research/update any pages recently.

    I have however noticed there is still a fair number of consistent views on the pages and was wondering:

    If I had some time what would we like to see updated? and Has anyone found any glaring issues that need to be fixed?

    I know the official pages have been updated and added to over time, so I'm been reluctant to add without adding a little value. Ideally, I'd like to add topics with concrete examples of how to use them, but this takes time and testing (and fixing my spelling and typos).

    Just wondering if anyone finds the info on the wiki there useful, or should I leave it to the professionals over at MA?

    I'm like 60 posts behind here on the forums, so hopefully, I haven't missed something.

    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:

    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


    Fixture 2 at Fixture 1 /o


    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.