Timecode parser, guessing and shorthand

[ryanfrancesconi]

For manual entry of timecode i think a short hand would be helpful similar to how Premiere does it. Here's a few examples from Premiere:

a function might be something like:

    class func parseTimecode(string: String,
                             frameRate: Timecode.FrameRate,
                             delimiter: String = ":") -> Timecode? {
        let components = string.components(separatedBy: delimiter)

        var tcc = TCC(d: 0, h: 0, m: 0, s: 0, f: 0, sf: 0)

        switch components.count {
        // 01:00:10:01:11
        case 5:
            tcc.h = components[0].toInt()
            tcc.m = components[1].toInt()
            tcc.s = components[2].toInt()
            tcc.f = components[3].toInt()
            tcc.sf = components[4].toInt()
        // 01:00:10:01
        case 4:
            tcc.h = components[0].toInt()
            tcc.m = components[1].toInt()
            tcc.s = components[2].toInt()
            tcc.f = components[3].toInt()
        // 01:00:00
        case 3:
            tcc.m = components[0].toInt()
            tcc.s = components[1].toInt()
            tcc.f = components[2].toInt()
        // 1:1 = 00:00:01:01
        case 2:
            tcc.s = components[0].toInt()
            tcc.f = components[1].toInt()
        // 10 = 00:00:00:10
        case 1:
            tcc.f = components[0].toInt()
        default:
            return nil
        }

        return tcc.toTimecode(at: frameRate)
    }
`

[ryanfrancesconi]

would need to better take into account semi colons for drop frame perhaps or other considerations

[ryanfrancesconi]

Here's a video showing the idea:

timecode_shorthand.mov

[orchetect]

Currently the Timecode() string initializer (and stringValue setter) use a moderately flexible heuristic for accepting malformed or shorthand input, which is largely by design to act as pre-formatted validation of raw timecode strings being fed into it.

It's possible to modify the string parser to intelligently handle shorthand as you've suggested, but since there likely is no empirical/standard on how shorthand should be accepted (different DAWs and video editing apps may behave slightly differently in this regard), it may:

1. be better left to the developer to implement their own shorthand parser as they see fit, or
2. build several parsers for TimecodeKit that are selectable by a parameter which cover the variations possible.

[orchetect]

Deferring this to a future date when I can write additional formatters for specific contexts.