MTF and Repainting
The global `On Bar Close?` switch is the first thing this page teaches, and it is the first thing a reader should understand before running the tool in a live session. There is one switch for every slot in this trim....
Written By Axiom Admin
Last updated 22 days ago
MTF and Repainting
The global On Bar Close? switch is the first thing this page teaches, and it is the first thing a reader should understand before running the tool in a live session. There is one switch for every slot in this trim. Flipping it changes what every enabled slot reports on every chart bar, and the two modes are honest about different things. Neither mode is "the right one." Each is the right one for a reader who has chosen it deliberately.
The one switch, both modes
On Bar Close? is a boolean input in the PU Settings group. It defaults to true. It applies globally across all three slots. Per-slot repaint control does not exist on this trim; if you need it, CTX is where it lives.
On β the confirmed mode
With the switch on, every slot's higher-timeframe request returns the values from the previous confirmed higher-timeframe bar. That means:
A slot at 60m on a 1m chart updates only when the 60m bar closes. Between closes, the slot's RSI and signal hold their values for up to 60 chart bars at a time.
The value the slot reports is previous-slot-bar accurate, not now accurate. The latency is one slot-timeframe bar relative to what the live higher-timeframe math would show.
The slot does not revise within a live higher-timeframe bar. The line is stable across chart bars until the next higher-timeframe bar closes.
This is the non-repainting configuration, with the qualifier that it is non-repainting because the switch is on. The same tool with the switch off repaints within a live higher-timeframe bar. The word "non-repainting" is only accurate about this instrument when the switch is on, which is why this page uses the qualifier consistently.
Off β the live mode
With the switch off, every slot's higher-timeframe request returns the values from the live higher-timeframe bar. That means:
A slot at 60m on a 1m chart updates on every chart bar as the 60m bar evolves. The slot's RSI and signal move inside each 60m bar as the underlying price develops.
The value the slot reports is now accurate β it reflects where the slot's RSI and signal would be if the higher-timeframe bar closed right now.
The slot revises. Between the opening of a higher-timeframe bar and its close, the slot's values can change multiple times as the bar's OHLC develops.
This is the repaint-exposed configuration. "Repaint" here means the specific behavior of a value revising within a live higher-timeframe bar. Because the script uses lookahead_on, OFF-mode historical bars can also show the completed higher-timeframe bar earlier than a live trader would have known it. That makes OFF useful as a live posture choice, not as historical proof. Closed higher-timeframe bars do not keep changing once they are closed; the danger is reading OFF-mode history as if it were confirmed live evidence.
What the switch is not
The switch is not a fix. Neither mode removes within-bar motion from the market β the market moves, and the question is whether you want the slot to reflect that motion as it happens or to hold the last confirmed reading until the higher-timeframe bar closes. Calling the on-mode a "fix" and the off-mode a "problem" would be both wrong and unhelpful. Both modes are truthful about what they report as long as the reader knows which mode they are in.
The switch is also not a solution to latency. It is the latency tradeoff. The on-mode has latency by construction; the off-mode has revision by construction. Pick the one whose tradeoff you can live with on the session you are in. If you find yourself flipping the switch mid-session to chase whichever mode looks better given the last ten bars, you are letting recent bars decide your mode for you. Pick the mode that matches the read you are committing to, and then stop touching the switch until the session is done.
The slot-timeframe rule
A slot's timeframe must be greater than or equal to the chart's timeframe. The tool checks this explicitly on every run. If the slot timeframe sits below the chart timeframe, the tool raises a runtime error that names the slot β the error string will be shaped like RSI 01 timeframe cannot be lower than the chart timeframe. with the slot label matching whichever slot is misconfigured.
A slot equal to the chart timeframe is allowed. A slot blank also inherits the chart timeframe. Both are legitimate configurations, with the consequence that the slot no longer adds cross-timeframe evidence; see the same-timeframe collapse case below.
Worked verification on a 1m chart
Drop the indicator on a 1-minute chart of a liquid instrument, accept all defaults, and run this sequence:
With
On Bar Close? = true, watch slot 03 (the 60m slot) for a few chart bars. Its line should sit flat β the same RSI value and hidden signal state β across chart bars while it is carrying the previous confirmed 60m value. Around the next 60m boundary, that just-closed 60m bar becomes the previous confirmed value the slot can carry next.
Flip
On Bar Close?to false. Now watch slot 03 again. The slot's plotted RSI and color can begin drifting on every chart bar. The drift is the slot recomputing against the live 60m bar β as the live 60m bar's price path changes, the 60m RSI changes, the slot's smoothed RSI changes, and the hidden signal relationship can change too.
Wait for the next 60m bar to close in the live-mode run. The live slot settles when the 60m bar closes. The ON-mode copy does not use that just-closed value until it becomes the previous confirmed 60m bar on the next higher-timeframe segment, so compare the two modes around the boundary rather than pretending they are identical on every chart bar.
Flip back to
On Bar Close? = true. Slot 03 goes back to holding between 60m closes.
Do this once on the defaults and you will feel the tradeoff directly. The on-mode gives you a stable slot that updates in discrete steps; the off-mode gives you a continuously revising slot that settles at each higher-timeframe close. Both are correct. You are choosing what you want the slot to be showing you while the higher-timeframe bar is still open.
A second exercise for readers who want the tradeoff in their hands, not just on the page: run the same symbol with two copies of the indicator side by side. Copy A with On Bar Close? = true, copy B with On Bar Close? = false. Watch one live 60m bar from open to close on both copies. Copy B will show you where the slot "thought it was going" at each point during the bar; copy A will sit still until the confirmed value becomes available to its previous-bar logic. The divergence between them during the bar is the repaint surface; the handoff around the close is the confirmation. This exercise is the fastest way to stop treating the switch as a quality knob and start treating it as a posture choice.
Chart-bar vs slot-bar β the asymmetry that matters for alerts
The alert conditions on this tool are gated on barstate.isconfirmed. That gate fires on every confirmed chart bar, not on every slot-timeframe bar. On a 1m chart with a 60m slot, that gate fires every minute. If the slot is in a given state β say, RSI 03 Is Bullish β the alert can fire on every confirmed 1m chart bar where the state holds. A slot can carry the same state across many chart bars, and the alert will re-fire on each of those chart bars.
Consequence: an alert that fires "every minute for forty minutes" is not a bug. It is the alert's state-based wiring meeting the chart-bar cadence. The tool does not ship edge-triggered alerts β there is no "RSI 03 Just Turned Bullish" condition. Alerts covers this in full; the asymmetry is named here because it intersects the repaint behavior directly.
A subtle consequence in the live mode: when On Bar Close? = false, the slot's state can flip inside a live higher-timeframe bar, which means the slot's bullish/bearish state on any given chart bar reflects the live higher-timeframe bar's evolution. An alert firing on a live-mode run carries the caveat that the underlying slot value may still revise before the higher-timeframe bar closes. In the on-mode, the slot's state is locked between higher-timeframe closes, and the alert firing across chart bars is simply re-firing on the same locked state.
Same-timeframe collapse
Every slot's timeframe must be at or above the chart's timeframe. The tool does not force lower configured slots upward. If a slot timeframe is below the chart timeframe, it raises a runtime error. Same-timeframe collapse is a different case: it happens when you intentionally set slots equal to the chart timeframe, or leave them blank so they inherit the chart. In that setup, the slot still computes, but it no longer contributes higher-timeframe evidence.
The tool is behaving correctly. The configuration may have lost the purpose you expected from it. The fix is the reader's, not the tool's: either move the chart to a lower timeframe so the configured slot timeframes can sit above it, or reconfigure the slots to timeframes above the new chart.
This is a named case, not an edge case. It happens most often when a reader switches a chart's timeframe for a separate reason, then clears or equalizes slot timeframes while trying to recover from an error. If the pane suddenly looks uniform across the three slots and the blend is tracking the chart's local RSI, check whether the slots have been set to the chart timeframe or to the same timeframe as each other.
Session handling
The indicator does not gate on session state. It computes on every bar the chart provides, including extended-hours bars when the chart is set that way. A slot on a higher timeframe that spans regular and extended hours will inherit the chart's session setting β a 60m slot on a regular-hours-only chart will compute from regular-hours data; the same slot on an extended-hours chart will compute from extended-hours data. If you care about the session edges on the chart's symbol, configure the chart's session display and the slot will follow.
When a slot goes na
A slot returns na during warm-up until the raw RSI has enough higher-timeframe bars to exist. After that, the code falls back from unavailable MA outputs to earlier pipeline values: the slot RSI can use raw RSI before its smoothing MA is ready, and the slot signal can equal the slot RSI before the signal MA is ready. The plotted line can therefore appear before the full smoothing cascade is mature, but it is not the steady-state output yet.
Warm-up is expected. A reader loading the indicator fresh on a 1m chart and reading the first visible bars as "the indicator's read" may be reading fallback behavior. The default 60m slot needs the RSI lookback plus smoothing history in 60m bars, not just a few chart minutes. If your chart history is short enough to keep a slot perpetually warming up β for example, a newly listed symbol or a session setting that does not provide enough 60m bars β consider that a diagnostic about the chart, not the tool. TradingView only loads so many historical bars per chart; zooming out or changing the chart's timeframe can pull in more. If the slot still cannot fully warm up, the symbol does not have the history the configured slot length demands, and that is a scope mismatch between what you asked the slot to do and what the market has given you.
Where to go next
The knob that controls the switch and the slot timeframe inputs β Settings.
What the ten alerts fire on and what they do not β Alerts.
The same-timeframe collapse case in the context of other trust boundaries β Limitations and Trust Boundaries.
When a runtime error appears β Troubleshooting.