Hi Folks, There is now a new ClipStoreMXc Forum on Editsuite.com: (). This new forum is the place to go for specific information and discussion of the Abekas ClipStoreMXc HD/SD digital disk recorder. Regards, Douglas Johnson

John, We have some tentative plans to add Odetics protocol to the CSMXc, but nothing definite as of yet. The "second video channel" can only handle luma-only "key" -- so it's not a "video channel" but rightly labeled a "key channel." There are absolutely no possibility of making this into a full-bandwidth (read: chroma + luma) "video channel" in the CSMXc product.

I wanted to quickly add that my first experience with the Clip Store was relatively painless. I was a little concerned going in because of all that I have read here and considering that my show was a national broadcast (ACC Sunday Night Hoops on FSN). The box acted and reacted well during the show and only gave me grief during pre-pro with effects for which I didn't build additional "STOP" and "RECUE" keyframes to keep it "thinking" (upon a RUN trigger, only the matte would fire and then pause in mid-effect). Doug, thank you again for all of the support. My biggest word of encouragement would be to get the bugs worked out with Bill Lance first, especially those prohibiting your device and the Lance from being in synch frame for frame in jog and shuttle modes. It was difficult to clip 30+ elements then have to figure out the right combination to get the fills and mattes lined up exactly. I had no problems creating new clips, or making an append to existing clips. Doug, any chance of future protocol changes or additions (i.e. Odetics?) and is getting that second video channel to be more than a Key channel completely out of the question? JH

I've had this problem with FF's, Profiles and sometimes Spotbox. I use a Macro RUN command so now when I build that macro, I insert a .02 delay then run and attach that to a button of my choice. It gives the Lance/DDR a chance to "talk".

[quote="Douglas J"]Hi Rick, To further clarify how the CSMXc can work in ?today?s workflow?, there is provision to use OVERWRITE recording starting at a specific timecode inside the clip. However, in the software that?s currently installed in the CSMXc?s the field, I would advise against trying that right now. There are some known bugs with timecode recording that could mess you up. There is a possible escape route, by using ?TCN? timecode with a TCN OFFSET applied, but that admittedly can become a bit cumbersome to use. I would advise waiting for the new V3.3 software to be installed in the CSMXc before attempting the OVERWRITE method. We are working to vastly improve the timecode handling during OVERWRITE record mode (as well as during NEW CLIP and APPEND recordings). We?ve also added a new feature that provides a new ?LTC Source? in the CSMXc, which is ?ReGen?. This will allow you to park the disk at a given location inside the existing clip, select OVERWRITE record mode, and pickup the LTC at that location, marching forward from there. When you go into record to overwrite the ?old promos? with the new, the LTC will be picked up and re-written with the same value. An alternative process with the V3.3 software will allow you to simply disable the TIMECODE track from the recording, and you would simply OVERWRITE the video, key and audio tracks inside the clip, keeping the LTC values intact. We?ve also improved the ?LTC TCG? (timecode generator) in V3.3 so that if your LTC track somehow gets messed up (or if the source videotape has broken timecode at time of ingest), you can set a specific LTC PRESET value for the LTC TCG, and then have that value recorded as the starting value into the LTC track. This operation could be done at the time the videotape is ingested, or afterward as an OVERWRITE record of only the LTC ?TIMECODE? track. In the meantime, I suggest you continue to operate with append recordings to the ?mega clip.?[/quote] Hi Douglas: Sorry for the delay in my replies I have been a little busy. I hope you had a nice Thanksgiving. I don't want to make this a long email and I do appreciate your very informative answers to our questions. With regards to the "work flows" you speak of. I can assure you that the Graphics people who generate the various amounts of graphics for the shows we work on will not "pre-load" TD elements to the three Abekas disk drives and then ship them out. That will not happen because we get weekly additions on videotape after initlal reels are built. There is always more to add on and each production team/various regional networks do things differently. I think that is unlikely that just "a Abekas load" could be done unless the animated elements could be combined with the other elements which are destined to be loaded on a Terabyte Firewire drive then transported to the various regionals. No other network will do it and I've had discussions with the FOX Network about pre-loading, but it's more complicated than that because as I have mentioned, there is always something to add on and some of the material we take in is disposable after they air. It is for these reasons why I began this dialog with you to try and make Abekas aware that there has to be a better way of managing the clips that are stored on the 3 drives. I think per your writings, that the new version of software will be that much better, but in reality, Abekas needs to look at a way to quickly store/recall the clips to/from portable media ie: Firewire or USB2 drives because not everyone will own and transport their own drives. There should be some way of cueing to a certain part of the disk for re-record and "overwrite" as we discussed. I know I'm asking for something specific and something that I'm used to, but this is the reality in the field. You keep mentioning injesting with the tape timecode. That is all well and good after an intial load, but the problem as I have mentioned before, is we get plenty of tapes with the same timecode, so as a management tool I (myself) place different elements at different places on the drives. I do not use the tapes timecode because of this - I use the timecode generated by the Lance Controller. For the most part, I think we'll have to wait to see how you can implement the new software. You said your working to improve some of this and all I can do is stress the importance of this for operators in the field. Additionally, with all due respect to all concerned, while your having Mountain Mobile engineers test your new software, I think you have to keep in mind they are not operators. At some point in your testing you will have to work with a qualified TD who knows how to properly manage clips to see if your software implementation is truly successful. Thanks so very much. Best, Rick.

