+\section{Options for what \texttt{Time} is a function of}
+
+I've been trying for a while with \texttt{Time} as a wall-clock
+`real-time' unit. This means that the following is tricky:
+
+\begin{enumerate}
+\item Add content at 29.97 fps
+\item Length of this content is converted to \texttt{Time} using the
+ current DCP frame rate (which will be 29.97).
+\item Add more content at 25 fps.
+\item This causes the DCP frame rate to be changed to 25 fps, and so
+ the first piece of content is now being run slower and so its length
+ changes.
+\end{enumerate}
+
+I think this is the cause of content being overlapped in this case.
+
+It is tempting to solve this by making Time a subdivision of DCP video
+frame rate. This makes things nicer in many ways; you get a 1:1
+mapping of content video frames to Time in most cases, but not when
+video frames are skipped to halve the frame rate, say. In this case
+you could have a piece of content at 50 fps which is some time $T$
+long at at DCP rate of 50 fps, but half as long at a DCP rate of 25 fps.
+
+I'm fairly sure that there is inherently not a nice representation which
+will obviate the need for things to be recalculated when DCP rate changes.
+
+On the plus side, lengths in \texttt{Time} are computed on-demand from
+lengths kept as source frames.
+
+
+\section{More musings}
+
+In version 2 things we changed, and a problem appeared. We have / had
+\texttt{ContentTime} which is a metric time type, and it is used to
+describe video content length (amongst other things). However if we
+load a set of TIFFs and then change the frame rate we don't have the
+length in frames i order to work out the new rate.
+
+This suggests that the content lengths, at least, should be described
+in frames. Then to get metric lengths you would need to specify a
+timecode.
+
+I will probably have to try a frame-based ContentTime and see what
+problems arise.
+