MTF and Repainting

This page is for the reader about to change an On Bar Close? setting, or the reader who has already changed one and wants to verify they did not introduce a silent problem. Multi-timeframe tooling sits at the intersection of a legitimate design choice and a silent failure mode — you can use the feature correctly for months and then, on the one day you reach for the live branch, produce a blend you are reading wrongly without noticing. The page exists to keep that day from being expensive.

It covers five things in order: what per-slot On Bar Close? actually returns under the hood, why the script pairs lookahead_on with a [1] shift, what happens when a slot's timeframe is empty, why the indicator refuses to run when a slot's timeframe is below the chart's, and the mixed-posture failure mode that per-slot control makes possible. The first four are mechanics; the fifth is the behavioural risk the other four combine to create.

What per-slot On Bar Close? returns

Each of the five slots exposes its own On Bar Close? boolean. All five default to true. Inside the slot's compute helper the final step picks the value to return based on that boolean:

• On Bar Close? = true. The slot returns the previous bar's clamped K and D — the values from one bar ago. The slot's historical series only updates when a higher-timeframe bar actually closes. Confirmed history to the left of the current bar is stable.

• On Bar Close? = false. The slot returns the current bar's live K and D, computed on whatever price data has printed so far in the forming bar. The forming bar can change its K and D every tick until the higher-timeframe bar closes. Because the [1] confirmation shift is skipped, this is not the safe historical HTF posture; do not use the false branch as evidence that a value was knowable on historical bars.

The default is true on every slot because that is the safer choice for most readers. You get a stable, non-repainting view of the past, and the current bar updates to the previous bar's confirmed value — which is a one-bar lag on the chart timeframe but a bar-by-bar stability on the higher timeframe.

You turn a slot's On Bar Close? to false when you want the current bar to reflect the currently forming HTF bar in real time, and you are willing to accept that the current bar's K and D may change until that HTF bar closes.

A plain-language example

You are on a 5-minute chart with slot 03 set to the 60-minute timeframe.

• Slot 03 On Bar Close? = true. On every one of the twelve 5-minute bars inside a forming 60-minute bar, slot 03 returns the confirmed K and D from the previous 60-minute bar. The slot K line on the chart looks flat across those twelve bars. When the 60-minute bar closes, the slot's series updates to the new confirmed value on the next bar.

• Slot 03 On Bar Close? = false. On every one of the twelve 5-minute bars inside a forming 60-minute bar, slot 03 returns the live K and D computed on whatever the 60-minute bar has printed so far. The slot K line moves bar by bar, potentially in several directions, as the 60-minute bar fills out. When the 60-minute bar closes, the slot's value at that close becomes the confirmed value — and any future true reading of that bar will return that same value.

Both modes are legitimate. They give you different kinds of information. The true mode gives you a clean, lagged, confirmed read. The false mode gives you a live, potentially noisy, real-time read. Neither is strictly better; they trade in opposite directions.

Why lookahead_on paired with [1] is the safe HTF pattern

The slot's request.security call uses lookahead = barmerge.lookahead_on. Used alone, lookahead_on pulls the most recent HTF value — including the live value of a forming bar — into the current chart bar. That can paint the future onto historical bars if you are not careful: a historical chart bar can be plotted against an HTF value that was not available when the chart bar printed.

The script pairs lookahead_on with a [1] shift in the true branch: kRaw[1] and dRaw[1], which means "the confirmed value from one HTF bar ago." This combination is the documented safe pattern for pulling HTF values into a lower-timeframe chart without introducing future data into historical plots. On historical bars, the HTF bar that printed one bar ago is always fully confirmed, so kRaw[1] is always a value that was actually available at the chart bar's close.

The practical result: when On Bar Close? = true, historical bars on the chart are plotted against HTF values that were knowable at those historical chart bars. Nothing in the historical series repaints.

When On Bar Close? = false, the [1] shift is skipped. The slot uses the live HTF value. This is deliberately a tradeoff: you get real-time HTF reads on the current forming bar, and you accept that the forming bar's value can change until the HTF bar closes. Historical false-branch values may also differ from the confirmed-branch values because lookahead_on is no longer paired with the prior-HTF-bar shift. Treat that branch as a live-read mode, not a non-repainting historical study mode.

This is not a bug and this is not a workaround. It is a standard Pine pattern for HTF work. The per-slot On Bar Close? toggle just makes the choice explicit for each slot.

What happens when a slot's timeframe is empty

Slots 04 and 05 default to an empty TimeFrame input. When empty, the slot falls back to timeframe.period at compute time, meaning the slot runs on the chart timeframe. There is no higher timeframe to wait for; the slot just computes on the current bar's data.

