@pierre-k

Which options for the DPI scaling did you select in Options/Preferences/Display?

I tried everything.
In the first attempt I turned everything off and in the next attempt I turned everything on.

I don't use DPI primarily because I don't have 4k monitors.

Oops, I now have repros without text scaling though the speed of clicking and deleting (empty) events must be rather high then.

I told you all for 5 years that the mistake existed! 😺

Marco, try to reproduce the mistake on a more complex multi-track project.

Hi guys,

Juist fyi, I am living in Dubai, UAE here so the time difference is quite drastic.

Thanks for following up everyone. OK to answer above:

Marco.

I have scaling always set to 100%. So I am afraid that is not a factor.

Although I see you have now eliminated that as a factor and are able to repro. I am glad you are finally able to repro this. See my note below about the speed of the repro. And thanks again for following up.

Pierre.

There is definitely a difference when the preview window is closed. I just spent 5 minutes doing my usual split split split delete routine, on generated media and did not get a lock up. As soon as I put preview back on, I was able to repro within 30 seconds.

I cannot say 100% that the issue does not exist without preview on though. Will need to do longer tests.

Odd that even with an empty video (created within Vegas), having the preview window closed does help. The thing is, it is not previewing anything, as it is just an empty video. So why would that have any effect?

One thing to note about the speed of the repro. I (like many of us), have been getting this issue during regular work, for a a number of years. The thing is, it may take 30 minutes (or more) to manifest because normally, splitting and deleting with ripple on, is done much less often, maybe every 10 - 15 seconds (for example), sometimes much less, if no bad edits are required to be removed.

It is only now that I decided to follow it up aggressively, that I realise it can be triggered very quickly by doing the procedure quickly. This indicates some kind of build up.

Undo buffer maybe? There seems to be no way to turn off or lower the number of UNDOs (not that I would really want to), apart from in the "Internal" options, you can disable effects undo. I did that, it made no difference. (nb I cannot access Internal Options using V18 trial).

I have a session in the studio today so will not be able to test anything else until later. I hope this helps.

Cheers, Phil.

 

@Phil_P

"I cannot access Internal Options using V18 trial."

Yes you can. They moved it up a notch. Just hold the Shift key while selecting Options with the mouse.

@Phil_P

"I cannot access Internal Options using V18 trial."

Yes you can. They moved it up a notch. Just hold the Shift key while selecting Options with the mouse.

Thanks John, I am just trialling 18. So didn't look too carefully. I just did the usual Preferences with SHIFT held down and didn't see it in the dialog tabs. So presumed it was a limitation of the trial version. And unfortunately Undo level is not changeable there anyway, (as mentioned above).

What do you think about the actual issue that this thread is about? Can you repro it?

@Phil_P

"What do you think about the actual issue that this thread is about?"

I never work that way. I'm retired, so I have more important things to do...

@Phil_P

I will write a macro today which would do frequently clicking and deleting. That way it should be more easy for others to repro (if they are willing to use this macro). It won't be written for others, though. I will use the macro to make it easier to check different conditions which may or may not influence the issue.

@Phil_P

I will write a macro today which would do frequently clicking and deleting. That way it should be more easy for others to repro (if they are willing to use this macro). It won't be written for others, though. I will use the macro to make it easier to check different conditions which may or may not influence the issue.

Good idea. I usually use a tool to do automation for QA testing. It can look for screen elements, images and all sorts of other things. In fact I ended up developing lots of useful stuff from that, some of which makes me a few pennies.

But a specific Macro within Vegas will be useful for testing this for sure. :-)

Right gotta dash, session beginning. :-)

In a complex project, the error is almost instantaneous.

I now have a macro which in a loop does a left mouse-click, wait 500 ms, press Delete, wait 500 ms, start anew until I press a certain button.

This way I can proper repro the issue. Also I already found the timeline cursor doesn't need to be placed over the event which will be deleted. I have same repro if the (running) timeline cursor is set far to the right while the event deleting start from the left.

Also I already found the timeline cursor doesn't need to be placed over the event which will be deleted. I have same repro if the (running) timeline cursor is set far to the right while the event deleting start from the left.

Great stuff on the Macro Marco. :-).

Yes correct, delete does not have to be under cursor. I discovered that this morning and was going to re-test later on.

Pierre, also good (although sad) to see the exact problem so clearly represented.

@pierre-k

I can confirm your observations. After Vegas Pro freezes it seems like on my notebook it always lasts exactly 105 seconds to recover.

Also, I started testing with a single track filled with empty events (thirty minutes total, 360 empty events). It then takes between 2 and 4 minutes until the freeze happens.
But when I simply copy same track three times (so four same tracks now) and start testing anew, the freeze now happens within two seconds.

To me it seems like both the settings for RAM Preview as well as the number of render threads strongly affects the issue. Not in the way that a certain setting would prevent the freeze but different settings cause noticeable different times until the freeze happens.

Gentlemen, I have other interesting information for you !!!!

VEGAS 10 64bit VS VEGAS 18 64bit

In VP10, an error does not occur during normal editing with Auto ripple on.
If I want to reproduce the mistake, I have to edit really extremely. But this is not realistic in practice. In the example, an occasional freeze is evident during the extreme shift of entire blocks of events. But Vegas always recovers after a while and continues to work.

In VP18, 20 seconds of erasing on only one track is enough and the program freezes.

During the VP10 test, I noticed another extreme difference with working with files in folders.

In VP10, you immediately mark all the files in the folder (Ctrl + A). In VP18, it takes a very long time and Vegas freezes for a while. But that's a different discussion.

I think this discussion is very crucial for the Vegas team. These examples show that some functions deteriorate over time.

Now I'm going to test VP11 and VP12

Great stuff guys. In my experience when things start to get slow like this it is usually related to caching or as mentioned earlier the UNDO buffer.

In some of my DAW software you can set the amount of UNDO from 0 to infinity. I can see no way to adjust undo in Vegas. So cannot really test that.

Sorry I am still rushing here but will have more time to dedicate to this tomorrow. Really appreciate the work chaps.

VEGAS 11 64bit VS VEGAS 12 64bit

1. Auto ripple problem.
VP11 has the same behavior as VP10. So (relatively) great!
VP 12 - the problem begins in this version! Same problems as in VP13 / 14/15/16/17/18.

VP 11 Auto ripple - All tracks

VP11 Auto ripple - Affected Tracks

(I could go on like this for another two hours and I would be happy! 😺)

2. Delays with selecting files in folders.
Great and instant - VP10 / 11
Longer delays - VP12
Terribly long delays with momentary freezing - VP 17/18

VP10/11

VP12

VP 17/18

If the guys on the team manage to accelerate the new Vegas to the level of VP11, some users will be very happy!

I really want to thank Phil_P and Marco very much.

This is the first time that someone has worked with me so intensely on this issue.

I suspect that the goal is very close.

The problem with comparing different Vegas Pro versions is you may have changed a hundred conditions without knowing which ones.

But we get closer, yes.

I really want to thank Phil_P and Marco very much.

Me too to thanks you guys. I started this thread a while ago and resurrected it recently and appreciate the support.
I have had a few experiences like this in QA/Beta testing. Where the cause of an issue has been very hard to find. But once you get 3 or 4 good people on it we will solve it eventually. :-)

Ok so I tried changing some Preview Device options. No difference. Able to get the lockup in basically 4 deletes.

It was mentioned already but may be worth pursuing: I also tried clearing the Edit History but difficult to decide when that should be done, (after how many deletes).

1. I cannot get a repro with Preview OFF (so far). And if I put preview back on I can repro in seconds.

2. Lockup seems to last 1min:45sec every time.