This tutorial will examine different techniques for creating and viewing streams of numeric data in the Max environment. We will look at the multislider object, which has modes for both creating and monitoring data values. We will also look at monitor Watchpoints, a debugging tool that you can use to view the messages running through patch cords as they are being generated.

When working with a modular system like Max, it is sometimes difficult to keep track of all of the messages that are being sent between objects. Using the available tools for monitoring messages and values can help you fine tune a patch, or to track down problems in a patch’s operation. The two tools we will use – multislider objects and watchpoints – provide two different mechanisms for tracking data: multislider is a good option for runtime (performance) monitoring, while watchpoints a valuable during programming and debugging.

Open the tutorial.

Take a look at our tutorial. This patch contains a lot of objects that display and generate different types of graphs - in fact, they are all versions of the same object, a multislider. We will start with the patch labeled 1, which contains is a sequencer that will step through the various sliders of the multislider, and produce a note for each step using MIDI. The output of the multislider is between 0 and 127 (the standard MIDI note range), and provides 16 steps of sequenced data. If you turn on the metro with the toggle, you will see the step number being generated by the counter object, prepended with the fetch message, and used to query the sixteen sliders in the multislider. This is the basis for most step-sequencing patches, with either auto-generated contents (which is what the uzi-and-drunk-based section of the patch does), or by directly manipulating the individual sliders in the object.

The right output of the multislider is used for this application. When used as a bank of sliders (meaning that the Slider Style attribute is set to either Thin Line or Bar), the left outlet will send all of the slider values as a single list, and only when a bang message or complete new dataset is received. The fetch message sends the value of an individual slider (numbered starting at 1) out the right outlet.

Take a look at the multislider object's Inspector and note the different settings. Our object has a set of colors selected and 4 levels of alternating "candycane" colors selected. If you close the inspector and draw in the multislider, you can change the melody that plays in the sequence. Clicking the button object connected to the uzi will generate a new drunken melody.

Now look at the patcher area labeled 2, which is a monitoring patch for our mouse. Start the metro at the top of the patch with the toggle, then move your mouse around the screen. You will see that the two drawing areas on the top track the current X and Y mouse locations (output by our WTHITM abstraction), while the larger graph area at the bottom displays a four-line running display, scaled and modified by the logic above it.

In previous tutorials, we’ve used the lcd object for drawing our tracking information in creative ways. However, in this case, we are using the multislider object instead. The most common use for multislider is as a bank of sliders, but it has a few modes that are useful for displaying information from a stream of data. These modes are listed as options for the Slider Style attribute (in the inspector); they are the Scroll options, which accept incoming values, append them to the end of the displayed data, then scroll the display to make them visible. It provides a simple interface to something that is similar to the scrolling graphical displays that are commonly seen on electronic test equipment.

The two smaller multislider objects at the top of the patch display the data coming from our WTHITM abstraction (which we used in earlier tutorials) – turning our scaled mouse movements into numbers ranging from 0.0 to 1.0. This value goes into the multislider (to be displayed), then is output from the multislider into a bit of patching that produces four values from that data (the X position, the Y position, and a pair of polar coordinates for the distance and angle of the mouse from the center of the screen). This is sent into the lower multislider, which is both graphically jarring (red on green!) and peculiar in it’s display: it displays four data streams simultaneously.

Attempting to do something like this in an lcd object would be very difficult, but to accomplish a multiline display in a multislider is a simple matter of saying that there are four sliders, setting the display range (in this case, from -1.0 to 1.0), and letting the object work its magic. In this case, the X and Y coordinates of the mouse are used to create four different data streams, each displayed in its own section of the graphic.

While the multislider is useful for displaying numeric data streams, Max has a number of built-in systems for monitoring data as well. If you already have a screen full of objects and patch cords, you probably wouldn’t want to use the onscreen real estate for a large graphic display like a multislider. And if the data is being generated too quickly, or from too many locations, you may not want to print things to the Max window either. What is a better option? Watchpoints!

A Watchpoint is an attachment that you make to a patch cord that allows you to view the messages it carries without having to change your patch. If you click on a patch cord and bring up the contextual menu, there are two Watchpoint options: “Add Watchpoint – Monitor” and “Add Watchpoint – Break”. The first option sets a watchpoint that allows you to monitor the message values, while the second will force the patch to stop running when ever a message is seen on the selected patch cord - we used this in a previous tutorial to look at message order. Let’s watch some values run through the patch cords.

You can manage and view the watchpoints by selecting Watchpoints from the Debug menu. This brings up a window with one row for each watchpoint (identified by the colored and numbered circles on the patch cords). If you start the metro object in one of the patch sections using the toggle objects, you will begin generating messages – and you will see the results in the Watchpoints window. Both the window and the columns are resizable, so if you need to see more data than is visible, you can make the window larger or the columns wider. You will probably need to increase the size of the Value column to see all of the values for watchpoint 3 – you can widen it by selecting the header separator between the Value and Count columns and moving it to the right.

The columns in the Watchpoints window are mostly self-explanatory:
- The first column shows the watchpoint identifier.
- The second column displays the type of action assigned to the watchpoint.
- The third column displays the class of the object sending the message.
- The fourth column shows the name of the subpatcher containing the watchpoint (or is blank if it is on the main patch).
- The fifth column displays the value or values associated with the last received message.
- The sixth column displays the counter of messages received by this watchpoint.
- The seventh (and final) column shows a history of the last three values seen at this watchpoint.

If you start patcher section 1 and move your mouse around with the Watchpoints window visible, you will see the first three watchpoints tracking your mouse movement. The format of the window (and the location of the watchpoints) helps you quickly see that the X and Y coordinates, viewed with watchpoints 1 and 2, are properly scaled floating-point numbers from 0.0 to 1.0. You can also see the effect of the cartopol object and “divide by pi” (/ 3.1415) math objects on the X/Y coordinates by viewing the third and fourth value in watchpoint 3 (driven by the pack object). Watchpoints can provide a quick and easy way to verify that the results of your calculations match the ranges that you expect.

As we saw in an earlier tutorial, changing a watchpoint to either “break” or “break/watch” will have a special effect when Debugging is enabled: any message seen by the watchpoint will cause the program to pause, and allow you to step through the patch in debug mode. Once the patch is paused, the Debug Window is displayed and you can step through the patch one message at a time, watching the patch operating while the Debug Window displays your patcher's stack trace.

While only revealing one new object (multislider), this tutorial introduced a number of important techniques for both creating and tracking values in a data stream. We saw how multislider has built-in data display options that can greatly simplify the tracking of live numeric data. For debugging purposes, we also saw how watchpoints can be used to track any message on any patch cord without changing our programming.