9-Pin Preferences

This page is a comprehensive description of what each specific preference in VirtualVTR and VirtualVTR Pro will do. It does not offer overall guidance on particular setups.

In most 9-pin control scenarios, you should use a house-sync genlock to ensure VirtualVTR's frames are clocked out in sync with your controller, and that it maintains perfectly drift-free playback at all times.

Emulate 9-Pin via Serial port
VirtualVTR has many unique capabilities, and perhaps one of the most powerful, is its ability to emulate a 9-pin video deck. Although this may seem a simple task, in fact it's not. The 9-pin protocol is a loosely defined spec, which is interpreted differently by various vendors. This can result in a variety of compatibility levels between various devices. As the application becomes more complex, so the compatibility becomes tested. Basic transport commands are generally compatible between all devices, but synchronisation and status protocols tend to vary. Gallery have spent two years optimising the 9-pin behaviour of VirtualVTR and result is a protocol which provides very good overall compatibility, with the ability to tweak various parameters to improve compatibility in challenging scenarios. This preference turns on the basic 9-pin slave engine.

General Information about 9-pin Compatibility challenges
As discussed above certain setups require more parameter tweaking than others. Most common setups require no changing of the default parameters apart from selecting the appropriate serial port. However, since VirtualVTR is often pressed into heavy service in some hazardous locations such as Film sound mix stages, it includes extensive 9-pin flexibility to make some of the hairyer setups operational. Most of this work is NOT to make VirtualVTR play pictures in sync (this always happens), but in fact most of the challenge is convincing the 9-pin controller that they ARE in sync, via the difficult 9-pin protocols. Since the QuickTime timeline is abstracted from the physical video frame outputs, it tends to work in a more 'buffered' and 'lumpy' manner, reading lots of frames from disk in one go, and allowing the video card to trickle them out smoothly. This can lead to a 'lumpy' interpretation of what the currently displayed frame is. Normally this is not a problem, but in extreme cases, it can be a challenge. Most of the parameterrs are not affecting video playback at all, they simple tweak how the video playback is represented to the controller via 9-pin. Do not feel afraid of the array of preferences available for 9-pin since you will probably never need them. However, when you do, Gallery tech support will be able to advise the best combination of values. Meanwhile, here is the detail of what they do.

Serial Port
VirtualVTR supports any OS-supported serial ports, including USB Serial adaptors like Keyspan, and built-in serial ports, like those found on DeckLink video cards. Select the port to use with this pop up menu. Note that in OSX, we have found the motherboard serial port substitues like stealth and gPort to be less reliable than other solutions such as Keyspan. In OS9, the opposite situation prevails.

Serial Latency
This is an extremely important pref for OSX serial port users. The 9-pin specification imposes a limit on the time window available for a slave device to respond to a query or command from a master. This time window is actually shorter than the default serial delivery window in OSX. Hence, with this preference turned OFF, some controllers may not recognise VirtualVTR as a valid device because its replies are not arriving within the time window it expects. In most cases, you should turn ON 'serial latency' (reduction) and set the value to somewhere between 2 and 5 milliseconds. This tells the OS to deliver incoming serial messages promptly so VirtualVTR gets plenty of time to reply to them before the controller gets upset.

Use Interrupt Timer / Use Serial Thread
As previously discussed, it can be difficult to acheive 100% compatibility with all 9-pin controller, and as such, VirtualVTR offers several modes in which to operate it's serial communications. The first mode uses a polling interrupt timer, which is a brute force mechanism to constantly check if serial data is incoming, with the timer frequency set to ensure that data is handled promptly, but not so high that it swamps the CPU by spending all the time checking the serial port. A better way to handle serial communications is by setting up a dedicated 'thread' which runs alongside the VirtualVTR video subsystem and which handshakes the serial port, waiting patiently for new data before processing it. This serial thread can be given a priority, which determines how important OSX should consider it relative to the video playback tasks in VirtualVTR. In extremely taxing 9-pin control systems, you may need to balance the serial thread priority with video playback performance. The very best way to do this is by using a Dual processor mac, since the OSX multi threading will work much more smoothly on these systems. You can also mark the serial thread 'timeshare enabled' to allow the video subsystem to interrupt the serial thread when it needs the CPU urgently. Fortunately, most 9-pin setups work perfectly well with the default settings of VirtualVTR Preferences, with a serial thread and 2msecs serial latency. However, its nice to know that all this is tweakable should you encounter a particularly demanding setup. Call Gallery for advice on specific settings for your scenario if you encounter problems.

