jsbean / timeline Goto Github PK

Define an interface for objects that can perform closures rapidly at (as-)even(-as-possible) intervals.

protocol Timer {
    init(interval: Double, advance: () -> ())
    func start()
    func stop()
}

This could be Timer, DispatchSourceTimer, or perhaps something done in the audio realm (counting samples in buffers at a sampling rate).

Add contents of timeline to self.

It would be nice to be able to create local timeline, then merge it into another one.

Currently,

timeline.add(at:body:)

but, it should be:

timeline.add(at:action:)

Use configuration in dn-m/ArithmeticTools.

To ensure greater accuracy, the internal modeling of currentFrame became something calculated from the secondsElapsed instance property, as opposed to something which was manually incremented.

This disabled the deterministic behavior in the Frames domain (useful when testing the pause method), but without the potential for drift.

Update .gitignore to this.

In usage:

timeline.playbackRate = 1.25 // 25% faster

Will require adding:

extension Timeline {
    public var playbackRate: Double {
        didSet {
            // regenerate Timer
            // update position model (TODO: implement position model)
        }
    } 
}

Internally, propagate identifier of Timeline to Action, enabling the filtering of actions by their parent Timeline.

We currently use Timer.sheduledTimer(timerInterval:target:selector:userInfo:repeats:), which has objc all over it.

Transfer to this API, which looks like it won't require @objc-declared selector.

git rm -r --cached Carthage/Checkouts

Currently, looping actions are just added to the schedule. They are also not purged upon stop(), which means they will keep popping up, leading to things blowing up!

Create model for events that happen before the start of the timeline.

Currently, we are using:

typealias Action = () -> ()
protocol ActionType { } 
struct AtomicAction { }
struct LoopingAction { }

Where, ActionType structs contain an Action, wrapped with either an offset time stamp or looping interval.

The naming doesn't seem to appropriately convey the graph of relationships.

Define an interface for storing closures to be performed at given offsets.

protocol Schedule {
    mutating func add(_ action: Action, at: Frames)
    mutating func removeAll(identifier: String)
}

Create a richer model of duration spanning events, and therefore gaps between.

This will enable a more streamlined approach to generating ProgressBar actions when one has no events.

Make Timeline merely a protocol. Then, implement a default timeline given a certain Timer API.

There may be instances of properties here that were converted to fileprivate when they can maintain their private status.

The calculation from Tempo to the time interval is incorrect.

Currently, the model of the events in the timeline and the execution of this model are entangled.

This has made it so the refinement of accuracy in the timing has muddied up the model (and therefore breaking the pause functionality).

Break these apart.

Define an interface for objects that can measure time accurately. Keeps the Timer in check, avoids drift.

protocol Clock {
    static var now: Seconds { get }
    var elapsed: Seconds { get }
    func start()
}

To remove events with a given identifier:

E.g.,

timeline.removeActions(identifier: "autoPlay")
timeline.removeActions(identifier: "metronome")

We are using the Foundation Timer API, which is not super accurate:

Because of the various input sources a typical run loop manages, the effective resolution of the time interval for a timer is limited to on the order of 50-100 milliseconds.

More importantly, it drifts. In an initial implementation, I was counteracting the drift by continuously checking against CACurrentMediaTime(). At some point, this was reverted, and currentFrame is merely incremented during the internal advance() method.

We need to implement a check against the current time at the beginning of the advance() method, then calculate and set the currentFrame at that point.

Related, look into using the DispatchTime API rather than having a CoreGraphics dependency.

Currently, actions (() -> ()) are stored by UInt keys. When iterating over the registry, the events are in the order in which they were added, but not ordered by time.

Implement OrderedDictionary from DictionaryTools.

First, conform OrderedDictionary to CollectionType protocol.

This will relieve a dependency on QuartzCore.