Bar types

Bar types

Overview

Custom candle aggregation. Turn a raw tick stream — or another bar series — into your own bars: tick, volume, range, Renko, Heikin-Ashi, or something proprietary, all from the public TradeStrike.Pipeline.Bars contracts.

Two pieces: a spec + a builder

Every custom bar type is two cooperating types: a description of what the bars are, and a worker that actually produces them. Keeping these apart is what lets the engine deduplicate work — the spec is a cheap, comparable identity that can be shared across many charts, while the builder is the stateful machine that only needs to run once per distinct spec. You implement both; the framework wires them together.

  • A BarSpecification subclass — an immutable, value-comparable identity record carrying the parameters (instrument id + your settings). Two charts asking for an identical spec share one builder and one output series.
  • A builder — either ITickBarBuilder (driven by raw Ticks) or IDerivedBarBuilder (driven by another series' bars). It accumulates input and emits closed Bar values.

Both live in the namespace TradeStrike.Pipeline.Bars (with Tick in TradeStrike.Pipeline.Ticks). Adding a new bar type is one record + one builder + one registration — no core framework changes.

How a bar series is built

The runtime never talks to your builder directly. It resolves the spec to a builder through an IBarBuilderFactory, feeds the builder its input, and collects the closed Bar values into an IBarSeries that indicators, strategies, and the chart read.

graph LR
  Spec[BarSpecification] -->|resolve| F[IBarBuilderFactory]
  F -->|Create| B[IBarBuilder]
  T[Tick / source bar] -->|OnTick / OnSourceBarClosed| B
  B -->|closed Bar values| S[IBarSeries]
  S --> C[Indicators · strategies · chart]

Built-in bar types

Before you write your own, it helps to see the shapes the framework already ships, because your custom type slots in beside them and obeys the same rules. The host's default factory registers everything below; each row is a spec record plus a builder that closes a bar on its own rule. Use this table as a menu of patterns — most proprietary bar types are a variation on one of these. Every spec record is declared in BarSpecification.cs.

Spec Closes when…
TimeBarSpec(id, Period) every Period elapses (e.g. 5 min, epoch-aligned).
TickBarSpec(id, Ticks) Ticks trades have accumulated.
VolumeBarSpec(id, Volume, OversizedTrades) traded volume reaches Volume.
RangeBarSpec(id, RangeTicks) price moves RangeTicks × tickSize from the open.
RenkoBarSpec(id, BrickTicks, WithWicks) price moves one brick (reversal = 2 bricks).
MedianRenkoBarSpec(id, BrickTicks, TrendThresholdTicks) continuation / reversal thresholds are crossed.
KagiBarSpec(id, ReversalTicks) price reverses ReversalTicks from the active extreme.
PointAndFigureBarSpec(id, BoxTicks, Reversal) a column completes (box + reversal rule).
LineBreakBarSpec(id, LineCount) price breaks the last LineCount lines' high/low.
HeikinAshiBarSpec(id, Underlying) derived: transforms any underlying spec's bars.

Which of these a chart may actually offer depends on the data provider — see availability probing. Specs persist to JSON through BarSpecificationCodec, also covered there.

Where to go next

The rest of this section walks the full lifecycle of a custom bar type, from the identity record through a worked tick builder, a multi-close range builder, a derived transform, and finally registration, seeding, and discovery. Read them in order for the complete picture, or jump straight to the pattern you need.

Page What it covers
The BarSpecification The immutable identity record, its built-in subtypes, and how to subclass it.
Builder interfaces IBarBuilder, ITickBarBuilder, IDerivedBarBuilder, the Bar struct, and the closedBars span.
A tick bar A complete SIMPLE tick-driven builder, end to end.
A range bar Closing several bars in one tick, with honest volume accounting.
A derived bar An ADVANCED transform over another series (Heikin-Ashi).
Registration & discovery Mapping a spec to its builder, seeding the live handoff, persistence, and availability.