OK, so I should be able to do another SHIFT+B?

G

You can do Shift+B as often as you like. New frames will always be put into the preview buffer. If it happens to be full, Vegas will throw out old stuff. The memory size you assign determines how many prerendered frames can be kept at the same time.

It really only makes sense to assign memory you've actually got to spare. If your preview buffer uses up memory Vegas would have needed for its daily business, it'll likely slow things down rather than speed anything up. On the other hand, too small a buffer may mean Vegas constantly spends time caching frames that most likely won't be requested again before being overwritten.

Satevis : You can do Shift+B as often as you like. New frames will always be put into the preview buffer.

So what should I see in Memory section of Task Manager? The initial, say 8gb usage of RAM Preview being knocked down to make way for the now "next" SHIFT+B session? Yes?

Grazie

I think what you'd want is some form of "dynamic" RAM allocation for your preview RAM.
Why Vegas doesn't do this I have no idea.

Bob.

Thanks for that Bob.

What I am after is if I want to do RAM Preview, that's one operation. But then I may want to Render to a New Track. That's another Task. What I am finding is that Render New Track gets "stuck" in RAM with what is used it create that now non-volatile rendered out track. Meaning, render to new track steals RAM but doesn't release it. Build RAM Preview uses as much as has been allocated and ALSO doesn't release it, but it want I want to establish is will that RAM Building be over-written, removed, with further SHIFT+B actions.

G

"want I want to establish is will that RAM Building be over-written, removed, with further SHIFT+B actions."

My understanding is that once you specify the amount of preview RAM it is always allocated to that and never released. An additional SHIFT + B will overwrite it but not release it.

The above is based on the observation over the last few years that just having Preview RAM set to a value much above zero can impact stability i.e. running our of memory.

Bob.

Ok, so render to new track shouldn't hold onto the ram it used to render that track? 'Cos at the moment it looks like it is behaving the same way.

G

So what should I see in Memory section of Task Manager? The initial, say 8gb usage of RAM Preview being knocked down to make way for the now "next" SHIFT+B session? Yes?

When you start up Vegas, there is no preview buffer and no memory allocated for it. When you start playing the timeline, ask for a RAM preview, or render to a new track, the buffer will get filled up to the maximum size you set in the preferences. It will then stay at this size and be reused whenever necessary. I suppose the only way to release the associated memory is to reduce the preview buffer size in the preferences. Not sure when you'd want to do that, though. Maybe when you're running a few instances of Vegas and their combined preview buffer consumption is too much for your system to handle.

I think, by default, Task Manager's process list shows private process bytes. The Vegas preview buffer is considered shareable memory, so it won't be counted in the memory consumption attributed to vegas120.exe. Therefore, you'll likely see no drastic change in private byte consumption when prerendering a section (although, of course, there are other things that require memory apart from the preview buffer).

Ok, so render to new track shouldn't hold onto the ram it used to render that track? 'Cos at the moment it looks like it is behaving the same way.

It doesn't matter how you fill the buffer, whether by using the RAM preview, by just playing back the timeline, or by rendering to a new track. These will all use the same preview buffer, which will grow up to the specified size and which won't ever shrink under normal circumstances.

I think what you'd want is some form of "dynamic" RAM allocation for your preview RAM.

I know. :) In Syntheyes you can set a specify amount of RAM to hold frames for previewing. Since everything is rendered to RAM it's uncompressed for speedy playback. 232 frames @ 1920x1080 = 459mb RAM to preview in real time. Syntheyes dynamically puts frames in RAM for fast preview but then you've still got a lot of slowdown because removing frames from RAM and putting new frames from the hard drive in to ram is still slower then playing back from RAM, but faster then running straight from the hard drive.

So the solution in Syntheyes is the same as in Vegas: either lower the preview to fit more frames in the same amount of RAM (1920x1080 to 1/4 rez size @ 232 frames = 29mb RAM, so I could fit ~16x more frames in the same amount of RAM) or increase the RAM in the system to hold more at higher quality.

Those solutions keep the speed up, but dynamically swapping frames from hard drive to RAM is much slower.

"Ok, so render to new track shouldn't hold onto the ram it used to render that track?"

