MTF and Repainting

This page is about a single switch and one rule that governs slot timeframes. The switch is `On Bar Close?`. The rule is: every slot's timeframe must be at or above the chart's timeframe. Between the two, they account...

Written By Axiom Admin

Last updated 22 days ago

MTF and Repainting

This page is about a single switch and one rule that governs slot timeframes. The switch is On Bar Close?. The rule is: every slot's timeframe must be at or above the chart's timeframe. Between the two, they account for most of the MTF-related confusion a reader can run into on this pane, and both can be verified in a minute on a 1m chart.

If you have been burned by an MTF oscillator whose reading changed under you after you made a decision on it, this page is where that injury gets addressed directly. The switch has two positions, both of them honest. The job of this page is to make sure you know which one you have set and what it costs.

The On Bar Close? switch, in plain language

On Bar Close? is a global boolean at the bottom of the input panel, under the PU Settings group. It controls the repaint posture for every slot at once on the Base trim. You do not get per-slot control of this switch on Base. CTX exposes a per-slot version.

On Bar Close? = true is the stable position. Each slot's request.security call returns the previous higher-timeframe bar's values. The numbers the slot is showing you are the numbers from the last closed bar of its timeframe. Those numbers do not revise as the next higher-timeframe bar forms. The cost is latency β€” you are always one slot-timeframe bar behind real time on each slot.

On Bar Close? = false is the live position. Each slot returns the current higher-timeframe bar's values. The numbers move as the bar moves. When the higher-timeframe bar finally closes, the slot's reading settles to what it was showing at the moment of close. Until then, it can drift up and down inside the open bar. The cost is revision β€” a reading you made a decision on at minute 7 of a 60m bar is not the reading the slot will print at minute 8 of the same bar.

Both modes are honest if you know which mode you have set. Neither is "better." They are different tradeoffs for different reading contexts. A reader who wants to watch conditions evolve intra-bar has a reason to turn the switch off. A reader who only acts on confirmed reads has a reason to keep it on. A reader who does both things at different times on the same chart is looking at a feature Base does not expose β€” per-slot bar-close control β€” and that lives on CTX.

A frame worth carrying: On Bar Close? = true is the posture of a reader who treats a decision as final only when the evidence is final. On Bar Close? = false is the posture of a reader who wants to see a read forming in real time and accepts that the read can move before it settles. Neither posture is reckless and neither is paranoid. Pick the one that matches what you are actually doing. The accident to avoid is drifting between postures without noticing β€” acting on a live read as if it were confirmed, or waiting for confirmation while the instrument is actually showing you the live state you asked for. If you find yourself unsure which mode you are in, stop and check the input panel. Ten seconds.

One note about what the switch is not: it is not the entire non-repainting story internally. The indicator also uses lookahead = barmerge.lookahead_on in its request.security call, and that lookahead mode plus the previous-bar selection when ON is what makes the read non-repainting. They are two different mechanisms that cooperate. The manual does not treat them as the same thing, and you do not need to either. What matters is that ON is the confirmed-read mode and OFF is the live-read mode.

A 1m verification you can run in under two minutes

This verification takes less time than reading about it. Do it once. It is the fastest way to feel the switch in the bones of your chart.

  1. Load Axiom Stoch Osc onto a 1m chart of a liquid instrument. Use the defaults. Slot 01 at 5m, slot 02 at 15m, slot 03 at 60m. On Bar Close? = true.

  2. Pick slot 03 and watch it for a few minutes across several chart bars. With the switch on, slot 03's K line holds flat across chart bars that sit inside the same 60m bar β€” the reading only updates when the 60m bar closes. The tinted fill and blend will move a bit as slot 01 and slot 02 update, but slot 03's contribution to the blend is the same number across all 60 of the 1m chart bars inside that 60m bar.

  3. Toggle On Bar Close? to false. Watch slot 03 again. Inside the open 60m bar, slot 03 will begin drifting β€” its K moves as price moves inside the bar, because the slot is now returning the live higher-timeframe values. The blend will move more visibly too.

  4. Wait until the current 60m bar closes. At the moment of close, slot 03's value is whatever it was showing at that instant. If you switch back to On Bar Close? = true on the next bar, slot 03 will then hold that just-closed reading flat across all the 1m chart bars inside the new 60m bar.

  5. As a sanity check, compare the slot 03 values at the 60m close in both runs. They should match β€” the confirmed [1] read in ON is the close of the bar that just completed; the OFF read at the moment of close is the same number. Different paths to the same point.

What this verification is teaching you: ON is retrospective, OFF is contemporaneous, and the retrospective read is always equal to the contemporaneous read at the moment the slot-timeframe bar closed. The two modes report the same truth at bar closes. They disagree between bar closes.

The slot-TF-at-or-above-chart-TF rule

Every enabled slot must have a TimeFrame: equal to or higher than the chart's timeframe. If you set slot 02 to 1 and load the indicator on a 5m chart, the indicator raises a Pine runtime error that names the slot directly:

Stoch 02 timeframe cannot be lower than the chart timeframe.