In this chart-TF collapse case, On Bar Close? = true still applies the [1] shift — it returns the previous bar's confirmed K and D on the chart timeframe. That is a one-bar lag. On Bar Close? = false returns the live values on the forming chart bar.

So even when a slot's timeframe is empty, the On Bar Close? toggle is not a no-op. It still controls whether you get the confirmed previous-bar values or the live forming-bar values. The difference is just smaller because there is no higher-timeframe mismatch to manage.

Why the slot errors when its timeframe is below the chart's

The script checks each enabled slot's timeframe in seconds against the chart timeframe in seconds. If the slot's timeframe is strictly lower, the script calls runtime.error with the message "Stoch 0X timeframe cannot be lower than the chart timeframe." and stops.

This is by design. A stochastic computed on a lower timeframe than the chart would produce multiple values per chart bar, which the chart has no way to represent without either aggregating or picking one value arbitrarily. Rather than pick arbitrarily and hide the ambiguity from you, the script refuses to run and tells you which slot is the problem.

Your responses:

• Lower the chart timeframe. Move the chart to the slot's timeframe or lower.

• Raise the slot's timeframe. Move the slot to the chart's timeframe or higher.

• Leave the slot's timeframe empty. The slot will inherit the chart timeframe, which by definition satisfies the "not below chart TF" rule.

• Disable the slot. A disabled slot does not run, so the check does not apply.

The troubleshooting page carries this as its first row. Read the error message — it names the exact slot — and pick the cheapest response for your workflow.

The mixed-posture failure mode

Per-slot On Bar Close? gives you finer control. It also gives you a failure mode you could not create on the Base trim, where a single global switch forced every slot into the same posture.

What "mixed posture" means

Suppose you enable slots 01, 02, and 03 and set:

• Slot 01 (5-minute): On Bar Close? = true. Returns previous confirmed 5-minute bar's K/D.

• Slot 02 (15-minute): On Bar Close? = true. Returns previous confirmed 15-minute bar's K/D.

• Slot 03 (60-minute): On Bar Close? = false. Returns live forming 60-minute bar's K/D.

The blend is the weighted mean of three slot values. Two of those values are confirmed historical readings. One of them is a live, possibly shifting, current reading. The blend's current-bar value is a mix of past certainty and present volatility.

This is the mixed-posture state.

Why it matters

Several downstream reads become harder to interpret cleanly:

• The blend K/D relationship mixes timeframes of certainty. If slot 03 is bullish right now in its live read but will flip bearish when the 60-minute bar actually closes, the blend is currently bullish on a basis that is not stable. That bullishness is real in the live sense — the 60-minute bar is currently bullish — but it is not what the blend will say once the bar closes.

• The alignment counts treat every slot as equally fresh. The activeSlotCount logic and the per-slot bullish/bearish evaluations do not care whether a slot's current value came from a confirmed [1] shift or a live read. They count both. So a "three slots aligned bullish" state can include a live slot-03 read that will not survive the 60-minute bar close.

• The structure features inherit the mix. Divergence, Keltner, BBWP, and Donchian all read the blended K after smoothing and clamp. They see the mixed-posture blend as their input. BBWP in particular can look jumpier than the stable-posture version because the live slot is adding short-term noise to the blend.

• The divergence module compares against chart-price pivots. With a mixed-posture blend, a divergence is comparing chart-price pivots against a blended-K value whose recent history is partially live. Confirmed pivots, confirmed barstate.isconfirmed gating, and a partially live input. The divergence logic does not stop working, but its interpretation is murkier.

How to spot it

Open Settings. Look at the On Bar Close? row on every enabled slot. If the values are not all the same, you are in mixed posture. That is the whole diagnostic — the state is not visible on the pane. Nothing in the blend plot, nothing in the structure features, and nothing in the alert log tells you that your current blend is averaging a confirmed series with a live one. The only place that truth lives is the Settings panel, and you have to go look at it.

A useful habit: treat every reconfiguration of a slot's On Bar Close? toggle as a moment to glance at the other slots' toggles too. You may have set slot 03 to false three weeks ago for a specific session and forgotten. Mixed posture created three weeks ago is just as silent as mixed posture created three minutes ago, and the mechanism that produces the misread is indifferent to when the toggle flipped.

When it is legitimate

Mixed posture is legal, not bug. There are specific cases where a reader genuinely wants it:

• A live HTF slot for real-time early warning. You want to see the current forming 60-minute bar's stochastic tilt in real time, knowing it may flip, and you want that live read inside your blend.

