This worked fine until I added an assignable effect. After that I got the same error. Do you have an assignable effect in your project? It appears to be a limitation in the Script API. I ran into this problem while developing Ultimate S. There is no way to determine that a Bus is an Assignable FX or just a regular audio Bus via the Script API.

To reproduce this, create an empty project. Add nothing but an Assignable FX. Run Export XML. Now run Import XML. You get the error.

[Edit] On closer inspection of the script, it is assuming that you only use Buses and not Assignable FX and throws an exception when it sees a Bus name that is not Bus A, Bus B, Bus C, etc, Assignable FX are named FX 1, FX 2, etc. (not that it could create an assignable FX anyway because the Script API doesn’t allow it.)

~jr

Ahhh...that rots.

Yeah, I have assignable effects. AND I regularly rename the buses to something that makes sense, like "Drums", "Guitars", "Vocals", etc...

There's a lot of power in the scripting API, but a lot of surprising limitations, too.

Oh, well...I found a workaround for the problem that was leading me down the XML path, anyway. It wasn't fast or pretty, but I got 'er done.

I've submitted a request that we be allowed to change the media file on an event-by-event basis...not just globally replacing one file with another.

Thanks for the input...at least I know what the problem was now.

> AND I regularly rename the buses to something that makes sense, like "Drums", "Guitars", "Vocals", etc...

Just to be clear on my post, the renaming of a Bus to something like Drums or Guitar does not affect this script. The Name I was referring to is an internal name that only the Script API sees. When you rename a Bus, your are actually modifying the Description field in the Script API. It was just the fact that you had an assignable FX that caused the script to fail.

~jr

Oh...duh, of course. I wasn't thinking.

Nevermind.

Thanks for taking a look at this Johnny - although my situation seems to be slightly different from what you have found, you have thrown enough light on things that I now have at least some idea where things seem to be going wrong in my case.

In my case I was still getting the error even when I just used the simplest possible test project I could imagine - a single audio event with no video events at all, and no assignable effect chains either. But on seeing your message I looked again at the exported XML file and noticed that it was specifying 3 Bus Tracks (1 video and 2 audio) because I have my default project settings set to use 1 stereo bus (on the Audio tab of Project Properties). (The 2 audio busses are "Master" and "Bus A.") I decided to investigate varying the number of audio busses to see whether that would help me to see what was going wrong.

I found that by changing the number of audio busses in the project to zero I was finally able to export a test XML file that would import successfully without giving an error. I find that if I have any audio busses at all (other than the default "Master" bus) then I get the error message detailed in my original message when I try to import the file.

This is better than it was before - at least I can now create projects that can be imported via the XML scripts without causing an error - but only if they have no audio busses or assignable effects chains. Which is worse than you seemed to be finding - if I understood you correctly you were able to use multiple audio busses, just not any assignable effects chains.

I'd be very grateful if you could shed any further light on what might be going wrong in my case. In case it is of any help I've posted a test XML file of an extremely simple project which will not import without giving an error on my system. It consists of just one audio event, which is just the Windows XP Startup sound (so it should be available on all machines) - no assignable effects chains, one audio bus and nothing else at all. I'd very much appreciate it if you could see if it will import on your system. It can be downloaded from http://www.whippey.eclipse.co.uk/test.xml

Many thanks if you can offer any further insights.

Mark

Mark, I can tell you exactly what’s going wrong and how to fix it without any test xml. Remember I said that there is a check in the ImportXML code that makes sure that the Bus name that was just added matches the Bus name in the XML file. The reason it fails for you is because you have Buses inserted by default into your project BEFORE the script is run. (the script boldly assumes the new project is empty of any tracks and buses)

Here’s what happens: You create a new project. It inserts Bus A and Bus B because you changed the defaults to add two buses. You run ExportXML on this empty project and it exports two Buses A and B.

You run ImportXML. It starts a new project and that new project creates Bus A and Bus B as per your default. The script then reads the XML file, which instructs it to add Bus A. It adds a Bus and Vegas assigns Bus C to this Bus because there already is an A and B. The Script checks to see if Bus.Name(“Bus A”) equals Bus.Name(“Bus C”) and it does not! Bam it throws and exception and stops.

