path: root/DEVLOG.md

# Development log

# November 19th, 2025

## Rhythm

Developing a theory of rhythm for unheard.

There is a natural tension between relative and
absolute positioning of time objects in time.

Let me try to define relative positioning.

Absolute positioning is positioning a time object at an absolute
location on a timeline. For example, an absolutely positioned
time object might span [1 4]. Part of the definition might include
the constraint that the position of absolutely-positioned
time objects is known at compile time.

A relatively positioned time object is positioned relative to some
other entity (a container or another time object, for example).
A time object is relatively positioned if the related entity's
position is not known at compile time.

Maybe a more interesting differentiation is time objects that
are known to exist at compile time vs time objects that are not.

Relative positioning makes the following challenging:
 - 

Relative positioning makes seeking challenging, since you have
to play through the timeline to get to an event. It is also
not obviously clear how temporal indexing would work with

Absolute positioning is substantially less flexible. How do
loops work 

I think this is probably one of the hardest pieces for me to get right. I'll be doing a lot of writing to help me better understand the problem space. Here are some of my high-level goals:

 - A composer should be able to decompose their composition into phrases, just like a programmer can decompose a program into functions. (Hint: phrases are functions!) A composer should be able to work on a phrase in isolation, at times iterating upon it without regard for the entire composition. At other times, it should be easy for the composer to hear a phrase in concert with other phrases.
 - It should be intuitive for a composer to write a piece that changes between time signatures.
 - It should be intuitive for a composer to express polyrhythms.
 - The playback engine should provide affordances for starting loops or phrases at the next downbeat. This interacts with the polyrhythm constraint in various ways. Regardless, I want to minimize surprise.
 - Seeking (that is, jumping to a point in a composition) should be instantaneous. This has far-reaching consequences: in particular, it precludes certain kinds of iterative composition, where state t2 = f(state t1).
 - Looping should be easy and flexible. Note, though, that the ban on iterative composition imposed by the previous bullet point seems to imply that looping can't exist at all! Fortunately, I have some theories for how to resolve this conflict. They need to be worked through, though.
 - It should be possible to slow down the tempo of a song to (nearly) arbitrarily small values. Same for speeding up. This would allow for some kind of rhythmic fractals, where tempo slows down forever (while new subdivisions of tempo appear continuously). I've been looking into how "infinite zoom" fractal renderers represent zoom steps numerically, and hope to lift some of that into the playback engine.
 - Related to the above, I want to provide some kind of mechanism for expressing recursive rhythms – that is, a rhythm that plays concurrently at tempo t, 2t, 1/2t, 4 t, 1/4t, etc. (A composer would specify the number of iterations they want to play above and below t.) This mechanism would account for tempo zooming automatically.

As the theory of rhythm develops, I'll find that some of the above goals are fundamentally incompatible, so I'll have to make choices. That will be part of the fun.

## Key questions

 - The monotonic clock is ticking. That's cool. But what is the
 relationship between monotonic clock time and a note's actual input?
 That is, how does a clock (wall or pulse) query a note's presence?
 Especially when they are composed?
   
## Things I'm pretty sure about

 - Base unit should be a beat, and durations should be expressed
   as fractional beats (e.g. 1/4, 2/1).
 - Take a look at my "static" topology diagram, and consider that
   flows can bind to positions. Given that, maybe it is possible
   to have dynamic topologies. Put differently: As long as every
   dynamic topology input flow is continuously defined, then going
   "back in time" can mean "reversing the current state". This
   _DOES NOT_ mean reversing time, or even guarenteeing that what
   you play backward is the same as what you play forward.

What might happen when you hit play under this model?
You pass a flow into a player
The player sets time to init-time
The pulse clock starts pulsing

## Random notes

What is the "smallest time unit" that we want to represent?
We have to specify the number of "smallest time units" in a pulse.

I _think_ this is tightly tied to recursive zooming in. We can
specify durations as [128th notes, zoom level]
We increment zoom level when zooming in

We can set a "max frequency" for control information (say 100hz).
Then, our time-recursive function can short-circut any recursive objects
whose children have a minimum frequency that falls below the max frequency.
This will require that time objects emit min-frequency metadata,
which can be derived by finding the longest child.

This is a wild theory - test this tomorrow.

Actually, a better solution would be to just put the composer in control.
The composer should specify that they want n doublings or halvings of
a given phrase played concurrently.


## Solving for:

