My Favorite Object: trigger

    The trigger object is a humble but profoundly useful Max object. It doesn't make amazing sounds or images, but it will keep you sane while you do.
    Let's say you have a working patch. You decide that its layout could be a little clearer, so you start moving things around - not changing any patch cords, just moving objects. Then, it doesn't work! This can happen because when an object's outlet goes to more than one destination object, the order of those messages is determined by the position of the destination objects. Layout matters.
    Look at the print object outputs in the Max window to see how moving the print objects changes the message order. That can really mess things up in a complex patch. To bring some law and order to this Wild West of a patch, just type “trigger bang bang bang” into a Max object box. Or, if you’re not feeling all King of the Cowboys, you just can abbreviate with “t b b b”.
    The patch now works, no matter how much you move things around. Sanity!
    The trigger object not only works with bang messages, but with all Max data types. Each argument (b, i, f, l, s) specifies a data type (bang, integer, float, list, symbol) and results in an outlet. Not only that, trigger converts messages from one message type to another. So, each type argument results in an outlet of that type and each incoming message produces a message of that type out of the corresponding outlet.
    Changing the type of a a message can be tricky, but there’s usually some logic to it. For starters, any message of any type will result in a bang coming out of a “b” outlet. And if you send the trigger object a float, any “i” outlets you have created will output the number with the floating part truncated (e.g., 3.14159 becomes 3). If you input a list that begins with a number, trigger will output the first number only, retyped if necessary, out of both the “i” and “f” outlets.
    Here’s a very common use for the trigger object’s order-forcing and type conversion:
    When calculating a result from two numbers, it is normally the case that only the left inlet (or hot inlet) will produce an output. If you want the calculation to happen for either input, you’ll need a trigger object. Use “t b f” to set the right inlet, then send a bang message to the left inlet.
    Unfortunately, there are some type conversions that aren’t as obvious. Sending a bang message results in a zero from the integer and float outlets. A symbol (a text string) emerges unmodified from the list outlet, as does a list out the symbol outlet. But an integer or float seems to produce no output at all from a symbol outlet.
    What's going on? Well, actually it outputs a message consisting of the null symbol “” - the most Zen of all Max messages. The null message clears the message box and it can trigger a button object, but it doesn’t do anything particularly useful.
    Important Hint: “t l” will pass anything unchanged! You can use it to group all kinds of messages together to help declutter your patch. And one more thing: you can use any number or unreserved word as a “constant” argument. The trigger object will output that number or symbol regardless of the incoming message.
    It’s not a bad idea to use a trigger object anytime an object has more than one patch cord coming from a single outlet. In fact, if your patch is complicated, adding a trigger object at the top can be a way to define the main components in an orderly way. If you change your mind later – if you need to add one more process at the end, for example – you can just type in the new argument. After that (noticing the updated outlet assistance), use option-drag (alt-drag on Windows) to select all the patch cords to the right, then drag them to the right so that the outlets line up again:
    We noted above that “t l” passes any message. That also goes for pointers such as those that refer to Jitter matrices (e.g. jit_matrix u464001211) and or GL textures (e.g. jit_gl_texture u471000910). Since these messages are just symbols, using the trigger object for openGL textures doesn't result in reading back from the GPU to the CPU, so you can use trigger objects freely to organize your texture processing.
    If, like me, you’re totally in love with the trigger object, and if, like me, you know a tiny bit of JavaScript, then you’re ready to explore the jstrigger object in Ben Bracken’s recent article. Trigger warning: it’s fun.

    • Mar 07 2017 | 7:23 pm
      great walkthrough – i love triggers, too (and also those gifs up there! (:)
      yet, what would make me an even happier person: if adding new arguments to a trigger reconnected the patch chords accordingly! :D (and not as shown in the last image). that'd be super rad!
    • Mar 08 2017 | 5:14 pm
      Totally agree with Benniy, btw I was working years without knowing that several cords can be moved at once :P
    • Mar 08 2017 | 5:45 pm
      Wonderful, I think trigger is basically the first thing I show to my students, after explaining the right-left-bottom-up rule. I always say : "You might forget it before the next course, but I'm telling you, if at some point your patch starts to malfunction, there might a trigger needed somewhere".
      By the way, about the “t l”, I never thought about it as a kind of "all pass" that would work for any pointers, thanks for the info ! This is obviously why bach's library lllls can go through those, that's another example.
    • Mar 08 2017 | 8:28 pm
      Concise, precise and easy to digest, thanks!
    • Mar 09 2017 | 5:23 am
      instead of using [t l] you can also use an empty [p foo] - it is cheaper :)