[quote="Rick Tugman"]?And if we could "OVERWRITE" to the specific timecode on the drives then we would be managing the amount of disk space used. So please elaborate! I'm sure I'm not alone in making a better mouse trap and if change is required by the "food chain" to accomplish this and have the use of multiple clips, then we as "the users" have to make that happen.[/quote] Hi Rick, To further clarify how the CSMXc can work in ?today?s workflow?, there is provision to use OVERWRITE recording starting at a specific timecode inside the clip. However, in the software that?s currently installed in the CSMXc?s the field, I would advise against trying that right now. There are some known bugs with timecode recording that could mess you up. There is a possible escape route, by using ?TCN? timecode with a TCN OFFSET applied, but that admittedly can become a bit cumbersome to use. I would advise waiting for the new V3.3 software to be installed in the CSMXc before attempting the OVERWRITE method. We are working to vastly improve the timecode handling during OVERWRITE record mode (as well as during NEW CLIP and APPEND recordings). We?ve also added a new feature that provides a new ?LTC Source? in the CSMXc, which is ?ReGen?. This will allow you to park the disk at a given location inside the existing clip, select OVERWRITE record mode, and pickup the LTC at that location, marching forward from there. When you go into record to overwrite the ?old promos? with the new, the LTC will be picked up and re-written with the same value. An alternative process with the V3.3 software will allow you to simply disable the TIMECODE track from the recording, and you would simply OVERWRITE the video, key and audio tracks inside the clip, keeping the LTC values intact. We?ve also improved the ?LTC TCG? (timecode generator) in V3.3 so that if your LTC track somehow gets messed up (or if the source videotape has broken timecode at time of ingest), you can set a specific LTC PRESET value for the LTC TCG, and then have that value recorded as the starting value into the LTC track. This operation could be done at the time the videotape is ingested, or afterward as an OVERWRITE record of only the LTC ?TIMECODE? track. In the meantime, I suggest you continue to operate with append recordings to the ?mega clip.?

Hi Scott and Rick, Sorry for my delayed reply. I've been working like an animal this week to get a beta version of the CSMXc software ready for Mountain Mobile to test. Hopefully, we will get the beta version to the EIC either today or tomorrow. The so-called "food chain" that I referred to involves all the people in the workflow from the production of the animated graphics all the way to the people who use these graphics live on the air in the trucks. With some minor variance, today?s basic workflow for your application follows these primary work points (I?ll ignore planning meetings, etc.): Existing Workflow: a. Graphics studio creates a series of animated graphics using computer graphics programs. b. These animations are rendered (usually to a disk recorder or to a high-speed computer) for purposes of review and approval. c. Once approved, the graphic animations are transferred to videotape with a significant amount of effort in order to edit all the video/audio elements into the head end of the videotape, with a series of separate edits to place the key elements at the tail end of the tape. In some instances, two separate videotapes are created; one for video/audio, the other for key. d. Someone may or may not log the timecode values for the individual clips on the tape (usually not, from what I understand). e. The videotape(s) and timecode log are shipped to the truck. f. EIC (or other personnel) ingests the ?Video/Audio? portion of the videotape into the disk recorder. g. EIC (or other personnel) ingests the ?Key? portion of the videotape into the disk recorder. h. TD (or other personnel) programs the TDC-100 for all the IN and OUT points for each transition using the timecode log (if available), or by painstakingly reviewing the VKA clip created by the ingest of the videotape(s). i. TD programs the switcher EMEM to trigger the TDC-100, which in turn triggers the disk recorder for playback. j. The animations are aired. In an ideal world, this workflow could be streamlined if the graphics studios creating the VKA animated graphics were to simply render each animated clip as a series of TIFs, TGAs or PSD files (with embedded alpha), each with a unique filename and delivered to the remote truck on a portable USB or firewire disk drive (eliminating altogether the videotape transfer). The CSMXc could then import these graphic file sequences in the truck. One possible new workflow: New Workflow (A): a. Graphics studio(s) creates a series of animated graphics using computer graphics programs. b. These animations are rendered (usually to a disk recorder or to a high-speed computer) for purposes of review and approval. c. Once approved, the rendered TIF or TGA sequences (with associated audio WAV files) are copied to a portable USB or firewire drive. d. This portable disk is shipped to the truck. e. EIC imports the graphics into the CSMXc, using the CSMXc Import Utility. Separate clips are automatically created inside the CSMXc by this process. f. TD programs the switcher EMEM to load and trigger the individual CSMXc clips. g. The animations are aired. This workflow could be modified slightly and streamlined a bit further, if the graphics studios themselves also had one or more CSMXc machines, with one or more spare 3-disk sets. The graphics studios would then ship the 3-disk sets to the truck(s), thus eliminating the need to copy the graphics files onto a portable USB or firewire drive, and eliminating the need to ingest TIFs, TGA, etc. in the truck. This alternate new work flow is outlined as follows: New Workflow (B) Alternate: a. Graphics studio creates a series of animated graphics using computer graphics programs. b. These animations are rendered as a series of TIF?s or TGA?s and WAV files to a locally networked ?render folder?; at the same time, one or more CSMXc disk recorders on the same network are ?watching? the render folder(s), and simultaneously ingesting these graphics files ? which in turn automatically creates real-time clips, ready for review and approval soon after the rendering operation(s) are finished. c. Once the animations are approved, the 3-disk set is removed from the CSMXc(s) that was/were monitoring the render folder(s), and these disk set(s) are shipped to the truck(s). d. EIC installs the 3-disk set into the CSMXc; as soon as the machine is booted, the graphics are ready to play. e. TD programs the switcher EMEM to load and trigger the individual CSMXc clips. f. The animations are aired. Benefits of the new workflow: ? More streamlined, both in the production of the animations, and at time of ingest in the truck, by eliminating the variable of working with videotape. ? Much more accurate: video is 100% guaranteed to be aligned with Key every time, since the TIF?s or TGA?s graphics files embed the video with alpha in each frame of the clip. ? Slightly better picture quality is possible, since the animated graphics aren?t transferred to videotape, which degrades the images slightly (8-bit versus 10-bit resolution). ? Clip management is much improved, since each animation is a separate clip ID living inside the disk recorder (instead of one huge clip consisting of several animations). ? Adding new clips is much easier; just ingest new TIFs or TGAs with associated WAV file into the CSMXc. ? Switcher EMEM registers directly loads and triggers the clips inside the CSMXc, eliminating another variable in between the two. The roadblocks to implementing this new workflow (that I see; there could be others): ? Getting the animation studios to change their workflow. Although it will be streamlined by eliminating the need to create videotape(s). ? The import of TIF?s and TGA?s into the CSMXc in the truck could be a little slower versus ingesting videotape, perhaps being twice as slow. This roadblock could be eliminated in two possible ways: o Graphics studios purchase CSXMc?s and ingest the animations onto the real-time 3-disk set, and ship these disks to the truck. This involves the studios spending some money, of course, which could be a rather high obstacle to overcome. o Abekas MAY be able to speed up the graphic file import operation, by modifying the CSMXc firmware and/or software. There are some possible methods available to achieve near real-time ingest of TIF?s and TGA files. ? The EIC?s and TD?s would need to alter their workflow habits; but I believe the workflow would be made easier. These are my observations. You may have some other views to add, and they will be welcomed.

