Re: aux time code
Re: aux time code
- Subject: Re: aux time code
- From: Helena Ju <email@hidden>
- Date: Fri, 15 Aug 2008 10:03:21 -0700
Hey folks,
Thanks for your input.
I'm concerned about the workflow:
User imports XML file, and referenced media file (perhaps also used
in another project) changes.
That doesn't sound right to me (the XML file import pretty much only
modifies project data today--the QT metedata is changeable but is not
user visible and therefor won't affect any existing projects). Nor is
it easily undo-able (since the media files could be brought online
later and would be unclear where this now media file resident data
came from). A separate application that users use could modify those
files without this confusion and could still send XML to FCP.
I believe that one could write Andreas's autorenamer application (for
clips and their subsequent files) today without any change from Final
Cut Pro. There are proper QuickTime APIs, or, in the case of the name
of the files, Carbon and Cocoa API, that give developers the file
level access.
The part I think we could improve is to provide access for the cases
that are NOT covered by existing API, i.e., you want to use that
timecode for something within Final Cut Pro and TC isn't supported for
that file format (like AIFF files).
As a bonus, I think it'd be great to add in support for retaining TC
tracks not already on the media file, since there is no data conflict,
but as I stated before, the media file shouldn't be changed, and its
data takes priority. If the user chooses to explicitly modify their
media files with TC data in FCP, they still have that option via the
user interface.
Import from and export to an XML format is to provide access to the
data model in Final Cut Pro, not to rewrite the access to the
operating system.
If there are further workflows that are not covered by this plan, I'd
love to hear those.
Thanks,
Helena
PS In the proposed scheme, it seems to me that if you did an XML
import with 3 timecodes, then batch captured the media, the TC would
stay in FCP, but only resident TC from the capture path would be
stored in the QuickTime file.
On Aug 14, 2008, at 7:36 AM, Andreas Kiel wrote:
Hi,
I tend to share Rainer's point of view.
There should be something like "updatebehaviour" available even for
more things in the XML - like file names (this somehow is already in
FCS 1 and 2), also for "scene/take/note/tape" in BWF handling as
another example. The original data could be kept with metadata or
something like an "item history" so you in worst case can revert to
original state - if you keep XML backups.
An example: I did an "auto-renamer" for clips in FCP using some text
files the user supplies or an XML using scene, take, note and angle.
When the XML is imported in FCP everything works fine, but if the
clips got offline it will be hell.
Same with any audio.
I know this will/would cost a lot of development time.
Andreas
On 14.08.2008, at 15:13, Rainer Standke wrote:
Hi Helena,
for full control, on both existing and non-existing TC tracks,
there should be a flag that you can turn on and off and that
decides if file or XML wins. This could work like the
updatebehaviour flag for QT metadata. In the latter case the actual
Quicktime files should be changed/overwritten.
I don't see the use or benefit of a situation where you have one TC
assigned to a clip in the QT file, and another one in FCP. That is
bound to become a problem later on in people's workflows. In other
words, I would like to see an optional behaviour where the TC in
the Quicktime does get overwritten.
That flag should off course default to off, or file wins, and maybe
there should be a warning in the user interface upon import.
My 2 cents,
Rainer
P.S. What should I expect to see when I import clips with all 3
timecodes and have them batch capatured? Will the aux TCs from the
XML migrate into the Quicktime file?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Pro-apps-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Pro-apps-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Pro-apps-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden