[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: flex-files (ongoing)



This looking like a good dialogue.


>>2. More flexibility to be able to remove/edit erroneously recorded events 
>>such as might occur when grabbing data on the fly.
>The v.6.00 BorderMover fulfills this need (see v.6.00 manual section s10.5)

I'll be sure to check this.


>>4. It seems to be a major Achilles heel that if there is an error in the 
>> collection of data, that it is not apparent to the operator until you 
>> have completed an edit (for instance after a 33 minute flat of 16mm) 
>> and gone back to review your data.
>Is it that I am not native english, but I can't see where you are going.

As I understand operations, using one of Aatons variety of approaches (On 
the fly logging, "G" marking as you go, or the 1st pass - 2nd pass 
method) the user will end up having collected one or several "records" of 
event data into the database.  Within the data collection window there is 
no reporting of the actual data captured, rather there is only a numbered 
mark on the time line indicating the presense of an event.  To verify the 
correctness of that data one must take the time to exit the data 
collection area and enter the data management area.  Referring back to my 
worst case example above, IF someone were to only have marked a "G" at 
the head of a 1200ft (3 cam roll) flat of 16mm, and it turned out that 
there was an error in the collection of data at the "G" point, the 
operator would be unaware of the error (because it is not visually 
apparent to him at the time of collection) until after completion of the 
33 or so minutes it would take to transfer the roll.


>>5. There could be much more flexibility with the ergonomics of your 
>> visual interface by hiding many of the parameters Config window. 
>Agreed. v.6.4 (thanks to the 32bit O/S introduced with the current v.6.02) 
>will beneficiate of a much more powerful graphic library. But remember 
>that one of the Keylink claims-to-fame is that colorists can permanently 
>check the transfer environment, be it telecine phasing 
>or VTR Ltc misbehaviors.  We will not abandon that feature for 
>the sake of fashionable pull-down menus.
 
As I had mentioned, some of the base parameters should remain (TK speed, 
Transfer speed, Telecine Phasing, etc.), but much of the engineering 
level parameters only need to be considered when there is a question 
about the system setup; another Fkey would do fine.  This stuff just 
seems to fill up the screen.
When you said "fashionable" pull-down menus, did you mean practical?


>>7. I think the visual interface would be easier to navigate if it more 
>> closely reflected the progression of events in a typical setting.
>Sure, do you know Keylink already asks for a quarter of the time it takes 
>to set other comparable systems?

A revelent point, the few fields of data collected make it nice and easy 
to set up.  But I favor the idea of subtly leading the user through a 
visual interface with clever navigational cues.  Some of that was 
improved upon in the 6.0 versions, but my eyes still whip across the 
screen when I have to enter a time code number for the tach driven T/C.  
I would expect to see the T/C entry cue branch off to the right, instead 
of its popping up near the top left of the screen.


>>9. I would like to be able to have a selection of sorting options in the 
Titles view.
>v.6.01c already added alpha sorting to descending time, do you really need
some other sorting criteria, such as colorist's name or box-office 
ratings?

The choice of what is needed in a practical scenario should be left up to 
the operator, not up to the vision of the software designer; . . . oh, 
and sorting by colorist is an interesting idea.


>so please download the PDF compressed v.6.02 manual.

JP, thank you.

Tim Bond

This Email address is shared by the Bond home, so please put the 
RECIPIENT'S NAME within the MESSAGE BODY for proper routing.