Articles

The new version of Media Composer - 3.5 - is out, which means end of development for the 3.1.x line. This is significant in one little aspect.

Back in v. 3.1 I noticed something that was really hard to miss: if there was a FireWire deck connected to the computer, you'd get a C++ Runtime error right after you quit the application. it read: "Microsoft Visual C++ Runtime Library. Runtime Error! Program: ...ramFiles\Avid\Avid Media Composer\AvidMediaComposer.exe. R6025. - pure vertual function call" OK.

Here's the picture.

Avid techsupport confirmed this as a bug. Indeed, this was 100% reproducible - hard to miss. Not a showstopper by any means, just an annoyance really. Nevertheless this problem somehow slipped past QC. Well, surely it will be squashed in the next release, right? Not so soon. Version 3.1.1 came out, then 3.1.1.1. The bug was still there. Now the last of the line v. 3.1.2 is out and semi-obsolete and the bug is still there! Obviously, making Media Composer bug-free is not an absolute but subject to prioritizing.

Long time ago, or at least longer than I care to remember, Avid introduced tree different project locations - private, shared and external. Most of the standalone users nave have to venture beyond the first two, but if you are on MediaNet you'll be no stranger to external projects. Starting with the much celebrated version 3.0 there has been what I would call an Empty External Path Bug. Basically, if you never accessed an external project before, your path for that location will be empty - it is saved in MCState file in case you wonder. If you attempt to create a new project in an external location under such condition, Media Composer will fail project creation but will present it as a failure to open the new project. The error you'd get is one of those obscure access violation errors and only after o'keying that you'd see "Couldn't open project" message. This is what it looks like, take note of the empty line for the Folder:

As I said earlier, this started happening back in Media Composer 3.0. It was strange to see that, for it was not the first year since Media Composer was paired with MediaNet and one would by now expect Avid to know how to handle such a trivial scenario. Nevertheless I dutifully reported this error hoping they will fix something this simple right away. This bug is still present with version 3.1.2 which is five(!) versions later.

Speaking of MediaNet, the release of Vista and 64-bit compatible MediaNet client went a long way ensuring the value of older 4.1 and 4.2 Unity installations. It was a godsend salvation for all facilities trying to stay updated with Media Composers but for various reasons, mostly legacy, having to keep older Unities. Certainly an upgrade opportunity should not be stalled by older Unity software and Avid released the 5.0 client compliant versions - 4.1.6 and 4.2.4. But did they really? If you start downloading the installation files you'll see that they both end on 'RS1': MediaNet_4.1.6_RC1.zip and MediaNet_4.2.4_RC1.zip. Those who are familiar with versioning in software development will immediately recognize that 'RC1' stands for 'Release Candidate One', which is one version above beta, but is not yet final, stable release. Avid is not getting back to those versions of Unity fixing anything and getting stable versions out.

Avid's priorities these days seem to be in getting out new Media Composer features as fast as possible. It is certainly commendable. Better XDCAM and P2 support is long overdue and version 3.5 addresses just that. Happy now? Well, not if this means we have to put up with all the known but ignored bugs.

Long time ago Avid had a "Boat shop" tutorial, which, among other things, praised the "Yankee ingenuity, industriousness". If those are truly qualities of New England Yankee's, it may be totally logical to move Media Composer development offshore.