[quote="Douglas J"]The CSMXc is different from the FFV in this regard; you can indeed record all of your elements into ?one big clip? in the CSMXc, just like the FFV. However, unlike the FFV, you can also create separate clips in the CSMXc with each clip having its own unique identity (clip name), with its own internal timecode timeline (either LTC or TCN). One could then just program EMEM registers on the switcher to load and run each clip in CSMXc (see an earlier post of mine in this forum, on November 14, 2006 for more info). However, because of the reluctance of everyone in the ?food chain? to change their workflow habits (from graphics creation all the way to airing the graphics), the CSMXc?s in your application are still being used the ?old-fashioned? way ? in which all the separate animated graphics transitions are recorded into one big clip. It doesn?t have to be this way, but changing the workflow means changing a lot of people?s work habits. However, I advocate getting people to change, because it would certainly reduce a lot of unneeded work, make thing a lot easier, and make life a lot simpler. If you would like me to elaborate on my views for a possible new workflow in a future post, then please let me know. You can operate the CSMXc in exactly the same way as the FFV in this regard. You can either append to an existing clip (APPEND Record), or you can overwrite the existing material at the end of an existing clip (OVERWRITE Record). The timecode can be at 00 or 01 hour at the head of the clip, and the promos can be at hour 3 at the tail end of the clip. When you have fresh promo material for a new event, you simply select OVERWRITE record mode, park the CSMXc at the 3-hour timecode in the clip, and perform a record from the VTR with the fresh promo material into CSXMc. If you were to store the clips in the CSMXc in the ?new-fashioned way?, in which each transition is contained in separate clip identities (instead of inside one big clip), then you could easily use the backup/restore archival process with an external firewire drive in exactly the same manner as you do now with the SpotBox.[/quote] Hi again Douglas .... thank you for the through posts and explainations. I'm glad to hear that the operation of the CSMXc will become that much easier when it comes to adding on a clip with the new version of software that is going to be introduced. With regards to your suggestion to store clips in a "new-fashioned way", I think that is a must and the "food chain" needs make the necessary change in the workflow. The people I believe you refer to as the "food chain" are not operators, and while they purchase your products, they are not the ones who have to make them work everyday in the field. It is for this reason why I beleive this site exists... it's a place where we can share knowledge and ideas as "the users" in the field. I believe by sharing this knowledge it is our hope that we can try to influence manufactuers like yourself to make the products we use everyday that much better. Your posts here (at least for me) are very welcome and they have been very informative. With that said, I am in agreement with Scott. I believe we are not alone and there are others who would like to see the same type of clip/disk management you proposed above with the workflow change. I believe something like this that is vital to the success and further development of the CSMXc which will offer us the versatility we have been discussing here. If it is indeed possible to make one longer clip of the elements that are used every day ie: TD Elements and have them live for example (as I mentioned) at 00 or 01 hours on the disk. Then add the materials that change everyday to a different clip with a different timecode/name and have that also accessible via a emem recall at the same time, then you have answered my question as to the management of the drives. I should have clarified however, that on my FF drives, I control the timecode and where I put the elements I use. I do not use timecode from the videotape because sometimes we get tapes with the same timecode numbers. So I personally manage the elements I put to the drives using the Lance Controllers timecode. Some might not agree with this method, but this works for me especially since they are my own drives and I know how they are loaded. If this is possilble to do on the CSMXc as I believe you stated, then I think I can speak for everyone that this would be something we would all be interested in hearing about. By having one clip of TD elements and another clip of "Promos" and possibly another clip lets call it "Title Page", and they are all accessible via a emem recall, then that is what I was looking for. As for the archive of this on a external firewire drive, the only thing that would need backing up would be "TD Elements", the other clips (if they already aired) would now be done because they are outdated... so there would be no reason to keep them. And if we could "OVERWRITE" to the specific timecode on the drives then we would be managing the amount of disk space used. So please elaborate! I'm sure I'm not alone in making a better mouse trap and if change is required by the "food chain" to accomplish this and have the use of multiple clips, then we as "the users" have to make that happen.

Doug, Yes, please do elaborate on the proper way to use the CSMXc when we want yo use multiple clips. I don't thnk I am alone when I say I would prefer this. Scott

