MTF and Repainting

MTF and Repainting

This page explains how the indicator handles multi-timeframe data, what the On Bar Close toggle does, why it matters, and how to verify the behavior yourself. If you have ever been burned by a multi-timeframe indicator that looked great in history and fell apart in real time, this page is the one that explains why that happens and how this tool addresses it.

Why multi-timeframe indicators repaint

When an indicator on a 1-minute chart requests data from a higher timeframe — say, 5 minutes — it has a problem: the current 5-minute bar is not finished yet. The MACD, ATR, and all the other calculations for that 5-minute bar are in progress. They will not be final until the 5-minute bar closes.

There are two ways to handle this:

1. Use the building bar's values. The indicator takes whatever the 5-minute bar looks like right now and uses it. This is faster — you see values that reflect the most current higher-timeframe data. But those values are provisional. As the 5-minute bar continues to build, the values change. When the 5-minute bar finally closes, the final values may be very different from what the indicator was showing halfway through. The historical chart does not show this instability because by the time you scroll back, the 5-minute bar has already closed and the values are final.

1. Use the last confirmed bar's values. The indicator ignores the building 5-minute bar entirely and uses the values from the most recent fully closed 5-minute bar. This introduces lag — you are always one HTF bar behind — but what you see does not change. Once a value is plotted, it stays.

The first approach is what causes repainting. The indicator is technically showing correct data for the current moment, but "the current moment" keeps changing until the bar closes. A trader looking at the historical chart sees only the final values and never sees the instability that was present in real time. This is how you end up with an indicator that shows a perfect crossover on a historical bar that, in real time, crossed and uncrossed three times before settling. The chart remembers the final state. You would have experienced the uncertainty.

How this indicator handles it

The On Bar Close? toggle in PU Settings gives you the choice between these two approaches. It is not hidden, not automatic, and not optimized for either case. You choose.

On Bar Close = ON (default)

Each slot uses the values from the last fully confirmed higher-timeframe bar.

What this means in practice on a 1-minute chart with a 5-minute slot:

• For the first minute after a 5-minute bar closes, the slot updates to reflect the newly confirmed 5-minute bar's MACD values.

• For the remaining four minutes, the slot holds that value. It does not change.

• When the next 5-minute bar closes, the slot steps to the new confirmed value.

This produces a staircase pattern: the slot's reading holds steady, then steps to a new level, then holds steady again. Each step happens exactly when an HTF bar closes.

What you gain: Stability. What you see is what happened. Historical readings match real-time readings. No bar on the chart will change its value after it has been plotted.

What you give up: Freshness. You are always one HTF bar behind the market. If the 5-minute bar is 4 minutes in and something significant has happened, the slot will not show it until the bar closes. The slot is reporting confirmed truth, not current truth.

On Bar Close = OFF

Each slot uses the values from the current in-progress higher-timeframe bar.

What this means on the same 1-minute chart with a 5-minute slot:

• On every 1-minute bar, the slot recalculates using the 5-minute bar that is still building.

• The values update smoothly and react to recent price action within the current HTF bar.

• When the 5-minute bar finally closes, the values settle to their final state.

What you gain: Responsiveness. The slot tracks evolving momentum within the current HTF bar. You see information sooner than with On Bar Close ON.

What you give up: Stability. The last few bars on the chart — the ones covering the current in-progress HTF bar — are provisional. They can and do change as the HTF bar continues building. When you scroll back through history, everything looks stable because all those bars were already confirmed. The instability only exists at the live edge.

This is the fundamental asymmetry that makes repainting dangerous: history always looks clean, but the present is uncertain.

The choice and what it means

Neither setting is wrong. The default (ON) is the safer choice and the right one for most use cases. OFF is a valid choice for experienced traders who understand the tradeoff and are not relying on the most recent bars for final decisions.

Verification walkthrough

You do not have to take this on faith. Here is how to verify the repaint behavior yourself.

Step 1: Verify On Bar Close = ON behavior

1. Open a 1-minute chart.

2. Add the indicator with default settings (On Bar Close = ON).

3. Watch Slot 01 (5m, teal line). It should hold steady for approximately five 1-minute bars, then step to a new value when the 5-minute bar closes.

4. Note the slot's value at the current bar.

5. Wait for the 5-minute bar to close. The value should update once, then hold again.

6. Scroll back a few bars. The values should be the same as what you observed when those bars were live. Nothing changed.

What you are confirming: That the slot updates only on HTF bar close and that the plotted values do not change after they appear. If the slot were repainting, you would see the value shifting on every 1-minute bar as the 5-minute bar builds. With On Bar Close = ON, it should hold perfectly still between 5-minute bar closes.

Step 2: Verify On Bar Close = OFF behavior

