Karya, built on Mon Jul 24 11:39:07 PDT 2017 (patch 33511aca01257b76b88de7c7a2763b7a965c084e)

Safe HaskellNone

Ui.ScoreTime

Synopsis

Documentation

data ScoreTime Source #

Score time is the abstract unit of time, and its mapping to real time is dependent on the score context. ScoreTime units can be negative, but blocks only display events at >=0 ScoreTime.

Instances

Eq ScoreTime # 
Fractional ScoreTime # 
Num ScoreTime # 
Ord ScoreTime # 
Read.Read ScoreTime # 
Real ScoreTime # 
RealFrac ScoreTime # 
Show ScoreTime # 
DeepSeq.NFData ScoreTime # 

Methods

rnf :: ScoreTime -> () #

CRC32.CRC32 ScoreTime # 
Pretty ScoreTime # 
C.CStorable ScoreTime # 
ApproxEq.ApproxEq ScoreTime # 

Methods

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

Serialize.Serialize ScoreTime # 
ShowVal.ShowVal ScoreTime # 
ToVal ScoreTime # 

Methods

to_val :: ScoreTime -> Val Source #

Time ScoreTime # 
TypecheckNum ScoreTime # 
ToVal ScoreTime # 

Methods

to_val :: ScoreTime -> Val Source #

Typecheck ScoreTime # 

type TrackTime = ScoreTime Source #

This is also ScoreTime, but it's relative to the beginning of the track. I.e., UI events are all in track time, but when they get shifted and stretched as by note slicing they're no longer in TrackTime, but not yet in RealTime.

I'd like to make a type-level distinction because it's easy to get confused about whether a time has or hasn't been transformed, but when I tried it seemed like a big hassle since I'd really like for TrackTime to be a subtype of ScoreTime. I could do it with a phantom type, but it would change about a million type declarations. And since Events start in TrackTime but are then ScoreTime if transformed, they would also need a type parameter, along with probably a few other basic data types.

Unless I work up the courage to do that someday, the least I can do is document the difference with a type synonym.

round :: ScoreTime -> ScoreTime Source #

Traditionally, time would be an integral type with a highly composite number as the unit. This is so that common musical durations such as 1/3, 16, or 164 can be represented exactly. However, while this is good enough for the score, it's insufficiently accurate for derivation, which uses ScoreTime to shift and stretch events.

A principled solution would probably be to use an integral type for UI events in Events.Events and convert to floating point on derivation. However, that seems like a hassle and simply rounding the event's start and durations when they go into the track should achieve the same effect.

suffix :: Char Source #

t is for time, since RealTime uses s for seconds

eta :: ScoreTime Source #

Eta for comparison. ScoreTimes are all relative, but there's no reason to use such tiny ones.

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

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

(>) :: ScoreTime -> ScoreTime -> Bool Source #

True if the second is greater than the first - eta. This can be used to determine if the start of an event has passed, while giving a little bit of extra allowance if its close enough.

(<=) :: ScoreTime -> ScoreTime -> Bool Source #

True if the second is greater than the first - eta. This can be used to determine if the start of an event has passed, while giving a little bit of extra allowance if its close enough.

is_negative :: ScoreTime -> Bool Source #

Unlike <0, this counts -0 as negative.