Hello Editsuite.com friends,

Due to tons of abuse, we now require that you request user access by sending us your Login, Name, Email Address, Phone Number, and Profession by submitting that info HERE.  I'll review your request and try to get back to you within the week.  You can't imagine how many folk want to trash forums with bogas advertising. 

Also, please help us gain enough Facebook "Likes" to have a custom Facebook URL!  

--Gary Lieberman

PBUS Protocl and CSMXc

14 replies [Last post]
Douglas J
Douglas J's picture
User offline. Last seen 3 years 33 weeks ago. Offline
Joined: 13 Nov 2006

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.

Douglas Johnson
Chief Product Manager, Abekas

Douglas J
Douglas J's picture
User offline. Last seen 3 years 33 weeks ago. Offline
Joined: 13 Nov 2006
I should point out there is a PDF posted on the Abekas FTP site which details the use of the PBUS Protocol, along with operation of the PBUS data exchange utility. This document reflects V3.5-RC1 software in the ClipStoreMXc, so please be sure to check with your EIC for the software version of the CSMXc (or just click on the "HeidiEdit" task in the taskbar to see the version yourself). The PBUS Control PDF document is at: ftp://ftp.abekas.com/Abekas_Products/ClipStoreMXc/Documents/Configuring_...

Douglas Johnson
Chief Product Manager, Abekas

Douglas J
Douglas J's picture
User offline. Last seen 3 years 33 weeks ago. Offline
Joined: 13 Nov 2006
Bill, The loop flag will indeed be part of the PBUS data that you can edit outside of the CSMXc. See you at NAB. Doug

Douglas Johnson
Chief Product Manager, Abekas

Bill D
User offline. Last seen 3 years 35 weeks ago. Offline
Joined: 18 Aug 2005
[quote="Douglas J"]Hi Bill, We are hoping to have the new PBUS Data Exchange utility ready to show at NAB-2007; stop by booth #SU-2520 (South Hall, upper level; right across the MAIN isle from the big Sony booth). In the CSMXc, when you perform a PBUS "learn" operation while the LOOP is turned ON in the currently loaded clip, then when the PBUS register is later recalled, the loop flag will be turned on automatically. This works today. We don't have support for playlist control via PBUS at this time. Doug[/quote] Doug, Sounds like a nice feature with the loop, would be cool if that would show up in the P-bus data as well, that can be uploaded. If I go I will defintily stop by the booth, sounds like it is shaping up to be a nice HD DDR (or SD). thanks
Douglas J
Douglas J's picture
User offline. Last seen 3 years 33 weeks ago. Offline
Joined: 13 Nov 2006
Hi Bill, We are hoping to have the new PBUS Data Exchange utility ready to show at NAB-2007; stop by booth #SU-2520 (South Hall, upper level; right across the MAIN isle from the big Sony booth). In the CSMXc, when you perform a PBUS "learn" operation while the LOOP is turned ON in the currently loaded clip, then when the PBUS register is later recalled, the loop flag will be turned on automatically. This works today. We don't have support for playlist control via PBUS at this time. Doug

Douglas Johnson
Chief Product Manager, Abekas

Bill D
User offline. Last seen 3 years 35 weeks ago. Offline
Joined: 18 Aug 2005
[quote="Douglas J"]Bill and Curt, Thanks for posting your replies; we are scheduled now to work on the PBUS data import/export exchange on the CSMXc. To answer Bill's question about developing Odetics or AMP: It is a trade-off on development time. We can get the PBUS data exchange going much, much faster than take the time to develop Odetics or AMP protocols in the CSMXc. We would rather get some kind of useful feature implemented sooner, rather than developing a much more complex feature that is delivered much, much later. BTW,we have put a request into the folks at Thompson Grass Valley, to obtain a copy of the AMP protocol documentation; but no response yet. Doug[/quote] Doug, cool, that is what I figured. I think the P-bus data is a good idea and should serve the TD's needs. I always thought the protocol documentation was just out there, guess not. Hopefully they comply, it seems to be the best protocol out there, pretty similar to odetics with a few better features. One thing to consider down the road when you start doing something with machine control is playlists. Not sure how the clipstore handles loops and playlists, but the AMP side from the switcher doesn't send out anything put load, cue, stop and play commands. So ideally the protocol can call up clips that are built as playlists or loops, and then when receiving a play command, play those loops or playlists correctly. Just some thoughts.. Bill
Douglas J
Douglas J's picture
User offline. Last seen 3 years 33 weeks ago. Offline
Joined: 13 Nov 2006
Bill and Curt, Thanks for posting your replies; we are scheduled now to work on the PBUS data import/export exchange on the CSMXc. To answer Bill's question about developing Odetics or AMP: It is a trade-off on development time. We can get the PBUS data exchange going much, much faster than take the time to develop Odetics or AMP protocols in the CSMXc. We would rather get some kind of useful feature implemented sooner, rather than developing a much more complex feature that is delivered much, much later. BTW,we have put a request into the folks at Thompson Grass Valley, to obtain a copy of the AMP protocol documentation; but no response yet. Doug

Douglas Johnson
Chief Product Manager, Abekas

