S5) Structuring Time

Polymetry, Silences, Speed

Braces, Periods, Three Silences, and the Two Philosophies of Time

Musical time is not a line — it’s a network. BPscript inherits from BP3 the tools to describe it: superimposing flows, dividing into periods, playing with speed, and choosing between the measured time of the metronome and the free time of the ālāp.

Where does this article fit in?

After types (S3) and backticks (S4), we delve into an area where BPscript is particularly well-equipped: structuring time. This is the core of the BP3 legacy. This article assumes familiarity with the concept of polymetry — for an introduction, see B5.

Braces `{}`: Polymetry and Grouping

Music often has several things happening at once — a melody and a rhythm — or motifs that one wants to treat as a whole. Braces serve this purpose, and they have two roles depending on whether a comma is included:

Polymetry — Multiple Simultaneous Voices

S -> { melodie, rythme }

The comma , separates the voices. Each voice has its own duration — the BP3 engine calculates the least common multiple (LCM) to synchronize them. This is polymetry in the strong sense: duration ratios can be irrational (B5).

Temporal Grouping — A Single Voice

S -> A {B C D} E F

Without a comma, braces group symbols into a single temporal unit. The group {B C D} occupies the same duration as a simple symbol. A qualifier can be applied to it:

S -> A {B C D}[speed:2] E F      // B C D played at double speed

The Periodic Notation `.`

How do you get three groups of the same duration without manually calculating “this group is 1/3, that one is 1/3…”? This is the role of the dot .: it divides a sequence into fragments of equal symbolic duration.

S -> A B . C D . E F              // 3 fragments of equal duration

Each fragment between the . occupies the same time. This is a fundamental BP3 mechanism for building proportional structures without manually calculating durations.

Combinable with polymetry:

S -> { A B . C D, E F G }        // voice 1: 2 fragments, voice 2: 3 symbols

The . and , are two sides of the same BP3 expansion mechanism — they are passed as-is to the engine.

The Three Silences

BPscript distinguishes three ways to express the absence of sound:

Symbol	Name	Duration	Effect
`-`	silence	context-dependent	absence of event, occupies time
`_`	prolongation	extends previous event	sound continues, no new attack
`...`	indeterminate rest	calculated by engine	PolyMake finds optimal duration

The distinction is crucial. Compare:

Sa - Re          // silence between Sa and Re — two sounds separated by emptiness
Sa _ Re          // Sa lasts 2 positions — a single prolonged sound, then Re
Sa ... Re        // the engine calculates the rest duration to balance the voices

The indeterminate rest ... is the most subtle: in a polymetric context, the BP3 engine (via the PolyMake algorithm — see B13) calculates the duration that produces the simplest temporal structure. The composer writes the minimum, the engine does the rest:

S -> { A B C ..., D E F G }      // the ... compensates for the length difference

This is the notation closest to what a human musician would expect: one specifies the structure, not the timing details.

Speed: `[speed:]` on a Group and Duration Operators

Two distinct mechanisms control speed, and they do not compile in the same way.

`[speed:N]` on a Polymetric Group → Ratio

On a group {}, [speed:N] expresses a polymetric tempo ratio. In BP3, this ratio is placed in the first position within the braces:

BPscript	Compiled BP3
`{A B}[speed:2]`	`{2, A B}`
`{A B}[speed:1/2]`	`{1/2, A B}`
`{mi fa sol}[speed:2/3]`	`{2/3, mi fa sol}`

The compiler translates {...}[speed:N] → {N, ...}. No implicit ratio in BPscript: everything goes through [speed:].

Duration Operators `[/N]`, `[\N]`, `[*N]`, `[**N]` → Encapsulating Pair

On a symbol or group, BP3’s temporal operators are directly exposed and compile into an encapsulating pair of _tempo() (BP3’s tempo change instruction):

BPscript	Compiled BP3	Effect
`A[/2]`	`_tempo(2/1) A _tempo(1/2)`	doubles the speed of A
`A[*2]`	`_tempo(1/2) A _tempo(2/1)`	divides the speed of A by 2
`{A B}[/2]`	`_tempo(2/1) {A B} _tempo(1/2)`	group at double speed, local scope

The encapsulating pair ensures that the effect is local: the tempo is restored after the element. This is the essential difference from the polymetric ratio of [speed:], which is a structural property of the {} block.

