MTF and Repainting

Read this page before you trust STR on any multi-timeframe chart. "Multi-timeframe" covers several distinct behaviors, and three of them carry a cost the reader is expected to understand before acting on the pane: the...

Written By Axiom Admin

Last updated 22 days ago

MTF and Repainting

Read this page before you trust STR on any multi-timeframe chart. "Multi-timeframe" covers several distinct behaviors, and three of them carry a cost the reader is expected to understand before acting on the pane: the repaint posture controlled by On Bar Close?, the confirmation semantics that govern divergence detection, and the history requirement that gates BBWP. None of these are defects. Each one is a tradeoff the indicator exposes as a visible control rather than hides behind a default, which is what lets you decide what to pay in exchange for what you want.

The core posture STR takes on multi-timeframe behavior is this: the indicator will not silently rewrite what it already painted, and it will not silently substitute a lower timeframe for a higher one, and it will not rank a percentile against a population that does not exist. If any of those three protections costs you something β€” lag, a refused configuration, or an empty series until history builds β€” the page below names the cost precisely, so that whatever you give up is a choice you can articulate rather than a surprise you discover later.


What "repaint" means on this indicator

"Repaint" is a word that gets used loosely. Here it has a narrow, specific meaning: an indicator value for a past bar can change after that bar has closed, because the indicator was drawing from data that has since evolved.

On STR, the place this can happen is inside each slot's higher-timeframe request. When a slot runs on a timeframe higher than the chart, the indicator has two options for how to read the higher-timeframe bar:

  • Wait until the higher-timeframe bar closes and use the completed value.

  • Use the live higher-timeframe bar value right now, knowing it can change until that bar closes.

Both are legitimate options. They buy different things. STR exposes the choice as a per-slot toggle β€” On Bar Close? β€” and the default is true, the safer side. The point of this page is to make the cost of each side as clear as possible so you can choose deliberately.


The On Bar Close? switch in detail

Every slot has an On Bar Close? toggle inside its per-slot Power User group. This toggle is the repaint switch.

With On Bar Close? on (default)

The slot returns the prior confirmed higher-timeframe value.

  • What you get. Stable history. A bar that has been painted stays painted β€” its value does not silently shift after the fact. The chart you look at tomorrow is the chart you looked at today.

  • What you pay. Lag. The slot's current value is one higher-timeframe bar behind the live move. On a 60-minute slot applied to a 5-minute chart, you are watching the previous completed hour's read, not the in-progress hour. You find out where the oscillator stands one hour after the market does.

  • Why this is the default. Because the read stays honest. An indicator that can silently rewrite its past is hard to study, hard to backtest, and hard to trust at the moment when trust matters. The default trade is: you pay lag; you keep honesty.

With On Bar Close? off

The slot uses the live higher-timeframe bar value.

  • What you get. Responsiveness. The slot's current value updates in near real time as the live higher-timeframe bar develops.

  • What you pay. Repaint. Until the higher-timeframe bar closes, its value can move. That means the slot's current read can shift during the bar, and a bar that looked bullish ten minutes into an hour can look bearish forty minutes in. Worse, if you were to look at what that bar reported at a given moment in the past, you might not see the same value you saw live.

  • When this is a reasonable choice. When you are actively watching the pane in real time, are prepared to reassess if the higher-timeframe bar develops against your read, and are not relying on the historical stability of the slot's past values.

Which side to choose

The honest default is true on every slot. Leave it there until you can articulate a specific reason to flip it, and confine any flipping to the slots where real-time responsiveness actually helps you. Do not flip the switch on every slot "for speed." The gain on your fastest slot is marginal; the loss on your slowest slot is large.

Two traps worth naming:

  • Flipping the switch on a single chart, forgetting you did. If a particular chart session behaves noisier than you remember, check every slot's On Bar Close? before blaming the market.

  • Flipping the switch to stop feeling "late." The lateness is the price of honesty. If the lateness is the problem, the question is whether a higher-timeframe slot is the right slot at all, not whether to flip the switch.


