MTF and Repainting

This page exists because multi-timeframe tools are easy to trust too quickly. The chart can look neat. The higher-timeframe logic can still be doing something more complicated than the finished history suggests. That is not a scandal. It is simply a timing reality you need to understand before you start leaning on the stack.

For this indicator, the key truth is simple:

• timing posture belongs to each slot

That makes the tool more adaptable. It also means the stack can mix confirmed and live-forming behavior if you let it. That is why this page matters so much: on a busy chart, mixed timing can look like agreement when it is really asynchronous information sharing one pane.

Three timing checks that prevent most mistakes

Before you decide what the stack means, check these three things:

• the chart timeframe you are standing on
• the requested timeframe each active slot is reading
• whether each active slot is confirmed or still forming

Those checks sound basic. They are also where most false confidence starts.

Start with the right question

Do not start with "Does it repaint?" Start with:

• which slot is confirmed?
• which slot is still forming?
• what tradeoff did I choose for each one?

That is the more useful question because this indicator does not have one blanket timing answer for the whole stack.

What `On Bar Close?` really does

Each slot has its own `On Bar Close?` setting.

When `On Bar Close?` is on

That slot waits for confirmed requested-timeframe values.

Practical effect:

• the slot behaves more steadily
• historical and live behavior line up more closely
• you get less early movement from the requested timeframe

When `On Bar Close?` is off

That slot is allowed to follow the still-forming requested-timeframe bar.

Practical effect:

• the slot can react earlier
• the slot can also change before that requested bar is finished
• the live path can look less settled than the finished historical picture

Neither setting is secretly the correct one for every trader. They solve different problems.

What makes MTF trust slippery

Most confusion comes from collapsing three separate clocks into one story:

• the chart timeframe
• the slot's requested timeframe
• the chart-bar-close timing used for alerts

Those clocks do not automatically line up. That is why a normal alert can still involve a live-forming higher-timeframe slot. The chart bar may have closed. The requested slot timeframe may still be building.

The hard legality rule

An enabled slot cannot use a `TimeFrame:` below the chart timeframe.

This matters for two reasons:

• it prevents illegal setups from quietly producing bad interpretation
• it reminds you that the slot is being asked to represent a context layer, not a lower-timeframe shortcut on a higher-timeframe chart

If the script throws an error right after loading, check the enabled slot timeframes first.

Mixed slot timing is the real trust boundary

The most important timing risk here is not the word "repainting" by itself. It is mixed confirmed and live-forming posture inside the active stack.

That happens when:

• one active slot is confirmed
• another active slot is live-forming
• both are being summarized into the same blend

Why this matters:

• the blend can look smooth even when one contributor is still in motion
• alignment can change because of a live-forming slot while the other slots look settled
• the chart can tell a more coherent story than the timing contract underneath it actually deserves

Mixed timing is not automatically wrong. It needs to be chosen and verified on purpose.

A good way to think about repainting here

Use this wording in your own mind:

• confirmed slots are steadier and easier to compare across history and live use
• live-forming slots are earlier and less final

That framing is more useful than hunting for one blanket label.

What chart-bar-close alerts do not solve

All implemented alerts are chart-bar-close gated.

That does help keep alerts from firing on every intrabar twitch of the chart. It does not change the timing contract of an active slot.

If a slot is live-forming, it stays live-forming. The alert firing on a closed chart bar does not magically turn that slot into confirmed higher-timeframe data.

A replay-friendly verification routine

Use this when you want to stop guessing and actually see the timing tradeoff.

1. Keep the chart on a low timeframe such as `1m` or `5m`.
2. Use two slots with the same symbol, `TimeFrame:`, source, and MACD settings.
3. Leave `On Bar Close?` on for one slot.
4. Turn `On Bar Close?` off for the other.
5. Watch both slots while the requested higher-timeframe bar is still building.
6. Compare them again after that requested bar closes.

What you should notice:

• the live-forming slot can move sooner
• the confirmed slot usually stays steadier until the requested bar finishes
• the difference matters most before the requested bar closes

That is the timing tradeoff in plain sight.

When confirmed mode is usually the better starting point

Confirmed mode is usually the better starting point when:

• you are still learning the stack
• you care about cleaner history-to-live consistency
• you do not want mixed timing posture in the baseline ladder
• you want easier explanation when an alert fires

When live-forming mode can be worth using

Live-forming mode can be worth using when:

• earlier awareness matters more than the cleanest trust boundary
• you have already watched how the slot behaves before requested bars finish
• you are comfortable with the slot revising before that requested bar closes

Use it because you chose the tradeoff, not because "faster" sounded automatically better.

What to avoid

Avoid these timing mistakes:

• turning live-forming mode on for several important slots at once
• mixing timing posture across the baseline ladder before you understand the cost
• assuming historical calm proves live calm
• forgetting that the blend can summarize mixed timing states

A short self-check

Before you trust a higher-timeframe read, ask:

1. What is this slot's requested timeframe?
2. Is that slot confirmed or live-forming?
3. If this slot changed before the requested bar closed, would I call that expected or suspicious?
4. If several slots disagree, is the disagreement coming from timing or from actual context differences?

If those answers are clear, the timing boundary is probably healthy. If not, simplify the stack until it is.

Visual placeholder: Side-by-side pane capture showing two matching slots on the same requested timeframe, with only `On Bar Close?` different, plus one note explaining that chart-bar-close alerts do not erase live-forming slot behavior.