Forums > MaxMSP

[bang] resolution?

Jan 25 2011 | 3:22 pm

Sometimes I am programming controls (like filter cutoff) to go through a [bang] that sends the values rather than going directly to the filter input. The details aren’t too relevant. I am wondering if [bang] outputs at the same rate or resolution as just sending the [dial] directly to the object it’s controlling. I assume it’s OK, but seeing the [bang] light flicker intuitively makes me assume that the control is being segmented rather than a smooth control.

Jan 25 2011 | 4:18 pm

bangs are processed in the scheduler. Usually there is a rate down to 1 ms possible. If you use the UI object, this will eat unnecessarily much graphics power, as the flickering has to be drawn. An alternative is the trigger object or the bangbang [b].
Max tries to compute all bangs which occur within one scheduler interval, if its too much, your user interface gets sloppy, and can’t keep up. If that doesn’t happen, there is no need to worry…


Jan 26 2011 | 3:57 pm

This is easy enough to test yourself—something like the patch below.

Short answer: don’t get hung up about the blinkenlights. The flashing of button is cosmetic. Responding to bangs or other input is time-critical and done immediately. The cosmetic actions are handled whenever the Max engine (and the OS) feel there is time to do so. Cosmetic actions may get delayed or even dropped.

It is possible to build a patch that has so much processing going on that even the time-critical stuff gets delayed, but it needs to be a pretty monster patch before that happens.

-- Pasted Max Patch, click to expand. --

Jan 27 2011 | 1:16 pm

… which does not mean that [button] wouldnt use lots
more CPU compared to [t b].

when a bang button is not even able to show its graphics
in time (or at all), then it is time to repace it with [t b].


Jan 27 2011 | 10:29 pm

Or even better with [b 1]

Viewing 5 posts - 1 through 5 (of 5 total)

Forums > MaxMSP