S -> A {B C D}[speed:2] E F
// B C D played at double speed via the polymetric ratio, A and E at normal speed

Element Controls: `[]` Engine vs `()` Runtime

BPscript distinguishes two types of controls, with two syntaxes:

`[]` — Engine Instructions (BP3)

Square brackets [] carry instructions for the BP3 engine. They apply to symbols, groups, and rules. On an element of the RHS, [] is always written as a suffix: attached to the right of the element it qualifies (without a space).

A[/2]                            // symbol: duration operator, as suffix
{A B C}[speed:2]                 // group: polymetric ratio
S -> A B C [weight:3]            // rule: weight 3 (at end of rule)

The reserved language keywords in [] are: the duration operators /N, \N, *N, **N, as well as mode, scan, weight, speed, on_fail, tempo, meter, scale. Any other language keyword in [] is an error.

Other words (retro, rotate, keyxpand, striated, smooth, stop, goto…) are engine controls provided by the @controls library, not reserved language keywords themselves. They exist because the library defines them, not because BPscript knows them. The complete list of language keywords is in S12.

`()` — Runtime Parameters (Transport/REPL)

Parentheses () carry parameters intended for the runtime — BPscript does not interpret them, it transports them. Three scopes (always as a suffix):

Sa(vel:120)                      // symbol: vel=120 for this note
{A B C}(vel:80)                  // group: vel=80 for the entire group
S -> A B (vel:120)               // rule: vel=120 for the entire phrase

The compiler translates runtime parameters into _script(CTn) tokens — opaque references to a separately maintained control table:

BPscript	Compiled BP3
`Sa(vel:120)`	`Sa _script(CT0)` (CT0 = vel:120)
`S -> A B (vel:120)`	`_script(CT1) A B` (rule scope)

The []/() distinction is fundamental: [] changes the engine’s behavior (speed, weight, mode), () changes the runtime’s rendering (velocity, pan, instrument).

Derivation Types

BP3 offers several strategies for choosing which rule to apply when a non-terminal (a symbol that can be rewritten) has multiple candidate rules. In BPscript, the derivation type is declared as a block directive via @mode:X — it applies to the entire sub-grammar that follows:

Type	Full Name	Behavior
`ord`	Ordered	Rules are applied in declaration order (top to bottom)
`random`	Random	A rule is chosen randomly from candidates, weighted by their weights
`lin`	Linear (leftmost)	Random choice among rules applicable to the leftmost non-terminal
`sub1`	Substitute first	Substitution of the first occurrence of the non-terminal only
`sub`	Substitute all	Simultaneous substitution of all occurrences
`tem`	Templates	Matching via the TEMPLATES block
`poslong`	Positional longest	Like `sub1`, but selects the longest derivation

@mode:random                     // all rules below are in random mode

S -> A B C                       // weighted random choice
S -> D E F                       // same — same sub-grammar

-----                            // sub-grammar separator

@mode:ord                        // the following rules are in ordered mode
A -> Sa Re Ga
A -> Pa Dha Ni

The @mode:X persists until the next mode change. random mode is the most common in composition: it produces unpredictable variations, controlled by weights (B4). Details of each mode are in B3.

Scan Direction

Distinct from the derivation type, the scan direction sets the direction in which the engine searches, in the current string (BP3’s work string), for the next symbol to rewrite — thus which occurrence is chosen when several are suitable:

Direction	Qualifier	Effect
LEFT	`[scan:left]`	Searches for the symbol to rewrite from left to right
RIGHT	`[scan:right]`	Searches from right to left
RND	`[scan:rnd]`	Searches in a random order (default)

S -> A B C [scan:right]          // this rule scans from right to left

The scan direction is a qualifier per rule ([scan:X]), while the derivation type is a directive per sub-grammar (@mode:X). The two are orthogonal. The default, if no [scan:] is specified, is rnd.

Three Directions

The derivation arrow indicates the direction:

S -> A B C                       // production — when the engine generates
S <- A B C                       // analysis — when the engine recognizes (right → left)
S <> A B C                       // bidirectional — valid in both phases

The -> direction is the most common: the non-terminal on the left rewrites to the sequence on the right (production). <- corresponds to the direction of analysis, when the engine recognizes a given sequence. <> is bidirectional: the rule is valid in both generation and analysis.

