Standard version: 1.5

Major Change

Subcommittee

Pierre (RE:Vision Effects),  Jason (BorixFx) also expressed interest in specifying this properly, and others.

Overview

I think for host that have in and out trim points in their user interface, it should be documented what the host should then.

And because this is essentially what it does and there is no API to capture that.

We need to maintain the integrity of the OFX time regarding the source clip (e.g. changing the trim in-point does not affect then where a particular frame is in OFX Frame time - so does not slide the whole OFX world).  Yet this is potentially useful as well for an effect that needs to analyze the whole sequence (presumably in Instance Changed). For example if a source clip is 3 minutes but the trim points defines 10 seconds, the effect in question can see output frame range and do the appropriate thing.

2) Frame Range

As additional context there is where it is implemented an action to set that (the Time Domain Action ) but that's for hosts that need this to allow effect to extend or change that. That action states that the default is:

Question:  Is there such a thing as a Generator that does not have infinite frame range? 
Statement: This vaguely follows (Dod and Roi) - A generator might have infinite time extent but the next effect gets an explicit finite frame range. One can have a mechanism to set a time Roi (trim points) yet the frame range domain of definition might be "wider". 

 - Pierre

Solution

1) We could create timelineSuiteV2 - that clarifies (makes it clear and non-ambiguous) 

 

getTimeBounds returns the in-out trim points, not the Clip Prop FrameRange. Trim points bounds are always within or equal to Clip FrameRange (clip valid frames). 

For backward simplicity, add getTrimPoints 

and we need a getTime (or convert to LocalTime?) that allows us to convert from or to local OFX frame time to timeline time. It's not how some implement it.

 

This does not imply recursive evaluation - i.e. an host with constructs supporting nesting - would effectively return something based on duration of sequence/comp etc NOT that there exists deep down more frames possibly available. Similarly NLE operations like Razor Splice implicitely mean removing frames of a clip, these can be interpreted as new valid range by host. 

 

2) Since we are fixing generators in v1.5 - the Time Domain action might need to sport a documentation clarification:

Documentation currently says: Only General Context can set this.