[bang] resolution?

speedo's icon

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.

Tj Shredder's icon

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...

Stefan

Peter Castine's icon

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.

Max Patch
Copy patch and select New From Clipboard in Max.

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.

Roman Thilenius's icon

... 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].

-110

Tj Shredder's icon

Or even better with [b 1]