1. With the indicator still loaded, open settings and uncheck On Bar Close.

2. Watch Slot 01 again. It should now update on every 1-minute bar, moving more smoothly and reacting to intrabar price changes.

3. Note the slot's value at the current bar.

4. Wait a few 1-minute bars (still within the same 5-minute bar). The value may change.

5. Wait for the 5-minute bar to close. Watch whether the slot's recent values adjust when the HTF bar confirms.

6. Scroll back in history. The historical values look just as clean as they did with On Bar Close = ON — because they were already confirmed when recorded.

What you are confirming: That the slot updates intrabar, that the most recent values are provisional, and that the history-vs-live asymmetry exists.

Side-by-side comparison placeholder: Two chart captures of the same time period on a 1m chart. Left: On Bar Close = ON, showing the staircase step-update pattern. Right: On Bar Close = OFF, showing smooth intrabar updates. The historical bars look identical in both — the difference is visible only at the live edge.

Step 3: Understand the asymmetry

The key insight from this verification: with On Bar Close = OFF, history and live behavior are not the same. History shows confirmed values because those bars are in the past. Live shows provisional values because the current HTF bar is not closed.

This means a visual backtest done with On Bar Close = OFF is misleading. The historical signals look clean and stable, but in real time, the signals at the live edge would have been shifting. Any decision process that relies on the most recent few bars for entry or exit timing will see signals that were not as clean as they appear in hindsight.

This is the specific danger that burns people. You scroll through history with On Bar Close = OFF and every crossover looks crisp, every regime flip looks decisive. You build confidence in the tool's accuracy. Then you trade it live and the crossovers wobble, the regime flips hesitate, and the readings feel unreliable. Nothing broke — you are just seeing, for the first time, the instability that was always there but that confirmed history hid from you. The tool was never as crisp as the historical chart suggested. You were looking at a finished painting and mistaking it for a live camera.

How this interacts with alerts

All alerts in this indicator are bar-close gated on the chart timeframe. They fire only after the chart bar closes. This gating is independent of the On Bar Close setting.

With On Bar Close = ON, an alert fires on a confirmed chart bar referencing confirmed HTF data. Both layers are stable. The alert condition is reliable.

With On Bar Close = OFF, an alert fires on a confirmed chart bar, but the slot values behind that alert may include unconfirmed HTF data. The alert fired honestly — the condition was true at chart bar close — but the underlying data could shift when the HTF bar closes. In practice, this means an alert could fire, you could react to it, and then the underlying reading could change slightly when the HTF bar confirms.

For alert-based workflows, On Bar Close = ON is the appropriate default.

When OFF is a reasonable choice

Turning On Bar Close OFF is not reckless. It is a deliberate tradeoff that makes sense in specific situations:

• You are watching the chart live and want the earliest possible read on higher-timeframe momentum shifts. You understand that the last few bars are provisional and you treat them accordingly.

• You are using the oscillator for discretionary context, not for algorithmic or alert-based decisions. You are reading the pane as an evolving picture, not as a source of definitive signals.

• You are comparing the oscillator's live behavior to price action in real time and you value seeing the oscillator respond to the current bar over seeing it report what the last confirmed bar looked like.

In all of these cases, the key is understanding that you are trading freshness for stability. The readings update sooner, but the most recent readings are not final.

When ON is the right choice (most of the time)

Keep On Bar Close ON when:

• You are using alerts to trigger decisions or notifications

• You need auditable readings (the chart should show exactly what happened)

• You are comparing historical behavior to current behavior and need both to be on the same footing

• You are building a decision log or journal and want the oscillator readings to be stable references

• You are not sure which setting to use (the default is the safe choice)

The deeper point

Repainting is not a bug in a multi-timeframe indicator. It is a physics problem. The current higher-timeframe bar does not know its final value yet — it is still being written. Any indicator that shows you the "current" HTF value before the bar closes is, by definition, showing you something that can change.

The question is not whether the indicator repaints. The question is whether the indicator is honest about when and how it repaints, whether you can control the behavior, and whether you understand the tradeoff.

This tool gives you that control through a single toggle. The default is the stable, non-repainting mode. The alternative is available when you want it. Both are honest about what they show you — one shows confirmed past, the other shows evolving present. The difference is whether you prefer to be right about what happened or current about what is happening. There is no setting that gives you both.

Timeframe enforcement

One more safety measure: the indicator enforces that each slot's timeframe must be equal to or higher than the chart timeframe. If you set a slot to 5m on a 15m chart, the indicator refuses to load and shows a runtime error.

This prevents a different kind of MTF problem — requesting data from a lower timeframe, which introduces its own set of data alignment issues. The indicator is designed to request higher-timeframe data or same-timeframe data, never lower. This is an intentional constraint, not a limitation.