Another feature that would be useful...

Robert W wrote on 10/24/2008, 3:41 PM
There is another feature that would be useful to integrate into Vegas. This may take some considerable time to develop and the bug test, and properly beta test. It could even be quite tricky to implement.

Yes, you've guessed it, a render clock that is capable of telling you how many days it has left to render and has taken to render, rather than just rolling the clock back around to zero. I've got a render going at the minute that the clock has rolled around at least twice on, and I am actually only able to make an educated guess as to when it will complete. That is really unforgivable, pathetic, shoddy, coding and implementation. I dare anyone to try and rationalise that. It is just laziness and neglect.

So when you want to bring me in to point out all the rest of the niggly things, just drop us a line Sony. I can work quite cheaply.

Comments

TheHappyFriar wrote on 10/24/2008, 6:36 PM
i'm sure this falls under the "if it WAS that simple it would of been done by now". but shoddy programming? Odds are vegas has a separate variable for hours, minutes & seconds. That could be 3 variables. Add day's that's a 4th. Months that's a 5th. Years that's a 6th. That's a lot of code to go through to add in three new variables that most likely no one will ever use, and definitely won't make the program any better to use.

Chienworks wrote on 10/24/2008, 8:24 PM
Unlikely. It's far more likely that it has a single variable for "time", and that the display subroutine pulls the hour, minute, and second values out of this single variable on each update. The hour display probably uses modulus 24 to keep it in the 00-23 range. It's possible that simply removing the modulus function would allow the display to show times up to 99 hours, 59 minutes, 59 seconds with no other changes. It might even go up to much higher values if the hour display isn't limited to 2 digits.
Robert W wrote on 10/25/2008, 2:19 AM
There is no excuse for it. It takes more effort to get it to roll over than it does to just display the number of hours. Actually I think it would go beyond 99 hours if it was not told to roll over, and from memory there is space for it to do that on screen. Either way, this should not create an issue as the routine for writing those characters to screen are handled by Windows rather than the program. It is simply dumb programming and design that cause this elementary and easily resolved issue to remain. To me it is typical of a development programme that is not actually paying any attention to the needs of it's users. In all the time they were developing and "testing" pro-titler, 8.1, avchd, the multi-cam and blu-ray support, they did not have five minutes to tweak the code to make that timer return the correct figures? I personally find it quite insulting.
johnmeyer wrote on 10/25/2008, 3:36 PM
Estimation is not the strong suit of this programming team. DVD Architect even now still can't even come close to correctly estimating the size of a DVD project. I hate to think how many newbies cut something or re-jiggered their project just because DVDA told them it was too big to fit, when in fact it would fit, and with plenty of room to spare.

As for the time estimate, doesn't the progress bar give you what you need? I concede that it doesn't give you hour, minute, second "accuracy," but quite frankly, such supposed accuracy would be completely misleading. Why? Because getting correct estimates during a render is pretty much impossible. Each fX adds differing amounts of time to a render, and even the settings within an fX affect rendering time. (See Results of render times for ALL Vegas fX). The interaction between dozens of video tracks, 3D, compositing, etc. make it almost impossible to estimate, I would think. I have seen projects where the render goes zipping along, and then hits a section where I have some of the things mentioned above, and suddenly I'm only rendering one frame a second. Then, after it finishes that section, it goes back up to real time or faster. Since there are an almost infinite number of variations of stuff that can be done on the timeline, I honestly don't know how even the sharpest programmer could provide an estimate that is accurate enough to warrant spending the extra time to implement more code.

Having said all that, the clock really shouldn't reset after twenty-four hours. That's just plain dumb.