Support linear (non-wrapping) timeline operations

[orchetect]

Bug Description, Steps to Reproduce, Crash Logs, Screenshots, etc.

Issue

In contexts where timecode Days component is enabled, linear timelines that support expressing timecode prior to zero-hour (00:00:00:00) such as Cubase 14 express this as such:

00:00:00:00 - 1 frame @ 24fps = -1 23:59:59:23 (essentially -1 day + 23:59:59:23)

Current Behavior

Currently when Timecode is using an upperLimit case of max100Days, subtracting 1 frame from zero by wrapping results in 99 23:59:59:23 since it underflows zero and wraps around 100 days.

Intended Behavior

This is where the interplay between Timecode.UpperLimit and Timecode.ValidationRule would have to become more nuanced.

It is proposed that some property allow the following behavior: (subject to change and may require further workshopping)

• With an upperLimit of max100Days to achieve Cubase 14's behavior:
  • 23:59:59:23 + 1 frame would result in 1 00:00:00:00
  • 1 23:59:59:23 + 1 frame would result in 2 00:00:00:00
  • 00:00:00:00 - 1 frame would result in -1 23:59:59:23
  • -1 23:59:59:23 + 1 frame would result in 00:00:00:00
• With an upperLimit of max24Hours we get a hybrid behavior which, while technically sound, may be intuitively confusing:
  • 23:59:59:23 + 1 frame would result in 24:00:00:00 and Hours could continue to accumulate without limit, while Days remains 0
  • 00:00:00:00 - 1 frame would result in -1 23:59:59:23 (similar to max100Days above) since there is no way to otherwise express linear timeline without negative Days
  • -1 23:59:59:23 + 1 frame would result in 00:00:00:00

Potential Solutions

1. One possible solution is to add a third Timecode.UpperLimit case named something akin to unbounded, unlimited, or freeTimeline. It would allow arithmetic operations to treat the timecode as having no upper or lower bound limits. This would result in timecode that increments or decrements the Days component for overflows and underflows of the 24 hour timecode clock. This may also suggest renaming UpperLimit nomenclature to something more broad, such as Scope or Context.

2. Another possible solution is to add an additional Timecode.ValidationRule case named preservingTimeline which allows arithmetic operations to treat the timecode as a linear timeline having no upper or lower bound limits, and to allow the largest timecode component visible based upon upperLimit to accumulate overflow or underflow as needed.

Considerations

Depending on the solution that is worked out, it may inherently suggest a rethinking of how UpperLimit and ValidationRule work with the numerous math functions. The goal would be to introduce this behavior with as little paradigm shift or end-user code changes as possible.