[bang] resolution?

Jan 25, 2011 at 3:22pm

[bang] resolution?

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.

#54588
Jan 25, 2011 at 4:18pm

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

#196602
Jan 26, 2011 at 3:57pm

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. –
#196603
Jan 27, 2011 at 1:16pm

… 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

#196604
Jan 27, 2011 at 10:29pm

Or even better with [b 1]

#196605

You must be logged in to reply to this topic.