Darrin,
Thanks. I'm presuming that groups don't have an interlaced/progressive setting per se, but that are by inference set to the project's properties for field order/progressive state. Correct me if I'm wrong, because the rest of my email relies on this assumption.
So are you then saying that simply putting an interlaced clip inside a group (where the project is progressive) and applying my effect (without an image well) will not get the proper attributes given to me internally? Let me rephrase that. I know that's not what happens. So my question is really this: Do you agree that this is a bug in Motion?
All I want to do is this:
And I want the effect to give me the output as progressive (which is conceptually the state of the project, or group), while the clip is reported to me as interlaced (because it IS interlaced :-)). What I get NOW inside my effec within Motion t is the input and output are reported as interlaced, when "clearly" the output is progressive (as per my assumption in the first paragraph).
Why would I need to know this you ask? For HQ retiming purposes I need to know this, for deinterlacing this would be of great help. For example, knowing that the input is interlaced and the result is progressive make a difference as to what we do internally for retiming, and gives us a strong clue for caching etc. to create the retimed sequence. In FCP 6 and 7, each sequence (the conceptual equivalent of a group in Motion) has a specific interlaced/progressive state, so there is no confusion as to what the "output" setting is. In Motion it seems like this is conceptually defined by the project settings, since groups really have no interlaced/progressive state specifically attached (at least that is my operating assumption).
Let's say a user wants to retime some interlaced footage, and convert from interlaced to progressive WHILE they do that. So in order for our software to be able to be efficient and calculate some other important things internally based on the the input and output "fieldness", what you are suggesting is that users need to great 2 groups and apply an effect to a progressive piece of footage that's the same resolution as their interlaced material (just to get the progressive output state set, right)? Then they need to put their interlaced footage in a image clip well? Let me ask you this: if you were applying an effect to some footage, and converting it from interlaced to progressive in the process, would you expect to have to apply your effect in the way you describe rather than just applying the effect to your interlaced footage, and then have the result be defined as progressive as set by the group, or project settings, state)? The second, easier way of doing this is what we've been able to do in FCP since FCP 6.0.3.
Let me ask an easier question: what is the interlaced/progressive state of the inputs to my effect plugin based on? For clips that are used as the main or image well inputs, I presume that motion justs reports to me the field state of the clip. If I were to drop a group in a clip well, is the progressive state the state of project settings (that is, is the progressive/interlaced state of a group independent of what clips reside within it)?
Pete