I replaced Vegas.Cursor with Vegas.TransportCursorPosition in the above script. Would not work at all, so I reverted back.

Did you make a typo in your reply or did you enter TransportCursorPosition as a single word? The object reference is your Vegas object then Transport, then CursorPosition.

Vegas -> Transport -> CursorPosition.

Yes, I did make a mistake. I entered it correctly and it did work on my first attempt. However, my second attempt produced the same error message as shown above. I tried other movement scripts and they worked OK again. That's what so maddening--they work MOST of the time, until they don't with the error message shown above. It's not a showstopper by any stretch--just annoying. As I said before, they work reliably with V10, but not V12.

wwaag

Does ANYONE have any idea what might be happening? I continue to get these scripting errors forcing a reboot of V12. Works OK for a few times, then the same issue. Again, these scripts work perfectly in V10. I've uninstalled New Blue Titler as well as Office 2007 as others have suggested these might be problematic--same result. Any suggestions would be greatly appreciated. I'm hoping that reverting back to V10 is not the only solution.

wwaag

Try initializing the variable addFrames before the switch statement (maybe set it to 0? whatever makes sense). If your frame rate doesn't get handled by either case statement, it will be some arbitrary "garbage" value which may be causing problems.

Also for floating point comparisons it's better to use an "epsilon" because a floating point frame rate may not match exactly for all of the digits. For example, use something like 29.97 +/- 0.01 for the first test case and 59.94 +/- 0.01 for the second. Here, 0.01 should be sufficiently small so that a frame rate of exactly 30.00 won't erroneously pass the test for an NTSC frame rate (maybe 0.005 is better). Then you'd use an if statement instead, to check whether the frame rate is close should look something like the following:

if ( ((29.97 - 0.01) < ProjectFrameRate) && ((29.97 + 0.01) > ProjectFrameRate) )
{
addFrames = 90;
}

else if ( ((59.94 - 0.01) < ProjectFrameRate) && ((59.94 + 0.01) > ProjectFrameRate) )
{
addFrames = 180;
}

else
{
// default value
addFrames = 0;
}

Initializing the variable makes sense if your Frame Rate is something other than the two conditions you have accommodated in your switch statement. Have you looked at the frame rate value to verify that it is being handled properly?

Thanks for the replies. These are the only 2 frame rates that I use and yes, I believe they are correct. Again, these scripts work PERFECTLY in V10e--never a crash. My suspicion is that this problem is another manifestation of how Vegas handles memory. Even the error message suggests that memory may be corrupted. Whenever this occurs in V12, I usually close Vegas. Even though I close it, the error message pops up that Vegas had to close. When I restart, the scripting generally works for awhile, although not always. This is OK for short projects that load quickly, but for longer ones that take minutes to load, it is unworkable. I've decided to go back to V10 for my initial cuts editing that requires frequent use of these scripts, and hopefully wait for an update that fixes the problem. It's frustrating, but having read other threads, I guess I'm not the only one having problems with V12.

wwaag

Incidentally, in coming up with the exact values for frame rate, I used a script that would display these using MessageBox.Show for the Vegas frame rate variable.

I really don't believe it's a good idea to try and perform switch processing on the value of floating point numbers. Are you comparing floats vs floats, or doubles vs doubles, or floats vs doubles. Are you using enough digits of precision, or too many. Trying to do an equality test on the absolute value of a floating point number is prone to produce errors.

Try adding a "default" case to your switch statement and set your time variable to a timecode value of zero. If you are not correctly handling the other cases this will add a zero offset to your time and eliminate your errors.

Per your suggestion, I added a "default" case so the change is zero. Also a MessageBox to show that something fouled up. I added these to all of my movement scripts. I then opened a simple project and began cursor movements. Finally, the dreaded error occurred. After that none of the other cursor movement scripts would work. In fact none of the other scripts would work--e.g. batch render (the one included with Vegas), deshaker, etc. that I use all of the time. At that point, restarting Vegas is the only solution--and even then, not always.

Again, I never have this problem with V10--only V12.

wwaag

I'm beginning to wonder if this isn't another problem showing up when you perform a cursor position change. For example, if you are having a compatibility problem with an older FX plug-in, it might not show up until you move the Vegas cursor over an Event that has the problematic plug-in assigned to it.