Custom Time Frame (CTF)This indicator allows users to create their own arbitrary time frames for chart analysis. It features a moving average, providing an additional layer of analysis, and offers flexibility through various open settings.
In terms of user settings and usage, the indicator provides several options. Users can choose their interval style, opting for either tick-based or time-based intervals. This flexibility allows for a more granular approach to data analysis, catering to different trading strategies and preferences. The number of ticks or the amount of time for each candle can be adjusted, enabling traders to set the granularity of the data to their liking. Color settings are also customizable, with options for setting colors for bullish and bearish indicators, adding a visual dimension to the analysis.
The average line parameters are an important aspect of this indicator. Users can adjust the length, ripple, type, color, and line width of the average line. The ripple setting, in particular, impacts the smoothness of the filter. With type II setting, the smoothing is increased, making it suitable for traders who prefer a more smoothed out moving average. Conversely, the type I setting decreases the smoothing, which might be preferred by those who want a more responsive indicator.
The use of the Chebyshev filter is a significant feature of this indicator. This filter is chosen for its high-performance smoothing capabilities with minimal data requirements. This ensures that the moving average appears quickly and accurately, which is crucial in real-time chart analysis. An important point to note is that when the moving average is enabled, it decreases the maximum number of candles that can be displayed on the chart. However, this is offset by the enhanced analytical precision provided by the moving average.
In summary, this indicator is especially beneficial for traders without access to premium accounts. It offers the capability to create low or custom time frame charts. The flexibility in settings, coupled with the inclusion of a Chebyshev filter for the moving average, makes it a versatile and valuable tool for detailed market analysis. It caters to a wide range of trading styles and strategies, making it a useful addition to any trader's toolkit.
Varip
OHLC📕 LIBRARY OHLC
🔷 Introduction
This library is a custom library designed to work with real-time bars. It allows to easily calculate OHLC values for any source.
Personally, I use this library to accurately display the highest and lowest values on visual indicators such as my progress bars.
🔷 How to Use
◼ 1. Import the OHLC library into your TradingView script:
import cryptolinx/OHLC/1
- or -
Instead of the library namespace, you can define a custom namespace as alias.
import cryptolinx/OHLC/1 as src
◼ 2. Create a new OHLC source using the `new()` function.
varip mySrc = OHLC.new() // It is required to use the `varip` keyword to init your ``
- or -
If you has set up an alias before.
varip mySrc = src.new()
===
In that case, your `` needs to be `na`, define your object like that
varip mySrc = na
◼ 3. Call the `hydrateOHLC()` method on your OHLC source to update its values:
Basic
float rsi = ta.rsi(close, 14)
mySrc.hydrateOHLC(rsi)
- or -
Inline
rsi = ta.rsi(close, 14).hydrateOHLC(mySrc)
◼ 4. The data is accessible under their corresponding names.
mySrc.open
mySrc.high
mySrc.low
mySrc.close
🔷 Note: This library only works with real-time bars and will not work with historical bars.
Motion▮ FEATURES
Now as library version :)
String-based transition-effects
Performance optimization. Reduced memory consumption up to >90% by kicking the output to the "stdout".
Use marquee- or loader-effect on any possible string location.
Example: UI Price-Ticker
----------------------------------------------------------------------------
Library "Motion"
_getStringMono(_len, _str, _sep)
Parameters:
_len
_str
_sep
marquee(this, _extern, _ws, _subLen, _subStart)
Parameters:
this
_extern
_ws
_subLen
_subStart
transition(this, _subLen, _subStart)
Parameters:
this
_subLen
_subStart
hold(this)
Parameters:
this
keyframe
keyframe A keyframe object.
Fields:
seq
intv
step
length
update_no
frame_no
ltr
hold
Education: INDEXThis is an INDEX page where educational links/scripts are sorted in the script itself (see below)
For example:
- where is the link of the 'var' article/idea?
-> search in the script comments below for Keywords -> var -> look for the date ->
now you will find the link at the date of update
Intrabar Price/Volume Change (experimental)This experimental script shows the intrabar progression of price/volume
It can only be used with live data, when you switch timeframe or ticker, it will start over again.
When you let the script run, you'll get insight of what is going on during the bar progression.
On each tick, when the price goes up, a green line will be drawn,
if it goes down, a red line is drawn. The higher the difference with previous price, the wider the line.
The same with volume (lighter, broader lines), only it will always be drawn in the same direction as price goes.
You can set the max width of the lines, when a spike is larger then previous lines, the rest will be adjusted, so the ratio stays the same
The center line (position can be changed) has 2 colors (only on second and minute timeframes) -> this makes it easy to see the bar progression, each change in color represents a new bar
Lines can be drawn on 2 sides, or at 1 side, also they can be reversed
Many thanks to @LonesomeTheBlue and @LucF for their inspiration, help and guidance!
Cheers!
Bar Percent CompleteThis is an example script for checking how far the current bar has progressed towards it's completed state. This works for any time frame, eliminating extra logic calls and conversions for each timeframe.period. It is not intended to be a standalone indicator, but rather as a resource for additional logic triggers on the real time bar of a pine script.
The main caveat is that pine script calculations occur on a per-tick basis. This means that the completion percentage can exceed the percentage threshold before any logic is executed. This happens when the next tick occurs after the threshold. The relevance then will depend on the activity of the underlying asset. Longer time frames on low activity assets will likely be more relevant than their shorter time frame counterparts.
Time and SalesThis scrip mimics time and sales window displaying tick by tick data coming from the exchange.
It only works when the market is open. And it does not store historical data.
Red color when the last price was higher than the new price.
Gray when both were same.
Green when new price is higher than last price.
Please note that I have tested this in India NSE Market Only. If you find anything buggy let me know in the comments, I will try to update it.
[CLX][#01] Animation - Price Ticker (Marquee)This indicator displays a classic animated price ticker overlaid on the user’s current chart. It is possible to fully customize it or to select one of the predefined styles.
A detailed description will follow in the next few days.
Used Pinescript technics:
- varip (view/animation)
- tulip instance (config/codestructur)
- table (view/position)
By the way, for me, one of the coolest animated effects is by Duyck
We hope you enjoy it! 🎉
CRYPTOLINX - jango_blockchained 😊👍
Disclaimer:
Trading success is all about following your trading strategy and the indicators should fit within your trading strategy, and not to be traded upon solely.
The script is for informational and educational purposes only. Use of the script does not constitute professional and/or financial advice. You alone have the sole responsibility of evaluating the script output and risks associated with the use of the script. In exchange for using the script, you agree not to hold dgtrd TradingView user liable for any possible claim for damages arising from any decision you make based on use of the script.
Tick Data DetailedHello All,
After Tick Chart and Tick Chart RSI scripts, this is Tick Data Detailed script. Like other tick scrips this one only works on real-time bars too. it creates two tables: the table at the right shows the detailed data for Current Bar and the table at the left shows the detailed data for all calculated bars (cumulative). the script checks the volume on each tick and add the tick and volume to the specified level (you can set/change levels)
The volume is multiplied by close price to calculate real volume .There are 7 levels/zones and the default levels are:
0 - 10.000
10.000 - 20.000
20.000 - 50.000
50.000 - 100.000
100.000 - 200.000
200.000 - 400.000
> 400.000
With this info, you will get number of ticks and total volumes on each levels. The idea to separate this levels is in order to know which type of traders trade at that moment. for example volume of whale moves are probably greater than 400.000 or at least 100.000. Or volume of small traders is less than 10.000 or between 20.000-50.000.
You will get info if there is anomaly on each candle as well. what is anomaly definition? Current candle is green but Sell volume is greater than Buy volume or current candle is red but Buy volume is greater than Sell volume . it is shown as (!). you should think/search why/how this anomaly occurs. You can see screenshot about it below.
also "TOTAL" text color changes automatically. if Buy volume is greater than Sell volume then its color becomes Green, if Sell volume is greater than Buy volume then its color becomes Red (or any color you set)
Optionally you can change background and text colors as shown in the example below.
Explanation:
How anomaly is shown:
You can enable coloring background and set the colors as you wish:
And Thanks to @Duyck for letting me use the special characters from his great script.
Enjoy!
Using `varip` variables [PineCoders]█ OVERVIEW
The new varip keyword in Pine can be used to declare variables that escape the rollback process, which is explained in the Pine User Manual's page on the execution model . This publication explains how Pine coders can use variables declared with varip to implement logic that was impossible to code in Pine before, such as timing events during the realtime bar, or keeping track of sequences of events that occur during successive realtime updates. We present code that allows you to calculate for how much time a given condition is true during a realtime bar, and show how this can be used to generate alerts.
█ WARNINGS
1. varip is an advanced feature which should only be used by coders already familiar with Pine's execution model and bar states .
2. Because varip only affects the behavior of your code in the realtime bar, it follows that backtest results on strategies built using logic based on varip will be meaningless,
as varip behavior cannot be simulated on historical bars. This also entails that plots on historical bars will not be able to reproduce the script's behavior in realtime.
3. Authors publishing scripts that behave differently in realtime and on historical bars should imperatively explain this to traders.
█ CONCEPTS
Escaping the rollback process
Whereas scripts only execute once at the close of historical bars, when a script is running in realtime, it executes every time the chart's feed detects a price or volume update. At every realtime update, Pine's runtime normally resets the values of a script's variables to their last committed value, i.e., the value they held when the previous bar closed. This is generally handy, as each realtime script execution starts from a known state, which simplifies script logic.
Sometimes, however, script logic requires code to be able to save states between different executions in the realtime bar. Declaring variables with varip now makes that possible. The "ip" in varip stands for "intrabar persist".
Let's look at the following code, which does not use varip :
//@version=4
study("")
int updateNo = na
if barstate.isnew
updateNo := 1
else
updateNo := updateNo + 1
plot(updateNo, style = plot.style_circles)
On historical bars, barstate.isnew is always true, so the plot shows a value of "1". On realtime bars, barstate.isnew is only true when the script first executes on the bar's opening. The plot will then briefly display "1" until subsequent executions occur. On the next executions during the realtime bar, the second branch of the if statement is executed because barstate.isnew is no longer true. Since `updateNo` is initialized to `na` at each execution, the `updateNo + 1` expression yields `na`, so nothing is plotted on further realtime executions of the script.
If we now use varip to declare the `updateNo` variable, the script behaves very differently:
//@version=4
study("")
varip int updateNo = na
if barstate.isnew
updateNo := 1
else
updateNo := updateNo + 1
plot(updateNo, style = plot.style_circles)
The difference now is that `updateNo` tracks the number of realtime updates that occur on each realtime bar. This can happen because the varip declaration allows the value of `updateNo` to be preserved between realtime updates; it is no longer rolled back at each realtime execution of the script. The test on barstate.isnew allows us to reset the update count when a new realtime bar comes in.
█ OUR SCRIPT
Let's move on to our script. It has three parts:
— Part 1 demonstrates how to generate alerts on timed conditions.
— Part 2 calculates the average of realtime update prices using a varip array.
— Part 3 presents a function to calculate the up/down/neutral volume by looking at price and volume variations between realtime bar updates.
Something we could not do in Pine before varip was to time the duration for which a condition is continuously true in the realtime bar. This was not possible because we could not save the beginning time of the first occurrence of the true condition.
One use case for this is a strategy where the system modeler wants to exit before the end of the realtime bar, but only if the exit condition occurs for a specific amount of time. One can thus design a strategy running on a 1H timeframe but able to exit if the exit condition persists for 15 minutes, for example. REMINDER: Using such logic in strategies will make backtesting their complete logic impossible, and backtest results useless, as historical behavior will not match the strategy's behavior in realtime, just as using `calc_on_every_tick = true` will do. Using `calc_on_every_tick = true` is necessary, by the way, when using varip in a strategy, as you want the strategy to run like a study in realtime, i.e., executing on each price or volume update.
Our script presents an `f_secondsSince(_cond, _resetCond)` function to calculate the time for which a condition is continuously true during, or even across multiple realtime bars. It only works in realtime. The abundant comments in the script hopefully provide enough information to understand the details of what it's doing. If you have questions, feel free to ask in the Comments section.
Features
The script's inputs allow you to:
• Specify the number of seconds the tested conditions must last before an alert is triggered (the default is 20 seconds).
• Determine if you want the duration to reset on new realtime bars.
• Require the direction of alerts (up or down) to alternate, which minimizes the number of alerts the script generates.
The inputs showcase the new `tooltip` parameter, which allows additional information to be displayed for each input by hovering over the "i" icon next to it.
The script only displays useful information on realtime bars. This information includes:
• The MA against which the current price is compared to determine the bull or bear conditions.
• A dash which prints on the chart when the bull or bear condition is true.
• An up or down triangle that prints when an alert is generated. The triangle will only appear on the update where the alert is triggered,
and unless that happens to be on the last execution of the realtime bar, it will not persist on the chart.
• The log of all triggered alerts to the right of the realtime bar.
• A gray square on top of the elapsed realtime bars where one or more alerts were generated. The square's tooltip displays the alert log for that bar.
• A yellow dot corresponding to the average price of all realtime bar updates, which is calculated using a varip array in "Part 2" of the script.
• Various key values in the Data Window for each parts of the script.
Note that the directional volume information calculated in Part 3 of the script is not plotted on the chart—only in the Data Window.
Using the script
You can try running the script on an open market with a 30sec timeframe. Because the default settings reset the duration on new realtime bars and require a 20 second delay, a reasonable amount of alerts will trigger.
Creating an alert on the script
You can create a script alert on the script. Keep in mind that when you create an alert from this script, the duration calculated by the instance of the script running the alert will not necessarily match that of the instance running on your chart, as both started their calculations at different times. Note that we use alert.freq_all in our alert() calls, so that alerts will trigger on all instances where the associated condition is met. If your alert is being paused because it reaches the maximum of 15 triggers in 3 minutes, you can configure the script's inputs so that up/down alerts must alternate. Also keep in mind that alerts run a distinct instance of your script on different servers, so discrepancies between the behavior of scripts running on charts and alerts can occur, especially if they trigger very often.
Challenges
Events detected in realtime using variables declared with varip can be transient and not leave visible traces at the close of the realtime bar, as is the case with our script, which can trigger multiple alerts during the same realtime bar, when the script's inputs allow for this. In such cases, elapsed realtime bars will be of no use in detecting past realtime bar events unless dedicated code is used to save traces of events, as we do with our alert log in this script, which we display as a tooltip on elapsed realtime bars.
█ NOTES
Realtime updates
We have no control over when realtime updates occur. A realtime bar can open, and then no realtime updates can occur until the open of the next realtime bar. The time between updates can vary considerably.
Past values
There is no mechanism to refer to past values of a varip variable across realtime executions in the same bar. Using the history-referencing operator will, as usual, return the variable's committed value on previous bars. If you want to preserve past values of a varip variable, they must be saved in other variables or in an array .
Resetting variables
Because varip variables not only preserve their values across realtime updates, but also across bars, you will typically need to plan conditions that will at some point reset their values to a known state. Testing on barstate.isnew , as we do, is a good way to achieve that.
Repainting
The fact that a script uses varip does not make it necessarily repainting. A script could conceivably use varip to calculate values saved when the realtime bar closes, and then use confirmed values of those calculations from the previous bar to trigger alerts or display plots, avoiding repaint.
timenow resolution
Although the variable is expressed in milliseconds it has an actual resolution of seconds, so it only increments in multiples of 1000 milliseconds.
Warn script users
When using varip to implement logic that cannot be replicated on historical bars, it's really important to explain this to traders in published script descriptions, even if you publish open-source. Remember that most TradingViewers do not know Pine.
New Pine features used in this script
This script uses three new Pine features:
• varip
• The `tooltip` parameter in input() .
• The new += assignment operator. See these also: -= , *= , /= and %= .
Example scripts
These are other scripts by PineCoders that use varip :
• Tick Delta Volume , by RicadoSantos .
• Tick Chart and Volume Info from Lower Time Frames by LonesomeTheBlue .
Thanks
Thanks to the PineCoders who helped improve this publication—especially to bmistiaen .
Look first. Then leap.
Volume Info from Lower Time FramesHello Traders,
We are now able to get info from lower time frames, Many Thanks to Pine Team .This script gets volume info from lower time frames and give alert if there is extreme volumes on last X lower time frame candles (if last X volumes are higher than volume moving average). so that if you set alerts on different securities then you will be able get alert if there is extreme volume moves and you can check the chart immediately.
The options:
Timeframe in Seconds : you can set lower time frames in seconds. by default it's 5 seconds. if you set it 60 then it will show 1min volumes, if you set it 1 then it will show 1 seconds volumes
MA Length : The script draws simple moving average using this length info. by default it's 20.
Number of Bars to Check for Alert : by default it's 5. meaning that if last 5 candles is greater than moving average and if you set alert then you get the alert "Extreme Volume"
Other options are for colors and line width.
As you can see in following example, chart time frame is 1 hour and the script shows volume info of 5 seconds candles:
Enjoy!
