With the ClipStoreMXc (CSMXc) one may use PBUS protocol to drive the ClipStoreMXc directly from any switcher supporting PBUS protocol. The PBUS protocol has three basic commands: LEARN, RECALL and TRIGGER. As far as the ClipStoreMXc is concerned, the PBUS control from the switcher is able to do the following:

? LEARN a specific clip ID (including the clip name, the directory in which the clip is stored, and one set of IN and OUT points within that clip).
? RECALL a learned clip ID (as described for LEARN). This command simply loads the learned clip in the player of ClipStoreMXc.
? TRIGGER a transport command.

ClipStoreMXc recognizes the following standard PBUS Trigger commands:

Trigger 0 = Normal Play
Trigger 1 = Recue Clip
Trigger 2 = Var Play
Trigger 3 = Reverse Play
Trigger 4 = Stop
Trigger 5 = Loop Play
Trigger 6 = (NOT SUPPORTED)
Trigger 7 = Normal Play

The PBUS commands are programmed to EMEM (memory) registers in the switcher itself; so when an EMEM register is stored or recalled, it stores (learns) or recalls the given PBUS command. The learned PBUS commands are actually stored in the ClipStoreMXc itself. In the Sony 7000 and 8000 switchers, one can label each "EMEM" register button with an alpha-numeric label to represent the clip ID (clip name) in the CSMXc.

This interface has been successfully tested on both GVG and Sony switchers. Other switchers that support PBUS protocol probably work as well, since PBUS is a rather simple protocol.

With PBUS control, one can either record a single large clip into the CSMXc with all the VKA elements contained within (the common workflow today), and then program an EMEM register for each IN and OUT point (or sub-clip) with that ?mega-clip?; but a better-organized workflow involves recording (or importing graphic files into) multiple clips in CSMXc, each clip being its own VKA transition element. Each EMEM register on the switcher can then be programmed to load the given clip and then play it with a trigger command. One can still mark an IN and OUT point within the clip using this scheme, but if the IN and OUT points are not learned with the EMEM, then the entire clip will play at the time of recall and trigger.

To use PBUS in the CSMXc, simply select the PBUS protocol in NetPanel:
? Click the EDITOR button.
? Click the PROTOCOL softkey.
? Click the PBUS softkey (this enables PBUS protocol).
? The ?PBUS Device ID? softkey becomes available. Click this softkey.
? Click the desired numeric PBUS DEVICE ID that you?ll be matching on the switcher side to control the CSMXc.

PLEASE NOTE: The use of PBUS protocol is predicated on the fact that the VKA elements are all ingested into the CSMXc with frame-accurate precision, so the VKA elements at a given timecode inside the clip are all aligned with each other. This is opposed to having the Video/Audio elements at the head end of the clip, with matching Key elements at the tail end. In such a clip, external controllers (such as the Lance TDC-100) control the video/audio via one RS422 port, with Key control via a separate RS422 serial port; this allows the video/audio to be "slipped" with regards to the key, and things are thus "re-aligned" by such an external controller. This means the use of PBUS requires you to ingest the VKA elements from the VTR using Auto Edit or an external frame-accurate controller; or you may ingest graphic files such as TIF, TGA or PSD (Photoshop) files that contain RGB fill with associated Alpha (key) on a frame-by-frame basis. The ClipStoreMXc features an Import utility to do just that.

From a complete workflow point of view, the best way to utilize PBUS protocol is to ingest the VKA material as a series of TIF, TGA, or PSD (photoshop) files, with embedded alpha (key); along with an audio WAV file to match audio to each series of graphic files. Using CSMXc?s Import utility, these graphics and audio files are then ingested as data, with real-time clips created inside CSMXc in which the VKA elements are always precisely aligned. This method also allows meaningful clip names for each transitional element stored in the CSMXc.

Of course, this means a change is required in today?s workflow, in which the graphic clips are delivered to the remote truck as a series of TIFs or TGA?s on a portable USB or firewire drive, rather than on videotape. That?s another battle, but one I believe is worthwhile. It certainly has it?s benefits: the studios creating the graphics won?t have to waste time creating multiple videotapes with the VKA material; they simply render each animation as a series of TIF's, TGA's or PSD's in a manner with which they are already familiar (with the associated audio WAV files). They then copy these files to a USB or firewire drive and ship that drive to the remote trucks. The VKA ingest in the truck is then much simpler, and always guaranteed to be spot-on frame accurate. This may be just a little more time consuming, since the ingest is a non-real time process, but it?s certainly a lot more precise, and allows individual clips names to be stored in the CMSXc (rather than one large ?mega-clip?) with the VKA elements guaranteed to always be aligned inside each clip.