Posts by strobie


    MATricks is exactly what you are describing (for fixture timings).

    No it is not. It deals exclusively with the selection that timing information might apply to, but doesn’t deal with the time information it’s self. For the time part, you have to manually apply some time or range of time for a given Matricks selection. And this information is only stored at the end point, ie a cue or maybe a preset. To update the timing at a discrete or global level, we have to update a non referenced, essentially hard time value on some attribute somewhere in a single cue, per cue. Then when we make a new selection we must do that again and so on.

    time presets would not care about matricks since they are applied on their own layer irrelivant of a selection.

    This feature is undeniably one of the most powerful ways possible to deal with timing. To my knowledge nobody else does this, becuase they just include timing into the preset and reference it there.

    But doing it the way I have described above, allows for 1 single set of presets instead of multiple duplicates which are swapped out during an update task.

    And instead just a couple of time presets which can be directly assigned to a preset on a per fixture type, per selection basis.

    if users here do not understand it that’s ok, I’m am POSITIVE that people at MA Lighting will understand what I am proposing.

    It’s already not too far outside the current work flows, so I don’t thing it will alienate anyone. And it still allows for the current “old way of handeling fade and delay times at an attribute level. Only this time instead of essentially hard values, there is a fully refferenced solution.

    No, absolutely not. MAtricks has nothing to do with time. That is purely a selection tool only tool.

    What I am talking about is a “Time Preset” That is, a preset which can only contain time information.

    it would act like something between a filter and a preset, contain “slots” of time values which can be super imposed onto selections at an atrribute level.

    Kind of like how some other consoles deal with groups, where if you have group 1 being referred as the selection of an effect, then you make some other selection and and store override that group, the effect instantly updates to the new selection in the updated group. this obs isn’t the case in grandma 1, 2, or 3, but something like this is what I’m talking about, only instead of a selection based object, I want the object to be Time.


    1. Open the “Time” pool and edit an empty Time tile.

    2. Select the attribute from the available list of attributes you would like your Time preset to apply to.

    3. Make a selection of fixtures and “take selection” and add a time range.

    4. Do this on as many lines as needed, or just one line.

    5. Close the editor and Label this time preset “Beam default”

    6. Make a copy of this “Time preset”, adjusting the attributes, and maybe the selection u till you have a series of these
    “Time” presents.

    7. Assign Time “Beam Default” at cue a or at seq b or assign property “off time” “Beam Default” at exec 1.2, or assign it to recipe lines xyz123, or group “Beam <>” or all of the above.

    8. Press some buttons at a show, nice it’s looking good. Now let’s run a macro to copy Time “Beam ><“ at Time “Beam <>” /m.

    Now every cue or place that references the Time preset “Beam Default” is instantly updated to take the new updated time settings of “Beam ><“.

    The idea is to keep this away from the preset Layer, which limits its use ability, and requires the creation of to many duplicate presets.
    And instead have a pool that handles time.

    A time object, that contains all possible discrete timing information as a fixed data object, which can be applied to any applicable object (a group, cue, cue part, cue in, cue out, release, go, go back, off time, phaser in cue or cue object or handle ect)

    Since we are a database, and everything in the database is an object or an operator or a location or a destination ect. I would like to vote that we make time our Bi*tch.

    Would it not make sense for time to be a user definable object with its own pool?

    In the same way we can apply a selection to a group, or a group to a preset or an appearance to a cue, I think it would be very advantageous to have a “thing” which deals with time.

    Weather that is individual fade or delay times, off times, release times, cue times or something else, these should exist in some kind of a pool, work with filters and worlds, and be referenced for easy on the fly updating.

    So say you want to apply some sweeps to your color picker, you can apply these by simply selecting a time object, then store /m that into your presets.
    Or store merging it into the one the presets already reference.
    Or store /m it into the cues, or the time object that the seq or exec is referencing, or a cue or cue part?

    Does this make sense?
    To hard?
    Too complicated?
    Am I crazy?

    I have noticed that the captive displays of the Ma3 consoles are extremely susceptible to the build up of finger prints, and the materials used to construct the housing of the main screen panel are also magnets for natural skin secretions over time.

    Since my white gloves no longer work on the new captive displays, I am wondering if there exists a recommended or manufacturer approved method of maintaining clean screens and housing on consoles?

    I COULD use a generic micro-fiber cloth and some low boiling point bi polar solvent such as IPA, but I thought I’d check here first to make sure I don’t remove some proprietary screen coating or damage gaskets ect.


    Thanks guys. But that brings me back to the previous question again. Now that a seq is essentially its own handle, what is the point of having execs at all now?

    We may as well do the same thing with any object, and then scrap the executor all together. To be clear here, I have a an expert understanding of ma2 (bold statement I know) and I completly understand what you guys are saying already. I know that execs handle other/non seq object types. I think maybe I'm not asking my question clearly so I will try rephrase it.

    What was/is the intension or reasoning behind changing playback ownership from the primary vehicle built to handle playback objects in MA3 (The Executor) to the Seq (object) When the exec is still primary the vehicle of handling playbacks of all other non seq playback objects? What is so special about the seq now, or what was wrong previously that required this to be reviewed?

    Previously playback handles had one of the highest priorities within the system, only exceeded really by output and some other things for example. So changing playback ownership back to the object its self could kind of mess with insurance we used to have here. If you've ever experienced ma2 go into a loop, you'll recall that touch and most other functions (Fixture output calculations, any HID ect) become unresponsive, But mission critical stuff like canbus, networking and physical execs are still maintained to the highest degree possible to sustain output. Will a move to a more virtualised handling of seq object playback be better or safer? Or is this a sacrifice for less restrictive development conditions in the future? Or a change made for reasons i haven't or cant imagine?

    Forgive me for wasting anyone's time with this, I'm just very curious about changes to stuff like this, as these things will shape some of my discussion making processes while I try develop new workflows for my transition to from Ma2 to Ma3.

    Yea I know all about execs as playback handles, what I dont understand is when you say "seq owns playback in ma3". Normally its the exec that owns the playback of what ever object is assigned to it or a seq could own playback if it is called directly without being assigned to an exec.

    Eg if a seq is assigned to an exec, playback is owned by the exec when that exec is called. If that seq (not the exec its assinged to) is called via the command line, then the seq would own the playback?

    Tapping on the Label in the playback window acts as tapping on the label in the playback bar (i.e. opening the assign menu). Tapping on / otherwise interacting with the executor section (i.e. buttons / faders / knobs) will act on the button/fader/knob.

    This is all working as expected. "Page 1.201" = Page 1 Exec 201. In general in grandMA3, "<object> x.y" = <object> x <child_of_object> y, and executors are children of pages (in the tree structure). If you just say "Exec 201" without specifying the page, it will be Exec 201 on the current page.

    This contrasts with grandMA2 which had lots of inconsistency in the syntax "<object> x.y.z" for which of x, y, and z was the grandparent, parent, object, child, or grandchild object.

    Select + empty exec behavior is expected.

    Master 201 At 100 = illegal object is expected. "Master" is the parent object for all selected, grand, speed, and playback masters. "FaderMaster" is the keyword to set the master fader level of a sequence. In general, perhaps have a look at this thread.

    Hey Ryan, if playback is owned by the seq now and not the executor, what is the point of executors other than them just being a handle for a sequence? Is the idea to eventually scrap the "executor" handle and just refer directly to seq handles as playbacks or something?

    Thanks mate! Unfortunately this isn't what I was looking for. I was looking for a way to action an exec from the exec tool bar at the bottom of the onpc screens 2 and 3 with the mouse or a touch gesture, without needing to open the playback window. The master level indicator would be a perfect place to build this function into, as its intuitive to try and click there, and has more screen resolution than the the virtual fader in the playback window. Also syntax to control the level of an exec fader. Direct control in the main UI is needed for objects such as special masters, eg for the rate multiplier functions, so it makes sense to at least have a gesture build in or to give parts of the exec (not including its label) some form of direct user interaction control.

    You comment brings up a good point though in regards to what I was saying is an inconsistency with syntax in my situation. where its not possible to address an exec fader level using the exec keyword, but it is possible to address an exec fader using the the page keyword. Your example syntax shows that both can be used in some circumstances, but not others. which I think needs to be addressed at some point.

    Cheers for the response Ryan. I tried variations of fadermaster to set exec 201 to 0 and full and those didn't work either. The only way to make it work is to omit the working name of the object I am working with (the exec id) and refer to the object as a page part, which seems counter-intuitive to me, but its not all about what i think i guess.
    I am able to control the exec using the playback window, but am disappointed I cant just run an exec's fader up via the exec master level indicator with the mouse, or at least a click and swipe gesture or reset an temp exec with the mouse, from within the main letterbox/playback bar. That was a really handy feature that negated the need to call a new window or have a new view that I would only ever use for that purpose.

    I'm far from having a robust understanding of MA3 yet, but I still think something fishy is going on with execs though. an illegal or wrong syntax shouldn't create a new seq, assign it to an exec then move said exec to a random place in the second playback bar. especially when non of the syntax used referenced any exec id/number. IE when trying to effect a change on only exec 201, using only the numbers 201 in the command line and not using any action words like "move" or "copy" or "assign" or object handles like "sequence". Its strange to see a new random seq created, and it be assigned to say exec 150 by its self. or an exec or seq that isn't referred to at all being moved.
    For example if i click in a the empty seq 7 pool tile, i would not expect a new seq to automatically be created at seq 11 for example. Defiantly not just by clicking, and without having the store keyword or shorthand in the command line.

    Thankyou for your patience, and for explaining thins! Going to take a long time to get used to the new structure. "exec 2.201 at 0" was a far cry more logical and easier and to remember than "fadermaster page 2.201 at 0", But i understand their reasoning here. I just hate that I cant make "this" do "that", without omitting the real world name of the object. its like the statement "Something else do this" . kind messes with the whole point of nomenclature in an object ordinated system if that makes any sense? Maybe they can allow for both in the future as a compromise :)

    Hi, with MA2 we used to be able to flash or toggle an exec of change the level of an execs master via the mouse/touch screen/HID

    How do I do this now?
    Clicking anywhere on the exec 201 icon pulls up its edit context menu, regardless of left or right click or where those clicks are made or if the click is held/dragged, or if gestures are used like the spinning motion used to drive the rotation of virtual encoders. it seems to me that i am going crazy. OR like there is no way to physically handle basic controls of an exec using touch or any human interface, which I would think is counter intuitive to the heavy emphasis on UI gesture with the rest of the applications functionality. or maybe I'm doing something wrong?

    Also, if I try to edit exec 201 by typing edit exec 201, the edit context opens and exec 201 flashes red as expected, but if I right click exec 201, CLF says the the syntax executed is "edit page 1.201".
    I can then say "on 201" or "off 201" and this works.
    but If try "on exec 1.201" nothing happens, while "on page 1.201" this does toggle on exec 201.
    for a command (where i want to specify the page the exec is on) I have to use on page 1.201" even though the object that I am really meaning to refer to here is an executor. This is confusing and in my opinion should change no?

    Other oddities i have noticed are listed below: (not using keyboard shortcuts)

    store exec 201

    If I type "fader" into CL and touch exec 201, a new seq is created and assigned to exec 102. doing this again moves exec 102 to exec 103 and so on.
    If I type "fader at 100" into CL and touch exec 201, a new seq is created and assigned to exec 102. doing this again moves exec 102 to exec 103 and so on.
    if i type "fader 201 at 100" the command is valid and executed, but the listed level of exec 201's master remains at 50%.
    if i type "sel" and then click on an empty exec a new seq is made and assigned to the empy exec and is selected
    if i type "master 201 at 100" i get CLF "illegal object".
    if i type "exec 201 full" nothing happens.
    if i type "Fader 1.201 at 100" CLF is "can not create object"
    If i type "fader exec 201 at 100" a new seq is created and assigned to exec 102 and is selected
    If i type "page 1.120 at 100" the previously (unintentionally created seq occupying exec 102 moves to exec 120
    If i type "Page 1.201 full" the command is executed but nothing happens.