Yes.

"'Cos at the moment it looks like it is behaving the same way."

I know of no way of verifying that it's doing exactly the same thing but I have to agree what you're observing indicates something of that nature is going on.

----------------------------------------------------------------------------------------------------

Vegas and memory allocation and de-allocation does seem to be an ongoing issue.
The amount of RAM that Vegas will use and the amount of it hinted at by SCS as needed is way below what the three "A"s talk about. I've seen turnkey systems with 96GB and 128GB of RAM in them. Once we start talking about such large amounts of RAM it generally needs to be ECC (error correcting) RAM and you only find that on server grade mobos and thus CPUs. Whilst RAM is cheap today getting to have lots of it does get costly.

Bob.

Would you expect to see RAM reclaimed after Render to New Track?

G

It will be reclaimed by the next Vegas process that needs it. It won't ever be released as free memory.

So, I see Render to new track filling up on task manger to 11gb. I don't see it released, but you are saying that's ok cos the next thing I go will just keep using RAM even though I've appeared to exceeded my allocations. Is that what you are saying?

G

So, I see Render to new track filling up on task manger to 11gb. I don't see it released,

If you refer to the general memory figure (for the entire system) in the task manager: That shows physical memory usage, which says very little about how much memory your applications actually use. I wouldn't read too much into any changes you see there. Physical memory is entirely managed by the operating system, which will distribute it among applications, background processes, drivers, and itself as it sees fit.

That aside, the question is: Why would you want to have the preview buffer released? It's a cache meant to speed things up, so emptying it without need doesn't make much sense. If you feel an 8 GB buffer is too much for your system to handle, you can simply tell Vegas to use less in the preferences.

So, this cache for Vegas is replenished and replenished and so on and so on. What I am seeing in Task Manager showing Render to New Track get bigger and bigger is of no consequence to the smooth running of Vegas?

I should not think that Vegas is running out of space?

G

I've never noticed my system getting slower of Vegas crashing because the amount of RAM it uses in Task Manager - Process gets larger.

What I have noticed is that when I'm rendering, if it uses up to much physical RAM it crashes, but never while editing/playing back.

I should think it's an indication that Vegas could run out of space ... if it runs out of space. How much do you have left? Rendering (not RAM preview) may use the RAM preview allocated space for storing frames as they are generated, but the rendering process also uses memory for other things as well, and these other things will *not* make use of the RAM preview allocation. These are two separate usage streams that don't intermingle.

If you can't successfully render with the RAM you have left over after setting aside 8GB for RAM preview, you may have to considering a smaller allocation.

I am "successfully" rendering to a new track. WHat was/is concerning me is that any of this activity will bump into the workings of Vegas to . . er . . work?

At present I DO have GPU enabled and I am attempting to stress Vegas enough with

LARGE RAM Preview allocations

PLUS

Render to New Track

PLUS

the use of GPU Enabled FXing.

And the only way I know to monitor this is by way of utilising:

Task Manager's > Resource Monitor > Physical Memory .

Here I am looking at the "In Use"; "Standby" and "Free" Bar Charts. I see the Chart crunching and crunching up to the far right expecting to see Vegas crash. I see 200mb left, then 150mbs left then . . . 1 mb . . . then . . . 10mbs . . .

Grazie

What I am seeing in Task Manager showing Render to New Track get bigger and bigger is of no consequence to the smooth running of Vegas?

In terms of performance, the physical memory consumption is quite irrelevant as long as it stays well below the maximum. Once it gets close to the top and the free physical memory runs low, Windows will have to start some active memory management, which may (but not necessarily will) reduce Vegas' performance. In that case, a smaller preview buffer will likely make better use of your system's resources. But even so, running out of physical memory is a perfectly normal condition that shouldn't cause any crashes (unless you've disabled your page file, that is).

Have you ever had Vegas run out of RAM before?

How would I know?

G

Shift+B / RAM Preview $uck$ worse than Render to New Track. I want my RAM for editing. NOT set aside to hold temporary renders.

I would much rather do the same as most other NLE's and create Render Files. If things get to bloated you just click a button to delete them.