===Macros===

If you've spend any time with this documentation, you should have a sense of how most things can be achieved by shuttling commands back and forth between Wintermute and Qlab. So far so good! **Macros** may seem fiddly, but once you've got the hang of them, they will make many tasks easier - think of them as mini cue lists that run within Wintermute.

Here's the basics:

  * Macros are lists of Wintermute commands and [[concepts:macros:parser directives]] 
  * Each command or directive can have an associated delay time in milliseconds
  * For commands with the same delay time, they are executed in the order they are added
  * Each macro has a trigger and a name - it is referred to by the trigger if the name is blank.
  * Macros are associated with a Node((which doesn't actually have to exist - you can create a fake //network// node to hold macros that are only ever triggered from within Wintermute using [[commands:macro_node_commands:node_macrorun]]))
  * There are three types:
    * [[commands:macro_node_commands:start|Network Node Macros]] that are run when receiving the relavant trigger from a networked [[concepts:nodes|node]]
    * [[commands:midi_commands:start|Midi In Macros]] that are run from a corresponding [[concepts:macros:midi_trigger]]. These macros must have a name as you can't refer directly to the trigger.
    * [[commands:streamdeck_commands:start|Streamdeck Macros]] that are triggered by a key up or key down from an attached Streamdeck
  * The only limit on execution and length is an overrun counter - if you try and run more than 128 commands from a single macro without a delay, the parser will assume that you've accidently created an infinte loop and halt the macro - this will be flagged in the system log.
  * Each macro has it's own private set of [[concepts:macros:macro_variables|variables]] that allow you to pass parameters to the macro - this is particularly important when deploying the same macro to multiple nodes.