Place New Buttons on SpeedEDIT Main Interface

C

CreatvGnius

Guest
Provide a button directly on the SpeedEDIT-VT main interface that provides the an user easily-accessible BG RENDER On/Off toggle, so the Background Rendering function can be instantly switched on or off as needed.

This request is inspired by another user who suggests that "a lot of folks have had to resort to [going back into the Preferences panel] to avoid [undesirable] re-render craziness". :D

While on the subject of proposing a button be added to the SpeedEDIT-VT interface:

What of the "ADD FILES" button, that's located in the upper-left portion of the VT-EDIT interface for VT[4]™ : Such a button is not present in the EDITOR panel of SpeedEDIT™ (standalone). Is this AD FILES button also gone from SpeedEDIT-VT? Please advise, as we're still rockin' with VT[4] build 6016. TIA

-PeterG
 

jcupp

Grizzled Veteran
<CTRL> i opens the Add Media Panel. It's also found on the "Window" menu.

The BG Render thing I can't help.
 

ScorpioProd

XDCAM HD production
After talking with John more about background rendering, I'm starting to think it may be more a psychological issue than a real issue.

What I'm getting at is based on the entire concept of "background rendering" we really shouldn't care if it's going all the time, even if it's redoing things over and over and over.

John insists it should NEVER interfere with us continuing to do our editing. In fact, any BG rendering specifically stops as soon as you start doing something.

So, I guess what I'm asking is is there really a problem or not? Isn't it just that we can "see" it is doing it that makes us think there is a problem when there really may not be?
 
C

CreatvGnius

Guest
ScorpioProd said:
...based on the entire concept of "background rendering" we really shouldn't care if it's going all the time, even if it's redoing things over and over and over....I guess what I'm asking is is there really a problem or not? Isn't it just that we can "see" it is doing it that makes us think there is a problem when there really may not be?
Interesting query, there, Eugene. Gives one pause for reflection. I'm thinking, why have precious resources "re-render" that which is already rendered (if that's what's really going on) -- regardless of whether or not I'm currently doing something in the interface. :D ?
-PeterG
 

ScorpioProd

XDCAM HD production
I agree in an ideal world...

But what resources are actually being "wasted" that would matter? I mean, I'm assuming a few percent more of the CPU being used isn't wasting a lot of electricity, and if it's not affecting the "edit experience", does it really matter?

Here's an example of where it comes into play. Say you have a big clip that you cut into many pieces, and you set up transitions between all those pieces. Well, the way SpeedEDIT is designed, it still sees all those clips as ONE big clip internally, with ONE flag to know if something has changed, so if you change something on one of the little pieces that you CUT from it, it will re-BG render EVERYTHING on all of those SUB-clips.

That frankly seems dumb to me, but that's how it is designed to work, there is a flag that tells it something has changed in the clip somewhere and off it goes BG rendering again. John said this isn't something that could be easily changed.

IF these were all actual separate clips, this wouldn't happen. Thing is, by this very design decision, it seems to me that BG rendering is much more intended only to let you have the finished project play back in real-time, versus having the pieces of it you are working on be ready to playback in real-time.

I don't agree with that design decision, but then again, SpeedEDIT really needs to be on a fast machine to live up to its name anyway.
 
C

CreatvGnius

Guest
Jeff - thanks for that CTRL+I shortcut for ADD Files
ScorpioProd said:
I agree in an ideal world...so if you change something on one of the little pieces that you CUT from it, it will re-BG render EVERYTHING on all of those SUB-clips.

That frankly seems dumb to me, but that's how it is designed to work...
I don't agree with that design decision, but then again, SpeedEDIT really needs to be on a fast machine to live up to its name anyway.

'Seems to me, you've thought this out quite well, Eugene. I see your point.
-PeterG
 
Top Bottom