The slot-timeframe rule

STR enforces a rule: each slot's Timeframe: must be greater than or equal to the chart timeframe. If a slot violates this rule, the indicator stops with a runtime error that names the offending slot.

This is deliberate. There is no honest way to serve a lower-timeframe request from a higher-timeframe chart context β€” you cannot conjure 1-minute bars while running on a 5-minute chart. Asking for one is the kind of configuration error that should fail loudly, not silently fall back to the chart timeframe with an undisclosed substitution.

Consequences:

  • The rule is not a warning and cannot be suppressed. The indicator will refuse to run.

  • The rule checks per slot. If three slots are legal and one is not, the indicator still refuses.

  • The error message names which slot. Fix that one. If you suspect more than one was wrong, check each.

The lowest timeframe the blend can reach is the chart timeframe. Every slot set to chart timeframe reads the chart directly. That is a legal configuration β€” it just means you are running STR as a single-timeframe read with whatever per-slot settings you have applied.


Divergence confirmation in plain language

Divergence detection starts from chart-price pivots. The script confirms a price pivot with ta.pivotlow or ta.pivothigh using Pivot Len: as symmetric left and right strength, then reads the blended fast at that same pivot offset. It does not separately confirm an oscillator pivot.

Consequences worth holding in your head:

A pivot takes time to confirm

With Pivot Len: at the default 20, a price pivot low (or high) at bar N cannot be confirmed until bar N + 20. During those 20 bars, the pivot is a candidate, not a confirmed pivot. The indicator will not evaluate divergence against a candidate.

This is the reason divergence triangles never appear on developing bars. They cannot. The information that would let them appear does not exist yet.

The triangle has two possible positions

Once a pivot is confirmed on bar N + 20, the triangle is drawn somewhere. Which bar depends on Plot On Pivot?:

  • Plot On Pivot? off (default). The triangle is drawn on bar N + 20 β€” the confirmation bar. This is the most honest placement because that is when the divergence actually became knowable.

  • Plot On Pivot? on. The triangle is drawn on bar N β€” the pivot bar itself β€” by back-offsetting the plot by Pivot Len: bars. The information is the same; only the drawing has moved.

Both positions show the same divergence. Neither tells you anything more than the other.

"Early" is a visual illusion with back-offset plotting

A back-offset triangle on bar N, viewed on a chart, looks like the indicator saw the divergence at the pivot. It did not. The indicator could not see the divergence until bar N + 20. The triangle is drawn on bar N for visual convenience. Treating the back-offset triangle as if you could have acted on it at bar N is a historical illusion β€” you were not, in fact, in possession of that information at bar N.

The alert and the triangle are not on the same bar

With Plot On Pivot? on, the alert still fires at bar N + 20. Only the drawing moved. A reader building a workflow against the alert plus the visual has to keep these two times straight. The alert bar is where the information became real.


BBWP history requirements

BBWP on the blended fast line is a percentile rank. Percentile ranks require a population to rank against. STR's default Lookback: is 252 bars, meaning the rank compares the current width to its past 252 valid widths. Until 252 valid widths exist on a given chart, BBWP cannot be computed and the columns do not paint.

Consequences:

  • A short chart shows no columns. This is not a defect. It is the indicator refusing to report a percentile rank over a population that does not yet exist.

  • Replay sessions take time to produce BBWP. If you are stepping through a replay from an early bar, BBWP columns will remain absent for 252 bars.

  • Reducing Lookback: trades stability for availability. A shorter lookback produces columns sooner but ranks against a smaller and noisier population. If you choose this trade, know you chose it.

  • Gaps and regime shifts matter. When the underlying regime shifts β€” quiet to violent, or the reverse β€” BBWP is ranking a new regime against old widths for a while. The rank during that transition is technically correct but characteristically unstable, because it is spanning two different worlds.