[quote="Rick Tugman"]Just for your information. I have done 3 shows now with the CSMXc.... the NBA game last year, a FOX MLB Game of the Week (because that was the only media available on the truck) and the PPV game which became a disaster. Each of these shows worked perfectly WITHOUT using a STOP command. All my shows are build exactly the same and the only issue I have had was on the PPV show after the clip was appended. It seems as if that can burn you if it's not done to spec.[/quote] The STOP command was an attempt to get around the problem of accidentally nudging the JOG knob on the Lance TDC-100 after cueing a register, which would then move the CSMXc off the IN point. Otherwise, the STOP command is not required. BTW, the new V3.3 software for CSMXc will automatically disable the JOG wheel on the Lance TDC-100 after loading a register, so the JOG wheel will then be unable to nudge off the IN point. [quote="Rick Tugman"]In the future I will look out for the proper LTC & TCN to be sure those values are correct. But it should be a little easier. I think what we are trying to say is .... it should just appened the clip (like in native mode) and we should be able to program after the addition.[/quote] Once the new software (V3.3) is released and running in the Mountain Mobile trucks, the CSMXc will indeed make appending to any clip a lot easier and more reliable, and you will be able to easily program the TDC-100 after the addition. You can even do this now, but just be sure to wait for the clip header to be rebuilt after the append record (which takes just a few seconds). [quote="Rick Tugman"]As for the drives and disk management..... I guess we have no choice in the use of different media for speed, but then lets compare the drives as you did to the FFV Drives. I fully understand how and why it requires the 3 drives and I like the "instant on" use of it, which is why I own my own FF drives. I also now understand the reasoning with regards to archive on other media especially when you take into account HD bandwith. The transfer times would just take too long as you suggest. But the problem I still see is the management especially if your traveling your own drives. By management I mean, controlling what clips are actually on the drives. What I'm not clear on is, if the playback of these clips all have to be in one clip or can the CSMXc decipher different clips on the drives in a playback mode.[/quote] The CSMXc is different from the FFV in this regard; you can indeed record all of your elements into ?one big clip? in the CSMXc, just like the FFV. However, unlike the FFV, you can also create separate clips in the CSMXc with each clip having its own unique identity (clip name), with its own internal timecode timeline (either LTC or TCN). One could then just program EMEM registers on the switcher to load and run each clip in CSMXc (see an earlier post of mine in this forum, on November 14, 2006 for more info). However, because of the reluctance of everyone in the ?food chain? to change their workflow habits (from graphics creation all the way to airing the graphics), the CSMXc?s in your application are still being used the ?old-fashioned? way ? in which all the separate animated graphics transitions are recorded into one big clip. It doesn?t have to be this way, but changing the workflow means changing a lot of people?s work habits. However, I advocate getting people to change, because it would certainly reduce a lot of unneeded work, make thing a lot easier, and make life a lot simpler. If you would like me to elaborate on my views for a possible new workflow in a future post, then please let me know. [quote="Rick Tugman"]Let's face it.... you need all your transitional elements, but you don't need the promo from last week. If you keep appending and adding on there is no way (that I see) to manage those clips and erase over them is there? For instance; using the BVW mode I put all my animated elements that I use each week at 00 or 01 hours on the Fast Forward Drives. I put promos at hour 3! Each week I place my promos on hour 3 "OVER" the existing promos therefore NOT adding on to the disk, but overwriting what is already there. Thus I'm not filling up the disk and I'm maintaining the amount of disk space used. When we use a SpotBox we have the advantage of also maintaining the files in which we backup by not sending over the clips we don't need to the backup firewire drive! It seems by appending the clips on the CSMXc there is no way to manage the disks load if you will! It seems that the disks just keep filling up and up and there is no way to actually manage what goes where. It is possible you can elaborate on this?[/quote] You can operate the CSMXc in exactly the same way as the FFV in this regard. You can either append to an existing clip (APPEND Record), or you can overwrite the existing material at the end of an existing clip (OVERWRITE Record). The timecode can be at 00 or 01 hour at the head of the clip, and the promos can be at hour 3 at the tail end of the clip. When you have fresh promo material for a new event, you simply select OVERWRITE record mode, park the CSMXc at the 3-hour timecode in the clip, and perform a record from the VTR with the fresh promo material into CSXMc. If you were to store the clips in the CSMXc in the ?new-fashioned way?, in which each transition is contained in separate clip identities (instead of inside one big clip), then you could easily use the backup/restore archival process with an external firewire drive in exactly the same manner as you do now with the SpotBox.

Hi again Douglas: This is all very good information and certainly makes using your device more understandable. It does sound like the Append on the additional clip messed up what had already been loaded and built. I thought that may have been the problem, but not being familiar with the box, I asked the second EIC to help thinking he knew what to do. It stands to reason that it all worked fine before, but after the addition (append) of the promo, which only took about 1:00, you would think you could go back in a just input the new cue points and continue. Just for your information. I have done 3 shows now with the CSMXc.... the NBA game last year, a FOX MLB Game of the Week (because that was the only media available on the truck) and the PPV game which became a disaster. Each of these shows worked perfectly WITHOUT using a STOP command. All my shows are build exactly the same and the only issue I have had was on the PPV show after the clip was appended. It seems as if that can burn you if it's not done to spec. In the future I will look out for the proper LTC & TCN to be sure those values are correct. But it should be a little easier. I think what we are trying to say is .... it should just appened the clip (like in native mode) and we should be able to program after the addition. As for the drives and disk management..... I guess we have no choice in the use of different media for speed, but then lets compare the drives as you did to the FFV Drives. I fully understand how and why it requires the 3 drives and I like the "instant on" use of it, which is why I own my own FF drives. I also now understand the reasoning with regards to archive on other media especially when you take into account HD bandwith. The transfer times would just take too long as you suggest. But the problem I still see is the management especially if your traveling your own drives. By management I mean, controlling what clips are actually on the drives. What I'm not clear on is, if the playback of these clips all have to be in one clip or can the CSMXc decipher different clips on the drives in a playback mode. Let's face it.... you need all your transitional elements, but you don't need the promo from last week. If you keep appending and adding on there is no way (that I see) to manage those clips and erase over them is there? For instance; using the BVW mode I put all my animated elements that I use each week at 00 or 01 hours on the Fast Forward Drives. I put promos at hour 3! Each week I place my promos on hour 3 "OVER" the existing promos therefore NOT adding on to the disk, but overwriting what is already there. Thus I'm not filling up the disk and I'm maintaining the amount of disk space used. When we use a SpotBox we have the advantage of also maintaining the files in which we backup by not sending over the clips we don't need to the backup firewire drive! It seems by appending the clips on the CSMXc there is no way to manage the disks load if you will! It seems that the disks just keep filling up and up and there is no way to actually manage what goes where. It is possible you can elaborate on this? For Jeremy .... Hi, thanks for the post. It sure sounded like the problem I had, This is all good information which I'm glad Douglas could respond to. All has been great thanks! I Hope the same for you. Best... Rick

