MTF & Repainting

Every multi-timeframe oscillator has a honesty problem to solve. When a slot runs on a higher timeframe than the chart, the slot's current value is either the confirmed value from the last closed higher-timeframe bar or the live, still-evolving value from the bar that is building right now. Those are not the same number. They are not even the same promise about the number. A tool that hides which of the two you are looking at is a tool that will hand you a confident reading on Tuesday and a different confident reading, retroactively, on Wednesday.

The Base trim solves the honesty problem with a single switch: On Bar Close?. This page walks what the switch does, what it costs, what it buys, and how to verify it with your own eyes in under five minutes.

The reason this page exists as its own URL, rather than a sub-section of Settings, is that the cost of misreading this switch is higher than the cost of misreading any other input on the indicator. A wrong source, a wrong baseline length, a wrong weight — each of those produces a pane that does a different job than you expected. A wrong On Bar Close? setting produces a pane that shows you one reading now and a different reading when you go back to review what happened. That is a different category of problem, and it deserves its own teaching.

The one switch you need to know

On Bar Close? lives in the PU Settings group. In the Base trim it is exactly one switch — not one per slot. Every enabled slot follows the same setting. That is deliberate; it keeps the honesty contract for the whole pane a single decision instead of three. If you want a per-slot repaint control, that is a CTX capability, not a Base one.

• On Bar Close? = true — every slot waits for its higher-timeframe bar to close before it reports a new value. Until that bar closes, the slot continues to display the last confirmed value. When the higher-timeframe bar closes, the slot updates, and the update holds until the next higher-timeframe close.

• On Bar Close? = false — every slot reads the live higher-timeframe bar on every chart tick. The slot value can move as the higher-timeframe bar evolves and settles when that bar finally closes. Between now and the higher-timeframe close, the displayed value can change in both directions. That is repainting, described plainly. It is not a bug. It is a tradeoff you are asking for.

Both behaviors are legitimate. Which one is right depends on why you are looking at the pane.

What each setting buys and costs you

ON buys honesty, costs reaction time

With the switch on, every bar you see on the slot line is a confirmed value. If the slot is reading 72 right now, it was reading 72 on the last higher-timeframe close, and it will continue to read 72 until the next higher-timeframe bar closes. Your post-session review will show what the slot actually said during the session, not an optimistic hindsight view.

The cost is proportional to the slot's timeframe. On a 1m chart with a slot set to 60m, the slot updates once per hour. Between updates, the fast line holds a flat segment that describes what the 60m reading was at the last hour close. That flat segment is not a malfunction. It is the honest state of a confirmed higher-timeframe read on a lower-timeframe chart.

OFF buys reaction time, costs stable history

With the switch off, every slot reads the live higher-timeframe bar on every chart tick, so the slot responds as soon as the higher-timeframe price moves. You see the higher-timeframe change on the 1m bar where it happened, not when the 60m bar closed.

The cost is that values can change. A 60m slot reading 78 now may be reading 74 in twenty minutes without any new bar being printed — the 60m bar just kept evolving. Alerts that fired based on confirmed state (see Alerts) are still confirmed on the chart bar where they fired, but the slot values you see now when reviewing that chart bar may be different from what they were when the alert decided to fire, if the higher-timeframe bar had not yet closed at that time.

The slot-timeframe rule

A slot's timeframe must be greater than or equal to the chart timeframe. The script enforces this at runtime. If you set a slot to a timeframe below the chart's, the script raises a named error — you will see something like MA 01 timeframe cannot be lower than the chart timeframe. on the chart, and the pane will stop drawing until you fix the configuration. This is a hard stop, not a silent fallback. The tool refuses to quietly invent data that does not exist on the chart's timeframe, and that refusal is the safe behavior.

A common shape of this error is dragging the indicator onto a chart with a larger timeframe than the slot was set for. A slot pinned to 5 will raise the error on a 15m chart, because 5m is below 15m. The fix is either to raise the slot's timeframe to meet or exceed the chart, or to blank the timeframe input so the slot inherits the chart timeframe.

The chart-timeframe guardrail case

The rule above means that when the chart sits above a configured slot's timeframe, the pane does not compress that slot upward. It stops and names the problem. Concretely, with the shipped defaults (slots at 5, 15, 60) on a 1H chart, slots 01 and 02 are below the chart timeframe, so the script raises the named runtime error instead of quietly turning them into 1H reads. Slot 03 is equal to the chart timeframe and is allowed, but the first invalid enabled slot still stops the script.

The pane is not broken in this state. It is telling the truth about a configuration that asked for data below the chart resolution. The pane cannot know whether you meant that or not. You do.

Two useful moves in this case:

• Move the chart to a lower timeframe so the defaults stack properly (1m or 5m for the shipped timeframes).

• Re-configure every enabled slot so it is at or above your current chart — for a 1H chart, slots at 60, 240, D are a comparable escalating stack.

This failure mode is one of the cleanest to diagnose because the script names it. See Troubleshooting for the symptom-to-cause framing.

A verification you can run in five minutes

This is the cheapest way to internalize what On Bar Close? is actually doing.

1. Set the chart to 1-minute on a liquid instrument.

2. Keep the default three-slot configuration. Confirm On Bar Close? = true.

3. Watch slot 03 (default 60m, drawn in blue). On each 1m bar, the line should hold a flat segment between 60m closes. The line updates only when the 60m bar closes.

4. Do the same with slot 02 (15m, aqua). You should see steps at each 15m close.

5. Flip On Bar Close? = false. Watch slot 03 and slot 02 again. Now they move on every 1m bar, because each is pulling the evolving higher-timeframe value on every tick.

6. Flip the switch back to ON. If you navigate back to the chart bar you were watching before, expect the ON and OFF versions to answer different timing questions. ON reads the previous closed higher-timeframe bar. OFF reads the live higher-timeframe bar and may later settle differently. Do not use this test to demand bar-for-bar historical equality between the two modes.

If the closed-bar values do not match, you are probably comparing across chart reloads with data that filled in differently, or your chart feed is still building history. The claim the tool makes is about its own behavior on a stable chart, not about how TradingView repaints after a reconnect.

The point of the verification is not to "prove the tool is right." It is to make the switch's behavior concrete enough in your own eyes that you stop trusting words about it and start trusting the shape of the lines. A user who has watched the switch flip once knows something that no amount of documentation can substitute for.

Alerts are separate from this switch

The alert evaluation gate and the repaint switch are different things and doing different jobs. See Alerts for the full picture, but the short version:

• Alerts evaluate on confirmed chart bars. barstate.isconfirmed gates every alert.

• On Bar Close? controls whether the slot value on that confirmed chart bar is being computed from the closed higher-timeframe bar (ON) or the live higher-timeframe bar (OFF).

If you leave the switch off, the fact that the alert fires on a confirmed chart bar does not rescue you from the slot value itself having been mid-evolution. The alert is still honest about when it fired; what it fired on may have moved since.

This matters most for the blend and alignment alerts. A blend or alignment state that was "bullish" under the live 60m read may not be "bullish" after the 60m bar closes. If that distinction would change what you do with the alert, leave the switch on.

Where to go next

• You want to understand the alert contract more carefully: Alerts.

• You want to understand how sensitivity, slot weights, and master smoothing interact with a repaint setup: Settings has the audit moves, and For the Geeks has the mental-model shape.

• The pane is doing something odd and you are not sure if it is the MTF rule kicking in: Troubleshooting.

• You are running a setup that depends on agreement across slots and timeframes: read Limitations & Trust Boundaries before you let the alignment alerts route anywhere important.