Curt
Curt's picture
User offline. Last seen 4 years 35 weeks ago. Offline
Joined: 30 Sep 2005
Doug, I agree with Bill, sounds good to me. The basic idea is to be able to create/edit PBUS data, and then be able to send that to the clipstore. Thank you Curt
Bill D
User offline. Last seen 3 years 35 weeks ago. Offline
Joined: 18 Aug 2005
Doug, Everything you said would work fine so multiple shows could use P-bus in one 'house' Or when coming into a truck a TD could load their P-bus file to the clipstore. Just curious why are holding off on odetics? just cost of writing for it, etc.? Also not sure what controllers besides Kalypso will do it, but AMP is even nicer then odetics, multiple folders and no character limit for clip name. sounds good though thanks Bill
Douglas J
Douglas J's picture
User offline. Last seen 3 years 33 weeks ago. Offline
Joined: 13 Nov 2006
Curt and Bill, Thanks for your feedback; it appears this is an important issue for TD's when using the CSMXc. We are thinking of developing a very simple application that can run on either the ClipStoreMXc itself, or on a WinXP computer that will allow you to export the PBUS data into a human-readable (and editable) text file. Likewise, this application would also import the user-defined PBUS data into the ClipStoreMXc. One could then edit the PBUS data in "Wordpad" or other simple text editor, and then import the PBUS data back into the ClipStoreMXc. This would also provide a means to store several "snap shot" variations of the PBUS data for the ClipStoreMXc. Does this meet your needs in this application? Is there anything else required to make this work? If we can help it, we would like to hold off developing Odetics protocol if we can. Doug

Douglas Johnson
Chief Product Manager, Abekas

Curt
Curt's picture
User offline. Last seen 4 years 35 weeks ago. Offline
Joined: 30 Sep 2005
[quote]There is currently no convenient method to access and modify this PBUS data inside the ClipStoreMXc. If there is enough interest from your fellow TD community, then we may possibly be able to investigate a method of providing access to this data via the NetPanel GUI (or via some other user-friendly method). Regards, Doug[/quote] Doug...thank you for the response. Since the Clipstore is built on the Windows XP platform, is the PBUS information stored in a file that another windows application would recognize...ie Microsoft Excel?...outside of the clipstore application? I know this would mean using another app to edit, but thought this might be a work around. This is how it has to be done on the Buf Spot panel for instance, b/c the GUI that the PC interfaces w/ the Spot panel will not allow for editing. We current use the profile in the configuration you mention where we record fill and key at the same time, and they have to be frame accurate. That was actually another question I had, but your reply answers that also. Thanks again for the information. Curt
Bill D
User offline. Last seen 3 years 35 weeks ago. Offline
Joined: 18 Aug 2005
Douglas, thanks for the info on the machine control, and I was curious about Curt's question as well. There are two ways this could be handled. Here are my thoughts. If machine control stays as BVW, then to use individual clips we would have to use P-bus for recall. There would need to be some way for each show to distinguish it's emem recall attachment to different clips. Otherwise everytime you come in to do a show you would have to relearn every emem that calls up a clip. Another solution would be to have clipstore talk odetics, or AMP. Most of the switchers talk these protocols, and can save clip name and timecode info into the emem recall. This could then be saved and loaded with all the other effects. If switcher doesn't talk this protocol then a lance or similar panel (Buf, DNF) could be used. All of these boxes have a way to save and upload emem to p-bus associations. Not sure what protocol's Sony and Kahuna use. I know GVG switchers have odetics and AMP (newer version of odetics, that can recall clips in multiple folders). As a operator I would prefer machine control, preferable not bvw, I agree with your other posts, indivual clips makes so much more sense. I know for sports this may be tough if they don't follow your ideas about file transferring. Really makes no sense to have one long tape like we have been doing. It easier for gfx operators and no quality issues, and easier for TD's if clips are uploaded as files to the clipstore. thanks, Bill
Douglas J
Douglas J's picture
User offline. Last seen 3 years 33 weeks ago. Offline
Joined: 13 Nov 2006
From the "Cost" thread in this forum: [quote="Curt"]Doug, Thank you for that information. Glad to hear about PBUS. Once question I did have though. Does the Clipstore allow you to save PBUS "files"...Meaning...if I am doing one show that uses one effect register with one clip...but another show wants to use that same register with a different clip, is there a way to save the PBUS information w/out having to relearn before each show. We do alot of this now using a Buf Spot panel, which allows you to send different PBUS files from a PC connected to the Panel ( or 2 panels in our case) before each show. This way each TD can use any EMEM, w/out worrying about stepping on someone elses effects. If this is possible, can you edit this this file either with in the GUI app , or if not, w/ another program..such as Microsoft Excel? Ok...so I guess that was more than one question..!...Thank you Curt[/quote] Curt, There is currently no convenient method to access and modify this PBUS data inside the ClipStoreMXc. If there is enough interest from your fellow TD community, then we may possibly be able to investigate a method of providing access to this data via the NetPanel GUI (or via some other user-friendly method). Regards, Doug

Douglas Johnson
Chief Product Manager, Abekas

Douglas J
Douglas J's picture
User offline. Last seen 3 years 33 weeks ago. Offline
Joined: 13 Nov 2006
Bill, The ClipStoreMXc can be controlled directly from the switcher via RS422 control with Sony BVW-75 protocol, which would provide "machine control" over the ClipStoreMXc. Likewise, the Lance TDC-100 controls the CSMXc with the same Sony BVW-75 protocol. In both of these cases, you would have to place all of your media into "one big clip" and then use "a bunch of IN and OUT points", as you put it, to reference the individual "clips".

Douglas Johnson
Chief Product Manager, Abekas

Bill D
User offline. Last seen 3 years 35 weeks ago. Offline
Joined: 18 Aug 2005
[quote="Douglas J"]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. .[/quote] Douglas, The P-bus sounds great. For a little more control through a switcher, you can do machine control using 422. If the lance can control it, is it basically controlling it via bvw control? Does this mean you can not call up different clips through the lance, just one clip with a bunch of in and out points. You mention it doesn't support odetics in another post, just curious what protocol it uses that allows the lance to talk to it, which could allow a switcher to do the same. thanks Bill