• A confirmed chart-TF slot for stability. You want your chart-timeframe slot rock-solid, so you keep it on true.

• You can finish the sentence: "I know slot 03 is live and slot 01 is confirmed, and I read the blend knowing that." If you can, mixed posture is a feature.

The default is all-true for a reason

If you cannot finish that sentence, the default of true on every slot is the honest position. Uniform posture across slots produces a blend whose members all agree about which bar's close they are reporting. Alignment counts compare like-for-like. Structure features read a stable input. You lose some freshness on HTF reads and gain a cleaner interpretation everywhere else.

A worked example: verifying "confirmed history stays stable"

One of the most load-bearing claims in this pack is that On Bar Close? = true produces stable historical bars. Verify it on your own chart like this.

1. Put the indicator on a 5-minute chart at defaults. Slot 03 is at 60-minute, On Bar Close? = true.

2. Scroll back to a historical 5-minute bar — say, 200 bars ago. Note the slot 03 K value at that bar. You can unhide slot 03's plot temporarily to see it; you can also hover the plot to read the exact value in the status line.

3. Wait one bar for a new chart bar to close.

4. Scroll back to the same 200-bars-ago bar. Note the slot 03 K value. It is the same value as before.

5. Toggle slot 03's On Bar Close? to false. Wait one bar.

6. Scroll back to the same 200-bars-ago bar. Note the slot 03 K value. This time the value is likely different from before — because without the [1] shift, the slot is reading a different HTF aggregation on that historical bar.

7. Toggle slot 03's On Bar Close? back to true. The historical value returns to what it was in step 2.

That sequence makes the repaint boundary concrete. With true, historical bars are stable. With false, historical bars can show different values depending on when you load the chart. This is not a bug in either mode; it is exactly what each mode is designed to produce.

Cross-ticker slots and session behaviour

The Optional Ticker input lets a slot run on a different symbol. This is useful for cross-asset context. It also introduces session behaviour that the chart's session may not match.

• The slot reads its Source on the other symbol's bars.

• The other symbol's session governs when the slot has data. An equities symbol slot on a 24-hour futures chart will have bars only during the equities session; the slot series will show gaps or flat values outside that session.

• Divergence still compares chart-price pivots against the blended K. The blended K now contains a cross-symbol slot. Confirmed pivots on the chart are detected on the chart's price; the divergence logic then compares them against a blended-K series that mixes on-symbol and off-symbol stochastic reads.

If you enable a cross-ticker slot, verify its behaviour during the session boundaries on your chart. If the slot reads flat during the chart's off-session hours, your blend is effectively a chart-only blend during those hours. The structure features will reflect that. The workflows page, Pattern B, walks through this in more detail.

A short inventory of MTF anti-patterns

• Setting an HTF slot to On Bar Close? = false "for responsiveness" without naming the live-read cost. You get responsiveness. You also get a slot whose current-bar value can change every tick. Wire this knowing what you bought.

• Leaving some slots on true and flipping one to false without checking the effect on alignment. Mixed posture. Alignment counts mix apples and oranges. See above.

• Assuming the On Bar Close? toggle is a no-op when the slot's timeframe is empty. It is not. It still applies the [1] shift on the chart timeframe, giving you a one-bar lag versus the live forming-bar read.

• Ignoring the runtime error and changing inputs until it goes away, without understanding which slot was out of range. The error message names the exact slot. Read it.

• Pairing a cross-ticker slot with extended-hours chart settings and reading the resulting blend as a single-session read. The cross-ticker slot obeys its own session, not the chart's.

Verification checklist before trusting MTF behaviour live

Run these before wiring any alert on a mixed-timeframe configuration:

• Confirm every enabled slot's On Bar Close? matches. If not, you are in mixed posture; decide deliberately.

• Confirm every enabled slot's TimeFrame is at or above the chart timeframe. No runtime error on load.

• Hover the forming bar on the chart. Note the blend K value. Wait one chart bar. Hover again. The blend K value should be stable on historical bars; the forming-bar value changes as new data prints.

• Force a cross-symbol slot to run by setting Optional Ticker on one slot. Verify the slot has data during your trading hours and check whether gaps appear during the chart's off-session.

• On a quiet bar, flip one HTF slot from true to false. Watch the blend line for live motion on the forming bar. Flip back to true. The blend's current-bar value settles to the confirmed version.

Where to go next: Settings for per-slot input details, Alerts for how alert timing interacts with barstate.isconfirmed, Limitations and trust boundaries for the mixed-posture failure mode in the full trust-boundary context, For the geeks for the pipeline's mechanical depth.