[quote="Jeremy W"][quote="Rick Tugman"]During the set up of this PPV game I also I no problems programing and running effects until the second engineer set up to box to append the clip so I could add an element. After that the box was unresponsive and cues were all over the place. I re-entered all my cues but then it would not cue properly. Thanks![/quote] Hey Rick, Jeremy here. Hope things are treating you well. I was on MMT 7HDX recently discussing the ClipStoreMXc, and he imparted this piece of knowledge. When appending a clip that already exists on the ClipStore, allow at least 15 minutes after you have finished before you try to access any clips...i.e., go get some coffee and a donut. The drives seem to have to "rearrange" themselves after an append function, and running a clip during that time throws everything else off. Hope this actually helps!![/quote] Jeremy is referring to the "header rebuild" that?s required after the append recording. First, some background information: all clips in ClipStoreMXc are "wrapped" in a QuickTime Movie header file (.MOV), which points to the video, key and audio data files on the three separate disk volumes. After an append (or any) recording, this header file is automatically rebuilt by the CSMXc, specifically for the benefit of indexing the audio data file; the QTMovie file must know where every frame of audio is within the audio data file. Jeremy was told two myths: (a) there is no ?rearranging? of the disk drives; there is simply a rebuild of a single .MOV file; and (b) the time to rebuild the header file was EXTREMELY exaggerated. What dictates the rebuild time is the overall length of the clip after the recording ? the longer the clip, the longer the rebuild time. However, the rebuild time is typically measured in SECONDS, not in MINUTES; for example, it takes approximately 10 SECONDS (and not 15 MINUTES) to rebuild the header for a twenty minute clip! In the existing software now in the field, if one were to access the CSMXc via the Lance TDC-100 during the clip header rebuild time (immediately after ending a record), then that TDC-100 action can potentially corrupt the header file, especially the audio indexing and possibly even the LTC data. Therefore, the EIC's were instructed to wait until after the rebuild is finished before doing anything else from the TDC-100. There is a red warning message present in NetPanel during this header rebuild time, so the EIC knows exactly when it's safe for the next operation on the TDC-100. In the upcoming software update, the CSMXc will automatically provide a "Tape Unthread" status to the TDC-100 during the clip header rebuild time (which is analogous to an ?ejected tape? status in a VTR); the TDC-100 in turn will respond with a "Not Ready" status in its display during the header rebuild, resulting in a temporary suspension of RS422 communications with the CSMXc. As soon as the header rebuild is finished, the "tape unthread" status is removed by the CSMXc, and normal communications with the TDC-100 automatically resume. This process works like a champ, and will provide positive feedback to the TDC-100, letting the operator know that it's now okay for the next operation -- and ultimately avoids corrupting anything in the CSMXc. I hope this helps.

[quote="Rick Tugman"]During the set up of this PPV game I also I no problems programing and running effects until the second engineer set up to box to append the clip so I could add an element. After that the box was unresponsive and cues were all over the place. I re-entered all my cues but then it would not cue properly. Thanks![/quote] Hey Rick, Jeremy here. Hope things are treating you well. I was on MMT 7HDX recently discussing the ClipStoreMXc, and he imparted this piece of knowledge. When appending a clip that already exists on the ClipStore, allow at least 15 minutes after you have finished before you try to access any clips...i.e., go get some coffee and a donut. The drives seem to have to "rearrange" themselves after an append function, and running a clip during that time throws everything else off. Hope this actually helps!!

Hi Rick, We are planning to support Odetics protocol first, and then VDCP. Odetics protocol is expected to be released in the ClipStoreMXc sometime early next year; VDCP sometime after that. However, you can use PBUS protocol today to drive the ClipStoreMXc directly from the Sony 8000 (or from any switcher supporting PBUS). As you probably already know, 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 registers in the switcher itself; so when an EMEM register is stored or recalled, it stores (learns) or recalls the given PBUS command. BTW, the learned PBUS commands are stored in the ClipStoreMXc itself. In the Sony 8000, you 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. With PBUS control, you can either record a single large clip in 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?; or you can record multiple clips in CSMXc, each clip being its own VKA transition element. Each EMEM register can then be programmed to load the given clip and then play it with a trigger command. You can still mark an IN and OUT point within the clip using this scheme, but if IN and OUT points are not learned with the EMEM, then the entire clip will play at the time of 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, the Lance TDC-100 controls the video/audio via one RS422 port, with Key control via a separate RS422 serial port. 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. We are investigating a ?key offset? parameter that could be used to instantly (and virtually) re-align the key material at the tail end of the clip with the video/audio at the head end so the VKA elements all appear to be aligned from the point of view of the PBUS control port (and from NetPanel). However, I can?t promise this feature will be implemented at this time. Furthermore, if you append new video/audio and then key to the end of the ?mega-clip?, the ?key offset? will be rendered useless for the newly appended material. 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 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 TIFs or TGAs in a manner with which they are already familiar. 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. Maybe 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. Hope this helps.

