MTF and Repainting
This is the page that decides whether your historical read is honest or dressed up after the fact.
Written By Axiom Admin
Last updated About 1 month ago
MTF & Repainting
This is the page that decides whether your historical read is honest or dressed up after the fact.
The script uses request.security() with lookahead_on, then switches between two different source patterns:
On Bar Close = on: each slot returns the previous bar's Fast/Slow inside the requested timeframe context (
fastRaw[1],slowRaw[1])On Bar Close = off: each slot returns the current bar's Fast/Slow inside that requested timeframe context
That one choice changes what the lower-timeframe chart is allowed to know.
What the problem is
This indicator is built to pull MA-distance readings from higher timeframes. If you are on a 1-minute chart and one slot is set to 15m, TradingView has to decide what the 1-minute bars should see while that 15-minute candle is still forming.
If you let the 1-minute bars see the still-building 15-minute value, you get a faster line in live use. You also get a chart that lies when you look back. The lower-timeframe bars inside that 15-minute block will later display the finalized 15-minute value, even though that value did not exist yet on the early 1-minute bars.
That is the repaint risk here. It is not abstract. It is the exact mechanism that can make historical review look cleaner than live experience.
How On Bar Close works
Axiom MA Osc Lite has one global toggle in the PU settings: On Bar Close? (default: on).
When On Bar Close is ON
Each slot uses the last confirmed bar from its requested timeframe.
In practical terms:
On a 1-minute chart with a 15-minute slot, every 1-minute bar inside the 10:00-10:14 window sees the oscillator value from the 9:45-10:00 15-minute bar.
At 10:15, the slot steps to the value from the 10:00-10:15 15-minute bar.
Historical bars stay stable because the script never asks lower-timeframe bars to look into the still-building higher-timeframe candle.
This is the safe pattern in the code: previous requested-timeframe value plus lookahead_on.
When On Bar Close is OFF
Each slot uses the current bar from its requested timeframe.
In practical terms:
On a 1-minute chart with a 15-minute slot, the 10:03 bar can reflect the current state of the still-building 10:00-10:15 15-minute candle.
In live use, that value can change again at 10:04, 10:05, and so on until the 15-minute candle closes.
In historical view, TradingView backfills the final 10:00-10:15 value across the whole 10:00-10:14 block.
That last bullet is the part people miss. The contamination is not limited to the bar on the far right. It affects the lower-timeframe bars inside each requested-timeframe bucket.
Why it matters for historical review
With On Bar Close off, the chart you scroll back through is not showing you what the lower-timeframe bars knew at the time. It is showing you the finalized higher-timeframe value painted across that whole block after the fact.
So if you study a 1-minute chart and think:
"The oscillator was already at this level on the 10:03 bar."
that may be false. What the historical chart is really showing is:
"Once the 10:00-10:15 candle finished, this became the final value for that whole 15-minute block."
That is why historical comparisons, screenshot analysis, and bar-by-bar strategy review need On Bar Close on.
Verification routine
You can verify the behavior directly.
Step 1: Create a simple test
Open a 1-minute chart.
Leave one slot at 15m.
Keep On Bar Close on.
Step 2: Look for the stepped pattern
The 15m-driven slot should hold the same value across several 1-minute bars, then step when the next 15-minute candle confirms. That blocky behavior is the confirmation safeguard working.
Step 3: Toggle On Bar Close off
Turn On Bar Close off and watch the same slot near the right edge. It should start reflecting the still-building 15-minute candle instead of the previous confirmed one.
Step 4: Watch a full higher-timeframe block form
As new 1-minute bars print inside the active 15-minute candle, the slot can keep changing. Once that 15-minute candle closes, the historical chart for that 15-minute block now shows the finalized higher-timeframe value across the block.
Step 5: Toggle On Bar Close back on
Turn it back on and compare the same lower-timeframe bars inside that 15-minute block. They will now show the previous confirmed 15-minute value instead.
The difference is not just the rightmost bar. It is the whole requested-timeframe bucket.
What On Bar Close does NOT protect against
1. Same-timeframe slots still lag when protection is on
If a slot uses the same timeframe as the chart, On Bar Close on still makes that slot use the previous bar's value. That is correct for this implementation, but it means the slot is one bar behind instead of live on the current bar.
2. Chart-bar confirmation is not the same thing as HTF confirmation
Every alert condition is gated with barstate.isconfirmed, which means the alert evaluates on a closed chart bar.
That does not mean the higher-timeframe input behind the alert was confirmed.
If On Bar Close is off, an alert can still fire on a confirmed 1-minute bar using a still-building 15-minute value. The alert timing is chart-bar-confirmed. The higher-timeframe source is not.
3. ATR normalization still changes what a given number means
On Bar Close protects the higher-timeframe request pattern. It does not freeze ATR as a concept. ATR is still a rolling denominator. A reading of +60 in one volatility regime and +60 in another does not necessarily represent the same raw price-to-MA distance.
That is not repainting. It is just the cost of volatility-relative scaling.
Summary of the tradeoff
If you are unsure, leave it on.
This script is much more useful one bar late and honest than fast and flattering.