a short explanation on why your original patch is not working: the DSP chain (think about the objects connected with yellow cords) runs real-time. However, the right output of the [number~] object in your patch will monitor your signal and output its value each n-th millisecond (by default, one sample value per each 100 ms). Since you have a [ with parameters 2 and 200, these periods are simply too short to make it sure that the 1 sent out by them (when the counter is between 0 and 1 or 199, respectively) holds long enough to be catched by the 100 ms long monitoring interval of [number~] (if you're on 44.1 kHz, then 200 samples will last approx. 4.5 ms, so your chances of actually catching that 1 by the [number~] are quite small). To make it sure that you always catch the changes (at least, theoretically), you'll have to put at least 4410 as the parameter of [ (if you're on 44.1 kHz AND [number~] has a monitoring rate of 100 ms).
On the other hand, you'll need to consider that the messages in Max are processed on a lower priority thread, and generally speaking, it's not a good idea to flood the messaging threads with too many messages at the same time...
@dave m: the helpfile is very comprehensive and clear, take a look?! also, i think the example is the work of dsp guru christrippledot - take a look at the link in the file i posted.
the problem with the other solutions in this thread is that they are not sample accurate and thus very wonky. the solution i posted is particularly accurate since max6, because of the 64-bit signal chain accuracy ([+=~] now accurate).
this is even better written in gen~ or GenExpr, and much more versatile in that environment. almost all dsp counting tasks i have these days are pieced together in gen~.