Custom (non-standard) frame rates about timecodekit

[ryanfrancesconi]

this might not be super pertinent to this, but it did occur to me that there might be some limitations with keeping the definition of frame rate in an enum that requires these constant switch statements to get different properties. Another way to consider could be to make FrameRate more of an actual object. I'm sure you considered that approach as well, but it might make sense in regard to the custom frame rate based on a float. This was my sketch of your FrameRate with that in mind a few days ago when I was thinking about the floatValue problem:

struct FrameRate {
    // MARK: Internal

    internal var frameRateForElapsedFramesCalculation: Double
    internal var frameRateForRealTimeCalculation: Double
    internal var framesDroppedPerMinute: Double

    // MARK: Public

    public var frameRate: Timecode.FrameRate

    public var stringValue: String
    public var stringValueVerbose: String
    public var stringValueFileNameCompatible: String

    public var floatValue: Float
    public var isDrop: Bool
    public var maxFrames: Int

    /// Max frame number displayable before seconds roll over.
    public var maxFrameNumberDisplayable: Int {
        return maxFrames - 1
    }

    public var numberOfDigits: Int

    /// Returns max elapsed frames from 0 to and including rolling over to `extent`.
    public func maxTotalFrames(in extent: Timecode.UpperLimit) -> Int {
        return -1
    }

    /// Returns max elapsed frames possible before rolling over to 0.
    /// (Number of frames from 0 to `extent` minus one subframe).
    public func maxTotalFramesExpressible(in extent: Timecode.UpperLimit) -> Int {
        return maxTotalFrames(in: extent) - 1
    }
}

I'm sure there's not a huge performance hit by the current switch statement structure, but not having them at all would be less.

[orchetect]

A good idea to consider, and I know that Apple frameworks have often worked this way (albeit as classes).

After a fair bit of woodshedding early on, I landed on the enum cases for frame rates for a few reasons.

It's the most lightweight way of referring to a frame rate, and passing a frame rate around within the library.

Also, internally, there are many shared properties or commonalities between subsets of frame rates so the code was made more succinct and efficient when performing calculations. You could consider them families of frame rates because of how they behave or how they are calculated.

It also serves as a nice way to learn about frame rates by digging into the library source code, where you can clearly see these contrasts and commonalities adjacent to each other.

Additionally, keep in mind there is a lot of shared ground between video frame rates and timecode frame rates, but certain rates including drop-frame are not actual video frame rates. They exist in the land of timecode representation only. Which is where the disconnect is happening with the fps float value issue. It's a bit of apples and oranges. That's why FrameRate is a member namespaced inside of Timecode and not a top-level object itself. It's not intended on being a general-purpose FrameRate object. Its needs and definitions are specific to timecode.

Internally in DAW project files, timecode display frame rate is never stored as a float. It's stored as its actual named format, as you would see it in a frame rate selection list. The float value you're dealing with is a video playback rate read from a video file.

I would be reluctant to refactor into a model where FrameRate was itself a struct. If there is strong argument for it, it could be a consideration.

[ryanfrancesconi]

Cool, thanks for the explanation. I was surprised by the format of it, but can tell you've thought a lot about it.

it does make the concept of a variable or custom frame rate more complicated though, no?

[orchetect]

It would be a bonus feature, but I wouldn't mind testing it out at some point.

If it's possible in a DAW then there may be use cases out there for it.