## Time signature changes
How does this interact with looping?

## Concurrent phrases with differing time signatures

It should be possible for concurrent time signatures to emit
their:
 - Offset
 - Numerator
 
They can be then merged together to create a data structure
containing lazy seqs of "beats" at each combination
Actually, just provide a function that takes offsets and numerators
and the "combination" that you're looking for, and returns
a lazy seq of beating indices

## Tick frequency

Monotonic clock frequency is tied to doubling or halving of tempo,
along with "discrete nyquist"

### Looping

What would it mean for each "phrase" to have its own derived timeline? 
(Maybe not literally a phrase, maybe some container designed for this).
and what would it mean if these phrases could have timeline offsets
that repeat?

### Jump back

Similar to a repeat in music theory. A timeline GOTO.

### Static repeat

Not actually a loop. This is calling a phrase again and again,
adding the phrase's length to the offset at each repetition.

## Phrase isolation
It should be easy to play a phrase by itself. In fact, it should be possible to
loop a phrase so yo can just hear it while you're working on it

Should create repl.play and repl.repeat:

(play phrase)
(play phrase 130)

(repeat phrase)
(repeat phrase 130)

(stop)

### Start a phrase at the next downbeat


### Start a phrase at the next polyrhythmic co-downbeat


### Abstract phrases away as functions


### Make seeking both easy to reason about and performant


### Sensible reverse playback (rolling a tempo from pos to neg)


### Express fractional notes sensibly

# November 20th, 2025

## Summary of yesterday's "theory of rhythm" noodling:

Must support:
 - Playing a phrase in isolation
 - Looping
 - Seeking
 - Time signatures and time signature changes
 - Coming in at the next downbeat
 
 Don't box out:
 - Polyrhythms
 - Unlimited slowing and speeding

 Looping means a few things:
 - Jumping back, identical to a repeat in music notation. Timeline goto.
 - Static repeat. That is, play phrase x n times. Note that this is is
   repeating, not looping. 

Insights:
 - Don't support iterative composition, where f(t2) = f(f(t1)).
   Iterative composition makes seek time linear with composition
   length. 
 - The monotonic clock frequency is closely related to the maximum
   number of events per second that we want to emit. 
 - Theoretically, infinite zoom could automatically derive the number
   of doublings and halvings to play by looking at the monotonic
   clock frequency and the longest event in a phrase. Doublings
   that would result in no event changes due to all events falling
   below the monotonic clock sampling rate could stop upward
   recursion. This seems complicated to implement in practice,
   but would technically work. (Think nyquist.)
 - Concurrent time signatures could emit their start offset and
   numerator. We could provide a function that takes offsets and
   numerators and returns a lazy seq of polyrhythmic downbeat
   positions.

Open questions:
Should base unit should be a beat, with durations based
as fractional units of a beat (e.g. 1/4, 4/1)? Or should base unit
account for time signature denominator? My hunch is that the internal
representation should be fractional beat, with helper functions that
convert current time signature to fractional beats.

## More brainstorming

Let me try to describe how the various decisions suggested above
could compose. I'll start at the end, and work backward.

You have a musical phrase representing your composition
or a part of it, and you want to play that phrase. The phrase
is a `timeline` object. The playback engine will query the
timeline object.

First,
you connect it to the playback engine:

```
(on-deck phrase input-map-f output-map-f)
```

`input-map-f` is a function that accepts the playback engine's available input
subsystems (initially just `{:midi midi-message-flow}`, but potentially
containing things like dmx and osc,) and returns a flow of a map wiring up the
input arguments of the composition.

Now, play the song:

```
(play 120)
```

`play` starts the clock, querying the timeline object as needed.

```
(pause)
```

`pause` pauses the piece.

```
(resume)
```

`resume` resumes the piece.

```
(play)
```

`play` with no arguments starts the piece from the beginning.

```
(loop)
```

`loop` with no args automatically resets the playback
position to the beginning at the end of the piece.

```
(loop start end)
```

This form of `loop` loops a segment of the composition.

(Aside: A pulse clock emits integers at the pulse rate. The
emitted integer represents the current _zoom level_.)

Open question: The playback engine queries the timeline at clock
positions. How does this relate to zoom levels? Is zoom level
part of the query?

### Random thoughts

Right now, phrases are eagerly composed together. This means that
if you redefine part of a piece, you have to redefine all of its
dependents, too. This might make interactive development annoying.