The fix, of course, is to modify the ImportBusTrack function to not check for this. If you comment out lines 276 and 277 in the script (by adding a // in front of them) this check will not be made and the script will continue.

The bigger problem is: Why are you using ExportXML in the first place? It doesn’t save many things about your project. In particular, it has no idea what settings you used on your effects. So while you might add Color Curves with the Warm Colors preset, it is not saving that information! It will add back Color Curves (and any other effect for that matter Audio or Video) with the (Default) setting! I don’t think this is what you want.

I just don’t think you’re getting what you think your getting accomplished by using these scripts. They are really just examples of what could be done with scripting and should not be expected to save a project the same was File->Save does.

Just curious why you are using this.

~jr

Brilliant! Many thanks for that explanation Johnny - it has been nagging at me for a while that I couldn't understand where the problem was. Just as you say, if I knock out the two lines that check for the bus name match the XML file imports just fine.

> The bigger problem is: Why are you using ExportXML in the first
> place? It doesn’t save many things about your project. In
> particular, it has no idea what settings you used on your effects......

I can see not much gets past you :-). OK, here's the whole story. A colleague of mine is a proper professional sound engineer (I'm just an amateur) and in the course of his work he needs to move projects between various hardware platforms - AVID, ProTools, Sadie, etc. For some of the projects he works on it would be extremely useful if he could do as much of the work as possible on a notebook PC at a variety of locations, doing whatever can't be done on this stripped-down, highly portable setup later, either on his own Sadie setup (movable, but not portable enough for this particular purpose) or on a ProTools system or other DAW setup elsewhere.

As he knew I was familiar with Vegas he asked me if I thought that it would be able to cope with what he needed and I said I thought it probably could, subject to being able to get the various projects into and out of Vegas without losing too much of the detail they comprise (these project files are usually in the form of OMFs) and that fortunately the software he was already familiar with for transferring these OMFs into and out of Sadie (EDLConvert from Cui Bono Soft) was also able to transfer projects into and out of Vegas by converting the OMF into an XML file that could be imported/exported using suitable scripts included with EDLConvert.

He obtained the demo version of Vegas and was able to prove (as far as he could using the demo) that he should be able to achieve what he needed using a combination of Vegas and EDLConvert. He was about to go ahead and purchase Vegas when I suggested that we could make absolutely sure by checking that he could import one of his converted projects into my (non-demo) installation of Vegas. So he brought a sample converted project over to my place and we attempted to import it using the EDLConvert import script, at which point we ran into the problem I mentioned. (Which I now know did not occur on his demo system because he has not changed the default number of audio busses as I had, of course.)

After a bit of investigation it became clear that the XML Import/Export scripts provided with EDLConvert were in fact merely very slight variations on the standard Import/Export XML scripts that are shipped with Vegas, and that the same import also error occurred when using the standard scripts. After trying and failing to resolve the problem on my machines I decided to post my original message in this thread to see if anyone could shed any light on it, and in order to simplify things I left out everything about the EDLConvert apect, merely saying that the error occurred with the standard Vegas Import/ExportXML scripts.

In the end the problem that occurred on my machines didn't dissuade him from going ahead and purchasing Vegas and he is now happily able to transfer OMF projects into and out of Vegas to allow him to do the kind of things he had hoped to be able to on a nice lightweight portable DAW setup - the last I heard everything was working as well as these things can be expected to. Effects settings and suchlike are of course specific to particular host systems so they can't really be transferred perfectly, but the vital stuff - event and track names, event locations, levels, fades, pans, etc, can all be transferred between the various systems he uses without losing/corrupting anything important.

Hope that explains the motivation behind my original question and many thanks again for explaining the reason why I was experiencing the problem. Many years ago I used to do some programming, but I don't seem to be able to get on with the modern style of languages like JScript for some reason - I spent a long time looking through the code but I couldn't see why it was failing at all until you explained it, at which point it suddenly became obvious, of course. I was much better in the days of 6502 and Z-80 assembler code.

Mark

Wanders off muttering: "In my day we didn't have all these fancy objects, classes, etc - all we had was ones and zeros. And sometimes we didn't even have ones."