What repaint costs you on a decision

A worked example makes the cost concrete. Suppose you are running STR on a 5-minute chart with MA 03 at 60m and On Bar Close? off for that slot. The 60-minute bar opens at 10:00 and closes at 11:00.

At 10:15, the 60m bar has been building for fifteen minutes. The live 60m value flows into MA 03, which flows into the blended fast. If the 60m bar has been leaning up, the slot's contribution is bullish and the blend leans that way.

At 10:45, the 60m bar has rolled over inside the hour. The live 60m value flows into MA 03 again β€” but now it is a different value. The slot's contribution is bearish. The blended fast that you saw leaning up at 10:15 is now leaning down. If you looked at the chart at 10:15 and said "alignment is bullish," you would not be wrong about what you saw at 10:15. But the bar you acted on has now repainted.

At 11:00, the 60m bar closes. Whatever it closed at is the value that, with On Bar Close? on, would have populated the slot on the next 60m bar. With On Bar Close? off, your historical 60m slot values between 10:00 and 11:00 are no longer what you saw live β€” they are now interpolations of the in-progress bar at the moment each 5m bar happened to render. Your history has been silently rewritten.

That rewriting is the cost. It is not catastrophic if you are a live reader aware of the tradeoff. It is catastrophic if you are running a backtest, studying past behavior to learn the instrument, or trying to tune settings based on how the pane used to look. The past you are examining is not the past that happened.

With On Bar Close? on, the 60m bar that closed at 11:00 populates MA 03 starting at 11:05 (the first 5m bar after the higher-timeframe close). Historical values do not move. You pay one higher-timeframe bar of lag; you keep a past you can study.


How to see the repaint cost yourself

This is a verification move you can run on any chart where you are considering flipping On Bar Close? off.

  1. On a chart where On Bar Close? is on across all slots, take note of the blended fast value during a specific five-minute bar inside a live higher-timeframe bar. Write it down.

  2. Flip On Bar Close? off on one slot that uses a higher timeframe (say MA 03 at 60m).

  3. Watch the blended fast value as the higher-timeframe bar develops. Note how it changes bar to bar within the hour.

  4. Wait for the higher-timeframe bar to close.

  5. Scroll back and re-read the blended fast value for the same five-minute bar from step 1. With On Bar Close? off, the historical value no longer matches what you wrote down. With On Bar Close? on, it matches exactly.

That mismatch β€” visible with your own eyes β€” is what repaint is. Seeing it yourself once is worth more than any number of pages describing it.


A note on alert behavior across the switch

Alerts fire on confirmed bars. That does not change whether On Bar Close? is on or off. But the definition of "the condition was true on the confirmed bar" is different on the two sides:

  • With On Bar Close? on, the slot's value on the confirmed bar is the prior closed higher-timeframe value. The alert fires against that stable value.

  • With On Bar Close? off, the slot's value on the confirmed bar is whatever the live higher-timeframe bar was at the moment the chart bar closed. That value can be different from what the higher-timeframe bar closes at later.

The consequence: an alert that fired under On Bar Close? off was true at the moment it fired, but the underlying slot value may subsequently shift. This is consistent with the repaint tradeoff but worth saying out loud if you are wiring alerts into an automated pipeline.


What this page does not cover

Three topics are mentioned here only so you know where to find them in detail:

  • The specific alert behavior and its confirmed-bar gate. See Alerts.

  • Sensitivity saturation and its interaction with smoothing. See Settings.

  • Symptom-first diagnosis when a chart feels wrong. See Troubleshooting.

The multi-timeframe posture, the repaint switch, and the confirmation semantics are the load-bearing content of this page. If you leave understanding those three well, you have the piece you came for. If any of them still feels abstract, run the repaint verification above on your own chart; the ten minutes it takes to see the mismatch with your own eyes is worth more than any number of paragraphs describing it.