Striated Time and Smooth Time

Pierre Boulez, in Penser la musique aujourd’hui (1963), distinguishes two textures of time using a textile image: a striated fabric is crossed by regular lines (a pulse), a smooth felt is homogeneous, without a grid.

Striated Time: counted time. A pulse divides time into units; durations are positions on this grid. This is the time of the metronome, of dance, of most Western music.
Smooth Time: uncounted time. No reference grid; durations are properties inherent to the sound objects themselves. This is the time of the ālāp (slow, unmeasured introduction to an Indian raga), of the drone, of free improvisation.

Warning: striated/smooth is not the discrete/continuous distinction of signal processing. Both regimes use the same rational arithmetic; what changes is the source of the duration — the grid (striated) or the object itself (smooth). See B12.

BP3 implements both regimes: _striated (the default) places events on a pulse grid; _smooth assigns each object its own duration (via time patterns). In BPscript, one switches between them with the striated / smooth controls (@controls library).

Beyond the regime, B12 identifies two ways to act on the temporal flow: time as an object property — smooth time, which BPscript finds in the cv type (a CV object carries its own duration — see S3) — and time as an instruction inserted into the flow — BP3’s _tempo() operator, exposed in BPscript by [/N], [*N]… seen above.

Tempo: Three Levels

BPscript distinguishes three levels of tempo control, provided by the @controls library:

Control	Syntax	Effect
Relative Multiplier	`[tempo:2]`	Doubles the current speed
Absolute Metronomic Marking	`@mm:120`	120 BPM (beats per minute)
Striated/Smooth Toggle	`striated` / `smooth`	Changes the temporal mode

@controls                        // import performance controls
@mm:120

S -> A B [tempo:2] C D           // C and D at double speed (relative)

[tempo:2] is a reserved language keyword. The striated/smooth toggles are controls from the @controls library. These three levels correspond to the concepts explored in B12.

Key Takeaways

{} = polymetry (with ,) or grouping (without ,)
. = periodic notation — fragments of equal duration
Three silences: - (empty), _ (prolongation), ... (engine-calculated rest)
[speed:N] on a group = polymetric ratio {N, ...} ; [/N], [*N] = duration operators (encapsulating _tempo pair)
7 derivation types (ord, random, lin, sub1, sub, tem, poslong) via @mode:X per sub-grammar + 3 scan directions (left, right, rnd — default rnd) via [scan:X] per rule
3 directions: -> (left→right), <- (right→left), <> (bidirectional)
Two times: striated (durations = positions on a grid, _striated) and smooth (durations = object properties, _smooth) — distinct from discrete/continuous

Glossary

Polymetry: Superposition of voices with potentially different durations, synchronized by the LCM
Periodic notation: notation using . to divide a sequence into fragments of equal symbolic duration
Prolongation: Symbol _ that extends the duration of the previous sound without a new attack
Indeterminate rest: Symbol ... whose duration is calculated by the BP3 engine (PolyMake algorithm)
Polymetric ratio: Factor [speed:N] that places a tempo ratio at the beginning of a {} block (compiled {N, ...})
Derivation mode: Strategy for choosing a rule when a non-terminal has multiple candidate rules (ord, random, lin…)
Striated time: counted time, where durations are positions on a pulse grid (_striated, default in BP3) — Boulez 1963
Smooth time: uncounted time, where durations are properties inherent to the objects, without a grid (_smooth) — Boulez 1963; not to be confused with signal continuity
Ālāp: Slow, unmeasured introduction to an Indian raga — a paradigmatic example of smooth time
LCM: Least Common Multiple — used by BP3 to synchronize polymetric voices

Links in the Series

S2 — Temporal symbols (-, _, …, .)
S3 — The CV type and the question “who interpolates?”
S6 (coming soon) — Flags and modes — how conditions interact with derivation
S8 — Patterns, captures, and templates
B5 — Polymetry in BP3 — foundations
B12 — The three times of BP3 — symbolic, striated, physical time
B13 — PolyMake — the polymetric expansion algorithm

Prerequisites: S2, B5
Reading time: 14 min
Tags: #BPscript #polymetry #time #silence #Boulez #BP3

Next article: S6 (coming soon) — Composing with conditions: flags and traversals

← Back to index