Timeline Analog 2. John Buck
Чтение книги онлайн.
Читать онлайн книгу Timeline Analog 2 - John Buck страница 6
Название: Timeline Analog 2
Автор: John Buck
Издательство: Ingram
Жанр: Изобразительное искусство, фотография
Серия: Timeline Analog
isbn: 9781925108583
isbn:
Splices - Edit - Play - Scenes.
The CMX interface acted as an electronic equivalent of a film editing system. Single letters on screen could be tapped with the light pen to set the rushes in motion.
The letter F was used for fast, N for normal speed, S for slow and J for jog, one frame at a time was. A still-frame was selected by touching any of the hyphens/rectangles between the letters. These variable speed capabilities were breakthrough achievements by themselves.
The CMX digital team had expanded on the work of Ampex engineer Anthony Poulett who had experimented with recording and reproducing television signals with an altered time base effect.
The video rushes signals had been recorded to the Memorex discs at a predetermined head-to-medium writing speed, and could be played back at the same head-to-medium writing speed, single frame access or half head-to-medium speed.
When the editor selected the ‘Scenes’ option from the right-hand monitor, he was able to call up the various rushes material. He could then play a shot and chose the first frame he required. Then he pressed the light pen to the word ‘Splice’ and the chosen frame was instantaneously transferred to the left-hand monitor and spliced to the preceding material.
By selecting ‘Play’ on the right hand monitor material, the editor then played through the scene to select a desired exit point. The exit frame of the previous one scene was always present on the left-hand monitor and the entrance frame of the next scene on the right-hand monitor.
As an alternative to a direct cut, the editor could call up the Edit option which gave him the ability to add a transition such as a (fade,dissolve,wipe,matte) or a special effect of any length from one frame on.
The 600 had the option of splicing video only or audio only from the "Edit" option.
Jim Adams continues:
From the software side, the 600 was pretty straight forward. Disk drive positioning was well known, all of the video was 30 fps and the PDP-11 real time clock (RTC) provided timing interrupts at 60 Hz.
Dave Bargen worked out the timing to switch between the primary playback disks and the auxiliary at the various playback rates and I devised a satisfactory for the Edit Decision List (EDL) as we named it. This was nothing more than an ASCII formatted list of source material, in-point and out-point frame codes and the computed record points.
The operator could also specify whether the recording was to be audio only, video only or both, and if the video was to be switched or fed through an effects generator. The audio and/or video transition was provided within the 600, but no effects were simulated.
Some of the original material was recorded in color and was frame coded in what was known as 'Drop Frame Code'. This code periodically omitted two frames from the frame count. For the 600, this was a minor issue and I solved it easily with special add and subtract routines, not unlike leap year day counting.
Interestingly the CMX team realized that the editing system could be controlled by other devices. From their 1971 patent:
It will be appreciated that while the light pen character generator described herein is particularly suited to convenient operation of the disclosed editing system, other interface terminals could be utilized if desired, such as keyboard, push buttons, joystick, etc
While the CMX 600 unit was now more or less capable of recording and playing video and audio in sync for an editor to make edit decisions, its sibling system, the CMX 200 needed to be able to translate all of those decisions in order to control the high resolution videotape copies of the master material on analog VTRs and ATRs.
Dave Bargen adds:
The second product priority was the Assembler system to be called the CMX 200. It isn't talked about much, because it isn't as glitzy, but it was an integral part of the product plan from the outset. It would take the edit decision information from the 600, and control broadcast tape recorders to produce the finished program
Jim Adams began work on the 200 Assembler.
One of the features of the PDP-11 was the ability to use the input and output ready/busy signals as interrupts under software control. I therefore set up the frame-code ready signals as interrupts and was able to keep track of the location of each (playback and record) tapes.
I keyed off the Real Time Clock (RTC) to analyze the tape position while seeking the in-points for each insert edit and was able to cue the VTR by alternating between Fast Forward and Rewind commands depending on the distance the tape was from the pre-roll target point.
Once all tapes were parked, they were put into play and capstan plus or minus over-ride commands were issued to bring them into synchronization with the counting of the PDP-11 processor. Conceptually this worked very well, but a number of issues surfaced that impacted the operation of the system.
The first was the tape machines did not follow the commands from the processor. I brought this up to the lead digital engineer, W. King Anderson and he assured me that it was a software problem.
After stepping through my code and observing the reactions of the VTRs, I approached King once again and told him that the interface cards were not responding to multiple commands from the processor. King reiterated that even though there were no ready/busy signals from the interface cards, they were much quicker than the PDP-11.
He did ask me how quickly I might be issuing commands, and I told him they would be about 1.2 or 2.4 microseconds apart. This completely surprised him and he said the interface card would take 5 to 8 microseconds to process each command. I added software delays into my code until the cards could be modified with appropriate ready/busy signals.
With the tape machines responding, other problems were exposed: some edit points were occasionally off by a frame, other times the switcher did not respond to commands from the processor.
More insidiously, the PDP-11 would halt with a fault signal and had to be restarted. I reported the issue with the fault signal to both the CMX management and the DEC maintenance people and was assured that is was a software problem.
I began logging each time the fault occurred and it appeared to be very random. I again reported the problem and was told "Software Problem, fix it". After a couple of weeks of this, I set out to find the root cause.
Staying late one evening, I hooked oscilloscopes to the various interface cards and into the PDP-11 processor. After about six hours of testing, plus my logs from the previous weeks, I was confident that I had the root cause of the fault.
Most mini-computers had instruction sets that were all 16 bits (2 bytes) wide. The PDP-11 had different lengths (2, 3 and 4 bytes) for different instructions like most of the large computers. This is a very efficient use of program memory and allows for more complex instructions in the 4 byte instances.