Douglass, When do you plan on adding VDCP to the Clipstore so an external controller doesn't have to be used? I konw it's unfashionable to mention here :-) but I LIKE the 8000's internal machine control and do not like external controllers like the Lance (Please, no flames..... I'm just asking him a question) and therefore like the concept with EVS, etc of getting the clip names right on the 8000's screen. this will be a determining factor on choosing the Clipstore or the XClyps (which does VDCP). Thanks! RE

[quote="Rick Tugman"]Hello Douglas .... I for one appreciate your post here, but in all honesty some of the work arounds you claim solve problems did not work for me on a recent show. I recently did a PPV College game on Mountain Mobile's 11HDX. I had been on the truck earlier in the year and had no problems. During the set up of this PPV game I also I no problems programing and running effects until the second engineer set up to box to append the clip so I could add an element. After that the box was unresponsive and cues were all over the place. I re-entered all my cues but then it would not cue properly. Shawn who is the EIC on the truck suggested using the STOP commands so I rebuilt most of my show (after it was all working) to put these commands in. This partially worked but the CSMXc was still unresponsive and it ruined plenty of transitions that were supposed to be cued and they misfired continually. Again this was after it was working perfectly all afternoon. I became very afraid to run effects because they just did not cue and it was quite ugly having the matte run and not the fill. Sometimes it ran fine and most of the time it didn't. After continually getting burned we had no choice but to dissolve to everything bypassing your device completely. I'm not sure what the second EIC did, but this box has to be more user friendly to be successful in the market. Also your drives don't network with anything else on the truck making it very difficult to manage clips. By using three sets of drives you also make it very difficult for traveling personnel ... it's just more to carry. From what I have seen there is no software to manage what is on the disks and there is no way to save the clips on other media. Can you please advise what kind of plans are in the future especailly for archive? It would be nice for TD's & Producers to archive files to a firewire drive for easy transport and reinstall easily because there is little time in the sports world these days. Thanks![/quote] I?m happy to be posting in this forum, and look forward to some good dialog. I?m sorry to hear you had such a horrible experience with the CSMXc on your recent PPV job. It sounds like your problems began after the append record operation; I assume you were adding some new elements to the existing base clip that was already recorded and setup in the CSMXc. There are indeed some known issues with the append recording; specifically with regards to picking up the LTC from the end of the original base clip and carrying it forward in the new append recording. Ideally, you want the LTC value to pickup and ?flywheel? or ?regenerate? from the end of the existing base clip, in order to avoid placing duplicate LTC values in the new append record. If the LTC signal from the VTR is present at the LTC input to CSMXc at time of the append record, then that new input LTC signal will be recorded during the append record ? AND if there happens to be LTC values in the new append record area that are a duplicate of the LTC values in the original base clip, then you will have cueing problem, similar to what you described. The goal when appending a new portion onto an existing base clip is to make sure the LTC input signal is *disconnected* from the CSMXc LTC input at time of the append recording is made; this will ensure the LTC in the new appended segment of the clip will pickup and march forward from the end of the original base clip. I can?t speak for Shawn, but perhaps the LTC signal from the VTR was still present when the append recording was made. However, you (and everyone else in this forum) should know that if LTC gets messed up during an append recording, there is an exit strategy available in the CSMXc to get things right again, and get them right again very quickly: you can use the ?TCN? (timecode native track) instead of the LTC track, and then use the ?TCN OFFSET? parameter to match the original LTC timecode on the first physical frame of the clip. Here is the procedure to follow in the CSMXc NetPanel user interface, after performing an append recording, and discovering you may have duplicate or otherwise corrupted LTC values in the new recording: 1. Locate the LTC and TCN buttons, located just below the poster image. Make sure the LTC button is selected. 2. Cue the clip to the first physical frame of the clip. This is easily achieved by clicking the timecode number located in the rectangular box at the LEFT end of the clip playback slider inside NetPanel. 3. Make a note of the LTC timecode value at this first frame of the clip. The LTC is shown in large numbers below the poster image in NetPanel. 4. Now click the TCN button. This selects the TCN track instead of LTC for purposes of cueing from the TDC-100. 5. Reveal the TCN OFFSET entry field. This is done by clicking the ?REC DUR? button. This button may be set to ?REC DUR?, ?TCN OFFSET? or ?TCG PRESET? and then toggles back to REC DUR again. 6. In the TCN OFFSET entry field, click the mouse cursor and type the LTC value noted in step 4 above. Then press ENTER. This sets the TCN track to the same value of the LTC at the start of the clip. This value then instantly advances forward throughout each frame of the entire clip, including the newly appended segment. This offset value is saved with the clip, so it is recalled whenever the clip is recalled. This procedure may have saved you during your PPV event. But it should be noted that if your original ?base clip? had breaks in the LTC timecode, then those breaks will NOT be preserved in the TCN track; the TCN track values will always be contiguous. To address your other comments: >>Also your drives don't network with anything else on the truck making it very difficult to manage clips.<< The ClipStoreMXc features WinXP networking with two Gigabit Ethernet ports, so it can easily network with other devices on the truck; it may be a policy choice that Mountain Mobile has not networked the CSMXc in their trucks. The CSMXc also features an image Import/Export utility that allows one to import graphic files that are generated by just about any graphics system on the planet. TIF, TGA, PSD etc. files that include alpha can be imported to create real-time clips in the CSMXc. Audio WAV files can also be imported via this utility. >>By using three sets of drives you also make it very difficult for traveling personnel ... it's just more to carry.<< Being a frequent traveler myself, I completely understand the desire and the need to travel lightly. Obviously, the CSMXc is targeted toward applications that the FastForward formerly addressed in SD; but the CSMXc supports both SD and HD, with much higher picture quality than the Fast Forward machine in both standards, since the CSMXc records SD uncompressed and records HD with extremely high-quality JPEG-2000 compression; both with 10-bit resolution. This higher picture quality demands higher bandwidth and higher performance from the real-time media disk drives, which in turn requires one more disk than found in the old Fast Forward machines. The decision to use 3 disks instead of 2 disks is a cost/benefit trade-off. We could have engineered the product with two very high-performance SCSI disk(s), but then the cost of the product would have increased by a substantial amount. In today?s competitive marketplace, our customers will always choose a lower-price product versus one that is higher priced but features more convenient portability. I should point out that the three-disk set in CSMXc is just one more disk drive than found in the old FFW system, and yet these 3 disks still occupy about the same space as a large HDCAM videotape cassette. Of course, you need to be a bit more careful when transporting disk drives versus transporting a videotape cassette. >>From what I have seen there is no software to manage what is on the disks and there is no way to save the clips on other media. The NetPanel user interface can be used to manage the clip library, with a few minor limitations. Internally, the CSMXc uses the Microsoft WinXP operating system, with the Windows Explorer file manager also available for advanced media file management. One can use Windows Explorer (not to be confused with Internet Explorer) to manage the media files present on the CSMXc three-disk set; one volume is used for video (drive H), one for key (drive K), and the last for audio (drive G). All of the media clips are stored below a ?QTMovies? folder on each of these three disk volumes. Subfolders below this folder can be created in NetPanel for better clip management. >>Can you please advise what kind of plans are in the future especailly for archive? It would be nice for TD's & Producers to archive files to a firewire drive for easy transport and reinstall easily because there is little time in the sports world these days.<< The CSMXc features four Hi-Speed USB 2.0 ports, and some of the newer machines also feature 1 or 2 firewire ports. You can connect any off-the-shelf portable Hi-Speed USB 2.0 or FireWire disk drive to these ports, and then use Windows Explorer to copy/move clips from the internal three-disk volumes to the external portable disk drive. You may also use any third-party backup/restore program (even the built-in WinXP backup/restore program that?s included with the CSMXc can be used) to archive and restore the media clips to/from the CSMXc and the portable USB or FireWire archive disk drive. Just beware that this can be a rather time-consuming process, since the amount of data can be substantial. Each minute of a real-time clip with video, key and audio will be about 2.5GB of data. Furthermore, these archive programs add a substantial data transfer overhead that increases the time needed to backup and restore. Your comment ?there is little time in the sports world these days? is the driving reason why clients who use the CSMXc have decided to purchase spare three-disk sets rather than using a single USB or FireWire archive drive. This reason is speed. If you archive the media clips onto a single USB or FireWire portable disk drive, it may take upwards of a couple of hours to backup or restore just one media clip (depending on the length of the clip). This is in contrast to using a three-disk set that has a copy of the real-time media clip(s) already loaded on it: you simply plug the 3 drives into the CSMXc, and turn on the machine. As soon as it?s booted, you?re instantly ready for air. Bottom line: You can either have: ? ?Instant-On? event setup, with more disks to manage during travel by using the 3-disk set. ?or? ? Much slower event setup to restore the media clip(s), with just one disk to manage during travel by using a single portable archive disk drive. The choice is yours. Thanks for posting, and please let me know if there?s anything else you?d like to know or comment on.

