► Timeframe selection
The higher timeframe can be selected using 3 different ways:
• By steps (60 min., 1D, 3D, 1W, 1M, 1Y).
• As a multiple of the current chart's resolution, which can be fractional, so 3.5 will work.
► Non-repainting or Repainting mode can be selected.
► Smoothing of the HTF line
Can be turned on/off and a smoothing factor allows the user to select the degree of smoothing he requires.
The framework is used here to create a higher timeframe version of a simple line, but it can be used to access HTF information for almost any signal.
• In Pine, the timeframe.multiplier is an integer representing the resolution, but a value of 1 can mean one day or one minute. This function converts that information in a standard fractional float minutes format that can then be used by the other functions in the framework.
• If the chart's current resolution is 15 seconds, the function will return 0.25. If the chart's resolution is one day, it will return 1440.
• This function does the same as f_resInMinutes(), but on the target resolution supplied as a parameter in the timeframe.period string format.
• This allows the implementation of the step HTF selection mode.
• A multiple like 3.5 is allowed.
• Note that with seconds resolutions, the result returned is constrained by the discrete seconds resolutions available on TV.
f_htfLabel(_txt, _y, _color)
• A warning when the chart's resolution is not lower than the HTF.
• The HTF resolution currently used.
The y position used to position the label will require adaptation to the signal you are using. For use in "overlay = true" mode, a technique that works well is commented out in the code.
• Added steps to the shorter TFs in f_resNextStep(). The steps are now: 15 min., 60 min., 4H, 1D, 3D, 1W, 1M, 1Y.
• Also added a compact version of the functions at the end of the script, which uses only 7 lines.
Added one function:
But would it be possible to use the timeframe multiplier for this? Something like f_multipleOfRes(vResInMinutes, vHtfType2) / timeframe.period ???
Right now the smoothing isn't that great
vHtfSmoothLen = int(max(2, vHtfType2))
vHtfSmoothLen = int(max(2, f_tfResInMinutes(vHtf)/vResInMinutes)) Sma(src,p) => a = cum(src), (a - a[max(p,0)])/max(p,0) rHtf := vHtfOn and vHtfSmooth ? Sma(Sma(Sma(rHtf, vHtfSmoothLen), vHtfSmoothLen), vHtfSmoothLen) : rHtf
When you need to code for each variable in your script 2 securitycalls() to get it into HigherTimeframe.... Then you bump into the problem of too many securitycall() in your script.
Do you have an idea how to prevent this,.... so is there a more generic manner??
==> talking about this line: ..... rHtf = not vHtfOn ? r : vHtfRepaints ? security(syminfo.tickerid, vHtf, r) : security(syminfo.tickerid, vHtf, r, lookahead = barmerge.lookahead_on)
1. Eliminate one of the 2, so either hard-code whether you are repainting or not.
2. Use this structure to control repainting:
// —————————— Alternate but more complex way of avoiding repainting using barmerge.lookahead_off. // It is also possible to avoid repainting using "lookahead_off" (the default in v3 and v4), but we then need to include logic // to use different "security()" calls for historical and real-time bars, so it's more complicated: // 1. for the REALTIME bar we use: security(syminfo.tickerid, higherTf, data) // 2. for HISTORICAL bars we use: security(syminfo.tickerid, higherTf, data) indexHighTf = barstate.isrealtime ? 1 : 0 indexCurrTf = barstate.isrealtime ? 0 : 1 sec2ff = security(syminfo.tickerid, higherTf, data[indexHighTf])[indexCurrTf]
which is taken from here: