[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
daVinci Tape-Tape Corrections
>Date: Tue, 22 Nov 1994 00:52:42 -0500
>From: HUE4YOU at aol.com
>Message-Id: <941122003042_4677803 at aol.com>
>To: telecine at xyzoom.alegria.com
>Subject: DaVinci/TLC interface Re: TtoT
>Checking to see if anyone out there has tried to use TLC as an edit
>control device in tape to tape mode. We have seen the oddest
>behavior when we try to edit utilizing the TLC as a controller of our
>source deck. Although we place the Da Vinci in the SLAVE mode as
>specified, we see that in the actual EDIT mode,(and only in EDIT)
>the frequency of skipped or non executed color corrections is quite
>>Date: Tue, 10 Jan 1995 10:38:47 -0700
>>To: HUE4YOU at aol.com
>>From: atoms at bach.ccinet.ab.ca (Andy Toms)
>>Subject: DaVinci/TLC tape to tape
>>Cc: rob at xyzoom.info.com
>>Hi I just saw your message regarding skipped color corrections during tape
>>to tape, and wanted to say "YOU ARE NOT ALONE"
>>The solution is to press "cmd play" during the preroll to
>>the edit, which forces DaVinci to reload its event buffers. Since trying
>>this, we have not had the problem with skipped corrections.
I was asked to comment on the above exchange. Indeed, I have seen 18.104.22.168 URSA analog
Renaissance code exhibit this problem with the TLC doing an edit. Andy Toms is correct
that the current work around is to do a <CMD> <PLAY> key sequence after the TLC has
rolled the SOURCE deck. I was told by our software department that the current URSA code
with the new Noise Reducer mode implemented may fix this problem. Looking over the
latest exchanges with Andy and the factory customer servcice department, it appears that
this is not the case. Maybe if Andy Toms is reading this, he could comment?
If anyone has any further questions or comments, I would be happy to respond as best I
can from this end.
Dwaine Maggart - daVinci LA Regional Field Service