Hello Douglas .... I for one appreciate your post here, but in all honesty some of the work arounds you claim solve problems did not work for me on a recent show. I recently did a PPV College game on Mountain Mobile's 11HDX. I had been on the truck earlier in the year and had no problems. During the set up of this PPV game I also I no problems programing and running effects until the second engineer set up to box to append the clip so I could add an element. After that the box was unresponsive and cues were all over the place. I re-entered all my cues but then it would not cue properly. Shawn who is the EIC on the truck suggested using the STOP commands so I rebuilt most of my show (after it was all working) to put these commands in. This partially worked but the CSMXc was still unresponsive and it ruined plenty of transitions that were supposed to be cued and they misfired continually. Again this was after it was working perfectly all afternoon. I became very afraid to run effects because they just did not cue and it was quite ugly having the matte run and not the fill. Sometimes it ran fine and most of the time it didn't. After continually getting burned we had no choice but to dissolve to everything bypassing your device completely. I'm not sure what the second EIC did, but this box has to be more user friendly to be successful in the market. Also your drives don't network with anything else on the truck making it very difficult to manage clips. By using three sets of drives you also make it very difficult for traveling personnel ... it's just more to carry. From what I have seen there is no software to manage what is on the disks and there is no way to save the clips on other media. Can you please advise what kind of plans are in the future especailly for archive? It would be nice for TD's & Producers to archive files to a firewire drive for easy transport and reinstall easily because there is little time in the sports world these days. Thanks!

