All that's left now is to get the Reorder nodes to take the right channels based on the suppress parameter's setting. We could set up a handful of Select nodes to feed the various luminance images into the right places, but with all the power of the macro language we should be able to find a programmatic way to just set the existing Reorder nodes to put the proper channels into luminance images. Two things will help us here. First, we can use conditional statements like if and else within the macro. Second is the fact that we can concatenate text strings with a simple +. For example, in Shake's scripting language "about" + "   " + "face" equals "about   face".

So let's determine the alternate channels like this:

  curve string alt_a;
  curve string alt_b;

  if (suppress == "r") {
    alt_a = "g";
    alt_b = "b";
  }
  else if (suppress == "g") {
    alt_a = "r";
    alt_b = "b";
  }
  else {
    alt_a = "r";
    alt_b = "g";
  }

Note the "curve" statement preceding the string declarations. As of the time this tutorial was written this is absolutely essential for this macro to behave as expected in the GUI. You see, while it's often assumed that Shake macro code is executed to generate an output image, this is not the case. The macro code is executed when the macro is instantiated, either by loading a script that contains it or creating the node in the GUI. Executing the macro creates the nodes in the tree which will themselves eventually be executed to generate an image. Now, with that in mind, consider what happens if a variable's value changes during the life of the node, for example by the user changing the value of "suppress". The macro tree has already been built and the variables resolved. Nothing would change! The "curve" statement is the solution to this. When it's encountered, Shake knows that this variable's value could change after the tree is built and any of the macro code that uses it will need to get rebuilt in that case. You can often get away without using "curve" by setting the variable to an expression that contains an input parameter when it's created. Shake will notice this dependency of the new variable on the input parameter. Since the input parameters are assumed to be changeable ("curve" type variables) over the life of the node, the new variable is then marked as something that needs to be recalculated if the parameter changes. And likewise, anything that uses it will get rebuilt or recalculated if it changes. However, the declaration of a variable is your first and last chance to make sure Shake knows how to treat it, so if it's not marked "curve" and not set to an expression containing another "curve"-type variable (like an input parameter) then it will get resolved to its current value where it's referenced. It's possible that future versions of Shake will be better able to guess when this is necessary, but it certainly won't hurt to err on the side of caution and overuse "curve" rather than underuse it.

To make things even cleaner and take advantage of the fact that Shake knows suppress is a "curve" type variable already,, we could use the conditional statement form introduced at the beginning of this article to rewrite the alt_a, alt_b assignment as:

  string alt_a = (suppress == "r") ? "g" : ( (suppress == "g") ? "r" : "r" );
  string alt_b = (suppress == "r") ? "b" : ( (suppress == "g") ? "b" : "g");

And with the + string concatenation, we can set our Reorders to something like "alt_a + alt_a + alt_a" to get "rrr", or "ggg", for example.