I am looking for an experienced Trading View Pine Script developer to professionally rebuild, optimize, debug, and expand an existing Section-Based Pivot Point + CPR (Central Pivot Range) indicator written in Pine Script v6.
This is NOT a beginner-level bug-fix project.
The current script already works partially, but it has major architectural, logical, scalability, performance, and section-handling issues that need to be professionally resolved.
The goal is to transform the current prototype into a professional-grade, scalable, accurate, optimized, maintainable, and future-proof Trading View indicator.
Current Indicator Features
The current indicator includes:
The script currently supports:
Section 00
Section 01
Section 02
Section 03
I now require:
The system should be redesigned so additional sections can be added dynamically in the future without duplicating large sections of code.
Developing CPR Workflow
The indicator operates using a section-to-next-section projection model.
Example workflow:
When a section begins, the indicator starts tracking that section's evolving OHLC values.
Using the developing High, Low, Open, and latest Close, the indicator continuously calculates a developing CPR (PP, BC, and TC).
This developing CPR is projected forward into the next section.
As new candles form, the High, Low, and Close may change, causing the projected CPR to update in real time.
When the active section closes, its final OHLC values become locked and the CPR becomes finalized.
The finalized CPR remains fixed historically.
The next section then becomes active and follows the same process, projecting its developing CPR into the following section.
This workflow continues sequentially across all configured sections.
The developer must preserve this section-to-next-section projection architecture while improving stability, performance, replay compatibility, scalability, and visual consistency.
Current Problems & Issues (Must Be Solved)
1. Massive Code Duplication
The current script manually duplicates logic for every section.
The following logic is duplicated multiple times:
OHLC tracking
CPR calculations
Developing CPR logic
Historical plotting
Object deletion
Labels
Line creation
This creates:
The architecture should be rebuilt using:
Reusable functions
Arrays
Generic section engine
Modular design
Scalable data structures
2. No Generic Section Engine
The current system is fully hardcoded.
I want:
The final architecture should support adding/removing sections easily.
3. Developing CPR Logic Is Unstable
The current projected CPR recalculates every candle using:
Current evolving High
Current evolving Low
Current Close
This creates:
Need:
Stable developing CPR logic
Optional locked/non-repainting mode
Optional live-developing mode
4. Repainting-Style Visual Behavior
Although historical values may not technically repaint, CPR lines move constantly during section development.
Need:
Stable visual rendering
Smoother CPR updates
Proper state handling
5. Timeframe Compatibility Problems
Primary supported timeframes:
1 Minute
3 Minute
5 Minute
15 Minute
30 Minute
1 Hour
4 Hour
Higher timeframes should either:
6. Section Overlap Problems
Need:
Overlap validation
Duplicate section detection
Invalid section detection
Configuration validation system
7. Cross-Midnight Section Issues
The system must correctly handle sections that cross midnight.
Need robust handling for:
8. No DST Handling
Need:
DST-safe section handling
Robust time zone architecture
Consistent timing behavior
9. Object Limit & Performance Problems
Current script creates excessive:
Lines
Labels
Historical objects
Need:
Object recycling
Optimized rendering
Reduced object creation
Efficient cleanup logic
10. Cleanup Logic Is Incorrect
Need:
11. CPR Raw Calculation Handling
I do NOT want automatic TC/BC normalization.
The indicator must:
Calculate CPR values exactly as produced by the market
Preserve raw calculations
Allow BC above TC when raw calculations produce that result
No forced normalization should occur.
12. No Separation Between Calculation & Rendering
Need:
Separate calculation engine
Separate rendering engine
Separate section state management
Modular architecture
13. No Object Recycling
Current logic constantly creates and destroys objects.
Need:
Reusable lines
Reusable labels
Efficient updating
14. Replay Mode Problems
Need full replay compatibility.
All calculations, labels, CPR values, historical plots, developing projections, and finalized CPR levels should behave identically in both Live Charts and Trading View Replay Mode.
15. Mobile & Visual Clutter Problems
Need:
16. No Market-Type Awareness (Make it Optional)
The indicator should function correctly across:
Forex
Crypto
Indices
Futures
Gold/XAUUSD
17. Poor Scalability
Current architecture becomes increasingly difficult to maintain as features expand.
Need:
18. Add One Additional Section
The current script supports four sections.
I require support for:
This section must support:
The architecture should support future expansion beyond five sections.
Core Architecture Requirement
The indicator must be built around a generic section-based framework.
The addition of new sections should require only configuration changes rather than structural code changes.
Future expansion should not require duplicating major portions of code or rebuilding core logic.
The final architecture should support scalable growth while maintaining performance, readability, maintainability, and consistency.
Expected Deliverables
Fully refactored Pine Script v6 code
Modular architecture
Optimized performance
Replay-compatible behavior
Generic section engine
Dynamic section handling
Stable CPR calculations
Improved UI/UX
Object recycling system
Inline code documentation
Final tested and production-ready script
If you have experience building advanced Trading View indicators with scalable architecture, state management, performance optimization, and non-repainting logic, I would be interested in discussing the project further.
=====================================REMEMBER=========================================
CPR Calculation Consistency Requirement
The current indicator's CPR Historical calculation logic is considered correct and must be preserved.
During the rebuild process, the developer must ensure that all historical CPR calculations generated by the new architecture match the existing indicator's CPR values exactly.
This includes:
Pivot Point (PP)
Bottom Central (BC)
Top Central (TC)
The refactored indicator must produce identical CPR values to the current indicator when using the same historical data and section configuration.
The purpose of this project is to improve architecture, scalability, maintainability, performance, replay compatibility, and rendering behavior—not to alter the underlying CPR calculation methodology.
Before final delivery, the developer should verify that historical CPR values from the new version align with the existing indicator and that PP, BC, and TC levels are plotted at the same price levels as the current implementation.
...
Show more