[quote="Scott Dailey"]Hi Todd, I have seen this problem on the Clip Store. I think the problem lies in the way the Clip Store talks to the Lance. The Lance considers the Clip Store an Unknown Device. Watch what the Lance does at the end of a cue. When the cue has ended its run, (whether the Lance is in recue or stop mode doesn't matter) the Lance suddenly jumps in to Jog mode and both channels A and B begin flashing. If the Clip Store sits long enough before being fired again, it seems to doze off. The next play trigger only fires Channel A of the Clip Store. My solution was to insert a STOP command after my recue command, at the end of the timeline, which kicks the Lance out of JOG. I haven't had it misfire since. Abekas supposedly knows about the problem and is working on a fix. I hope this helps. Scott[/quote] Greetings all. I'm Douglas Johnson, the product manager here at Abekas for the ClipStoreMXc. I'll attempt to avoid all marketing of the product and simply address issues raised in this forum on this product. This thread has been referring to the "Abekas Clip Store" but is more precisely referring to the "Abekas ClipStoreMXc". I frequently abbreviate the product name as "CSMXc". I saw one poster in this tread (EricG) was unfamiliar with the product, so for his benefit: if you wish to learn more about the ClipStoreMXc, you may download the product brochure and User Guide PDF files from these two links: BROCHURE: USER GUIDE: Now, to get to the heart of this discussion: it's true there are some known bugs in the Lance TDC-100 interface to CSMXc. We are now on the verge of posting a software release that corrects these bugs (see release schedule below). As Scott Dailey has pointed out, there is a work-around for the Key-Channel mis-cue bug that started this thread: simply insert a STOP command at the end of the timeline. This communications bug will be corrected with the new software release (see release schedule below). Another known bug (or annoyance) was the fact that once the TDC-100 performs a CUE to a marked IN point, the JOG knob on the TDC-100 remained "active." This then presents a problem for the TD if he/she happens to nudge the JOG knob on the TDC-100 after cue-up; the CSMXc would then jog off the IN point. This bug is also corrected in the new software for CSMXc. Another large improvement we are making in the CSMXc is jog handling from the TDC-100; it will be much easier to perform fine jog control of the CSMXc from the TDC-100. This is useful while jogging around the CSMXc to set up new cue points on the TDC-100. In addition to these bugs, we've also corrected several bugs relating to APPEND recording and LTC timecode recording at time of ingest. The end result of our efforts is to make the ClipStoreMXc operate in this environment as best it possibly can. The EIC's at Mountain Mobile have been very attentive to interfacing the CSMXc into the live workflow in their trucks, and have been providing Abekas with very timely reports of bugs discovered. At the same time, we here at Abekas have been providing the EIC's with the best work-arounds possible during the time it has taken us to develop new software which will correct these bugs. I believe the Mountain Mobile EIC's have done a good job of communicting these work-arounds to the TD's. Now to dispel one rumor from Scott Dailey: Abekas is NOT modifying the software to accommodate VIDEO+VIDEO record/play in CSMXc. The hardware simply does not and cannot support this functionality, since the "key channel" pathway through the machine is luminance-only (no chroma capability). The ClipStoreMXc is designed simply as a single-channel/single-user "VKA" SD & HD digital disk recorder. It's true there are eight channels of 24-bit/48kHz digital audio on the machine; and can be routed into and out of CSMXc via embedded SDI digital video stream, or via discrete AES/EBU digital audio pathways. Lastly, the CSMXc supports both Sony BVW-75 protocol and PBUS protocol. If desired, one can drive the CSMXc directly from any switcher that supports PBUS protocol. We've sucessfully tested PBUS control (including Learn, Recall and Trigger) from a variety of GVG switchers, as well as the Sony 8000. V3.3 SOFWARE RELEASE: This new software is scheduled to be released within the next 2 to 3 weeks. We expect to send a "release candidate" to the primary EIC at Mountain Mobile this week. If all passes in his testing, then we will release the software the following week. If the EIC testing reveals any major bugs that we did not discover during our final tests, then the final release will come perhaps a week after that.

Bvw

[quote="Scott Dailey"]The Clip Store is a three disk DDR developed by Abekas. It is set up as One Channel of Video, One Channel of Key, and I believe 8 channels of Audio. The MTVG trucks are currently set up to do 2 Channels of audio. Abakas is supposedly rewriting the software to enable you to set it up as video-video. It can be controlled with the Lance controller or a DNF or a switcher or an editor. It can also be configured to be the controller of a cuts only edit system itself. So far it has had some problems, but probably no more than any other new device released to soon. Happy punching, Scott[/quote] Does it talk BVW or Odetics? Bill

The Clip Store is a three disk DDR developed by Abekas. It is set up as One Channel of Video, One Channel of Key, and I believe 8 channels of Audio. The MTVG trucks are currently set up to do 2 Channels of audio. Abakas is supposedly rewriting the software to enable you to set it up as video-video. It can be controlled with the Lance controller or a DNF or a switcher or an editor. It can also be configured to be the controller of a cuts only edit system itself. So far it has had some problems, but probably no more than any other new device released to soon. Happy punching, Scott

This might make me look like an idiot, but I have to ask, what Clip Store are we talking about? Is this just another DDR that can talk to a Lance controller?

5 words come to mind with the clip store .... "not ready for prime time"

[quote="tandrews"]Tom, the PBA show is the fastest Hour and Half in TV. I love it![/quote] Yeah dude. I did a couple of those shows last year and I don't think I'll ever have that much fun.

Late reply. Thanks Scott and Tom. I just had a dual feed last week for the first time in a few months and it happened again, only once, but it did happen. I will try to add a stop command to the timeline. Tom, the PBA show is the fastest Hour and Half in TV. I love it! Take care. Todd

I've definately had this problem and it's very interesting as well as frustrating. I've also had the thing crash/reboot on me a couple times while append-recording a clip. I can't believe how quickly they pushed this to market. They must've known at least some of these problems existed. I think they got the wrong idea from Chyron about putting out products that just aren't ready for mainstream. I guess they have to do what they have to compete. By the way, Todd. Congrats on PBA! That is a fun show.

Hi Todd, I have seen this problem on the Clip Store. I think the problem lies in the way the Clip Store talks to the Lance. The Lance considers the Clip Store an Unknown Device. Watch what the Lance does at the end of a cue. When the cue has ended its run, (whether the Lance is in recue or stop mode doesn't matter) the Lance suddenly jumps in to Jog mode and both channels A and B begin flashing. If the Clip Store sits long enough before being fired again, it seems to doze off. The next play trigger only fires Channel A of the Clip Store. My solution was to insert a STOP command after my recue command, at the end of the timeline, which kicks the Lance out of JOG. I haven't had it misfire since. Abekas supposedly knows about the problem and is working on a fix. I hope this helps. Scott