Slots 01 and 03 raise the same error with their own slot labels if they are misconfigured the same way. The error is the indicator refusing a nonsensical configuration. This Base script is built for same-timeframe or higher-timeframe slots, and rather than silently accepting a lower-timeframe request it surfaces the misconfiguration so you know you did not get what you asked for.

Fix it two ways: raise the slot's timeframe to the chart's timeframe or higher, or lower the chart's timeframe to sit below the slot's. The rule is one-way. Chart TF ≀ slot TF is allowed; chart TF > slot TF is not.

When the chart timeframe changes

A different case is easy to misread. You have been running the defaults on a 1m chart β€” slot 01 at 5m, slot 02 at 15m, slot 03 at 60m β€” and then you switch the chart to 1H. The script does not collapse the 5m and 15m slots into the 1H chart. It raises the same runtime error described above, because those two slot timeframes are now lower than the chart timeframe.

The tool is correct. The configuration has lost its premise. The remedy is to reconfigure, not to report a bug. On a 1H chart, a useful slot stack might be 1H, 4H, 1D β€” three slots that are valid on the chart and meaningfully apart from each other. On a 5m chart, 5m / 15m / 60m is fine. The rule to carry forward is simple: every slot timeframe must be equal to or higher than the chart timeframe, and the slot stack should still be far enough apart to tell you something.

You can still create a "collapsed" read by configuration rather than by accident: set multiple slots to the same timeframe, same source, same K length, and same smoothing, and they will naturally draw nearly the same values. That is not Pine silently resolving lower timeframes. That is three near-duplicate slots asking the same question.

This case shows up when a reader moves between chart timeframes during a session and forgets to revisit the slot configuration. It is one of the most common "the tool broke" reports that turns out to be configuration, not behavior.

Source: and the slot-context high and low

A small note worth having on this page because it is easy to miss and painful to discover the hard way.

The stochastic transform takes three inputs, not one. A close, a high, and a low, over the K Length lookback. The slot's Source: input only substitutes for the close term. The high and low come from the slot's request.security context β€” a 5m slot sees 5m highs and lows, a 60m slot sees 60m highs and lows β€” not from whatever you selected as Source:.

So if you swap a slot from close to hlc3, the raw %K changes because the close term has been replaced by hlc3. The high and low do not change. On bars with long wicks, that substitution can shift the raw %K meaningfully. Readers who swap Source: expecting the whole stochastic measurement to rebuild from hlc3 highs and lows too are going to misread what changed.

This matters for MTF readers specifically because the slot-context high and low are the piece that makes the slot's measurement live in its own timeframe. The "slot is measuring the 60m stoch" property comes from the high and low resolving in the 60m context. Source: is layered on top of that context; it does not replace it.

When to touch the switch and when to leave it

A short field guide. Not recommendations β€” contexts in which a choice lands sensibly.

Leave On Bar Close? = true if:

  • You act on confirmed reads, not intra-bar reads.

  • You want slot 03's contribution to the blend to be stable across the 60 one-minute chart bars inside a 60m bar.

  • You have wired blend-based or alignment alerts and want them to fire on the same values that were visible to you at the confirming chart bar.

  • You are reviewing a chart historically and want the non-replay mode of what the pane would have printed on closed bars.

Turn On Bar Close? = false if:

  • You want to watch conditions evolve inside an open higher-timeframe bar.

  • You are using the pane as a live context display and you accept that any decision you make on the displayed value will need to be re-evaluated if the bar moves.

  • You are testing how a particular slot configuration reacts inside open bars on your instrument, and you are willing to wait for bar closes before drawing firm conclusions.

If you want one slot on ON and another on OFF at the same time, that is CTX. Base does not expose it.

What alerts do and do not promise under each mode

Every alert on this indicator is gated by barstate.isconfirmed β€” meaning alerts only evaluate on confirmed chart bars. That gate is about the chart bar, not the slot bar. Here is what that means in practice.

With On Bar Close? = true, a slot's values on every chart bar inside an open higher-timeframe bar are the previous higher-timeframe bar's values. Chart bars confirm, the alert evaluates against those previous-close values, nothing drifts. Predictable.

With On Bar Close? = false, a slot's values on every chart bar inside an open higher-timeframe bar are the live higher-timeframe values as of that chart bar. Chart bars confirm, the alert evaluates against whatever the slot was showing at chart bar close, which is still intra-bar for the slot. An alert can fire on a chart bar and a subsequent chart bar (still inside the same open higher-timeframe bar) can print a different state the next time the alert checks. That is the repaint surface.

This is not a hidden gotcha. It is the direct consequence of the switch being off. It is also the reason On Bar Close? = false is useful for live monitoring and not for firmly-confirmed signals β€” you are trading higher responsiveness against the possibility of state revisions inside open bars.

Cross-references

  • The On Bar Close? field on the input panel: Settings.

  • The alignment alert behavior under intra-bar drift: Alerts.

  • Timeframe errors and near-duplicate slot reads as troubleshooting entries: Troubleshooting.

  • The runtime error from a slot below the chart's timeframe as a troubleshooting entry: Troubleshooting.