Improve 9-pin timecode linearity.
if your 9-pin controller is reporting repeated status timecodes from VirtualVTR, you can enable this preference which will attempt to 'even-out' timecode report linearity. Note that even if the timecode reporting is 'lumpy', it is likely that video playback is completely smooth. Unbalanced CPU loading can lead to different priorities in the subsystems which play video and which report the current frame via 9-pin. This is only really an issue in very tight sync scenarios such as 2-pass DVD encoding and linear Video edit rolls. A faster Dual CPU machine will generally help here, also, and for extremely taxing setups (such as Sonic DVD Creator 2-pass encoding), you should use Gallery's P2Plus hardware 9-pin interface which uses a dedicated processor to manage the 9-pin comms.

Use Callback for Timecode calculation.
This pref is related to the situation described above. It uses a Quicktime callback mechanism to report passing frames for more defined serial frame edges. It can help satisfy some machine synchronisers, such as the SoundMaster Atom. However, the way it works is not very compatible with compressed video sources, particularly hardware MotionJPEG (MJPEG). If you are using MJPEG, you should not use this pref. if you must use this pref, use a fast CPU, and also enable 'Echo On' in the Video Output Assignments for the 'mjpa' media type.

MTC Overrides P2 transport.
Most 9-pin protocol problems with multi-machine synchronisers occur because the controller does not recognize that VirtualVTR is playing back in sync. Typically, the video really is in sync on the monitor, but because of CPU loading situations, sometimes this fact is not clearly indicated to the controller, mostly because the reported timecode passed back from VirtualVTR is not totally linear (ie. it is reported with some lumpy variation in response time, or with repeated or skipped frame values). Often in these situations, the machine controller is actually generating LTC as well as controlling connected machines. VirtualVTR contains an extremely good chase lock synchroniser, and in practice it is much faster to have VirtualVTR lock to timecode, than it is to allow a machine controller to slew VVTR into lock via 9-pin. To allow a hybrid setup where playback lock is handled by VirtualVTR by chasing the controller generated time, but where jog / shuttle control is required in non playback modes, you can use this preference. Essentially, it tells VirtualVTR to behave as a normal 9-pin deck when receiving basic locate, jog, shuttle transport commands, but to switch modes as soon as it received MTC, instead locking up to the MTC, and ignoring subsequent slewing commands from the controller. Shortly after VVTR locks to MTC, the controller will realise that VVTR is now in sync, and thinks its own slew commands were responsible. During synchronised playback, VirtualVTR continues to return status to the 9-pin controller. When the timecode stops, VirtualVTR reverts back to a well-behaved 9-pin deck for jog etc.

Use Incoming Timecode for 9-pin time.
As an extension to the situation described above this preference adds excellent timecode reporting linearity. Whilst the VirtualVTR timecode synchroniser is ensuring that the picture is played back in sync, this pref allows the 9-pin subsystem to ignore the (potentially lumpy) internal representation and instead simply 'echo-back' the timecode values sent by the controller, as the current reported position. This typically means the controller is hearing back exactly what it wants to hear to recognize accurate sync, whilst the VirtualVTR chase synchroniser is ensuring that accurate sync is what you get. This can be useful for setups with JSK synchronisers, and SoundMaster Atom systems, and any other synchroniser which can generate LTC during synchronisation.

9-pin ID
VirtualVTR can identify itself as a variety of different VTRs. Although this does not affect the way VirtualVTR behaves, it may affect the way the 9-pin controller treats VirtualVTR. This preference allows you to choose the status returned by VirtualVTR when requested via 9-pin.

NOTE.
In all cases, if your 9-pin setup is not performing, you should consider adding the VirtualVTR P2Plus hardware 9-pin interface which shifts the 9-pin protocol load to a dedicated CPU in the interface, and should keep almost any controller happy whilst VirtualVTR concentrates on playing the pictures.

©2003 Gallery