Karya, built on Sun Nov 26 01:04:37 PST 2017 (patch 0a920b2bde70c0cbac8ee09d158064798b61bbe5)

Safe HaskellNone




RealTime represents seconds, as opposed to ScoreTime, which are abstract units. Everything eventually is transformed into RealTime to be performed.

This type has switched from floating point to decimal and back again. The problem is that floating point is not exact, but there are a few operations that require events that have the same ScoreTime to be grouped with each other once they reach RealTime. For instance, controls are clipped to the note boundaries, and a note is required to have a pitch at exactly its starting time. While the event that produces the pitch signal may have the same ScoreTime as the note it belongs to, if imprecision has caused it to drift a little by the time it gets to performance, the note may wind up with no initial pitch, or pick up the pitch of the next note as a pitch bend.

An example of how imprecision can accumulate is a block call with pitch set in the caller. If the sub-block has a note at 0 this should line up with the start of the block call in the super-block and hence with a pitch at the same time. But the sub-block has its own warp which is a composition of the its tempo and the super-block's tempo. In theory the sub-block's warp should be shifted so its 0 starts at the calling point in the super-block, but in practice this is a number of floating point operations (addition, linear interpolation, ...) and the value may very well be slightly different.

Unfortunately switching RealTime to a lower-precision decimal type has the same problem because it introduces even more imprecision due to the ScoreTime -> RealTime -> ScoreTime conversion (this happens during warp composition, for instance, since shift and stretch are in ScoreTime). And I think it's ultimately not quite right because rounding will still produce incorrect results if the imprecise value falls at a rounding boundary.

Eventually, for MIDI at least, everything is rounded down to milliseconds so hopefully any imprecision can be accounted for by the operations that care about it and eventually be removed from the final result.



data RealTime Source #

A concrete unit of time.

This must have negative values because it's used for signals, which are used for the warp map, which is oriented with zero at the note start. If a note wants to get the real time before it, it must look up a negative RealTime.


Eq RealTime # 
Fractional RealTime # 
Num RealTime # 
Ord RealTime # 
Read.Read RealTime # 
Real RealTime # 
RealFrac RealTime # 


properFraction :: Integral b => RealTime -> (b, RealTime) #

truncate :: Integral b => RealTime -> b #

round :: Integral b => RealTime -> b #

ceiling :: Integral b => RealTime -> b #

floor :: Integral b => RealTime -> b #

Show RealTime # 
Storable RealTime # 
DeepSeq.NFData RealTime # 


rnf :: RealTime -> () #

CRC32.CRC32 RealTime # 
ToJSON RealTime # 
FromJSON RealTime # 
Pretty RealTime # 
C.CStorable RealTime # 
ApproxEq.ApproxEq RealTime # 


eq :: Double -> RealTime -> RealTime -> Bool Source #

Serialize.Serialize RealTime # 
ShowVal.ShowVal RealTime # 
ToVal RealTime # 


to_val :: RealTime -> Val Source #

Time RealTime # 
TypecheckNum RealTime # 
ToVal RealTime # 


to_val :: RealTime -> Val Source #

Typecheck RealTime # 
Typecheck Function # 
Typecheck TypedFunction # 

div :: RealTime -> Double -> RealTime infixl 7 Source #

mul :: RealTime -> Double -> RealTime infixl 7 Source #

large :: RealTime Source #

A large RealTime that is also not the max bound so it won't overflow too easily, and will also fit in a Signal.Y.

show_units :: RealTime -> Text Source #

Show RealTime as hours, minutes, seconds.

convert from

convert to


eta :: RealTime Source #

Eta for comparison. Since RealTimes are seconds, this amount of time is definitely unnoticeable.

(==) :: RealTime -> RealTime -> Bool Source #

RealTimes are imprecise, so compare them with this instead of (==).