V13 pro: Masking, Keyframes, Properties & bulk changes

[Phil Peacock]

I will be adding my vote too. This has been an issue for me also in the past and I found myself begrudgingly amending every single keyframe and at the same time thinking that I must have missed something obvious! So, thanks for raising this.

[Norman Black]

I know what you are asking for and which specifics. I am just point out that UI design is looked at in an orthogonal manner. Just saying I only want to change certain ones does not cut it. If this were implemented then how you you indicate to the user which things are allowed to be changed and which not.

Your screen show shows text entry fields. I already stipulated in a previous post that there are mechanisms that can work for these types of UI items. How are graphic indications shown?
Consider these screen shots.
mask1.jpg
mask2.jpg

Two mask keyframes, both different. If your app allows you to change parameters of multiple keyframes then how do you display the differing mask values in graphical form. Which are mask, positive/negative, feather type, feather amount slider. Not an easy answer and it should be obvious to the user what is going on and what is allowed or not. Notice that the text fields panel does not need to be displayed. I personally normally leave it off for more screen real estate. One cannot ignore that fact that the text info panel may not be available.

I agree that a multiple select and letting us change a text entry field is about the simplest way to seamlessly integrate into the existing user interface design a way to change some parameters. One can always add a new dialog to let one do such changes.

This change is a special mode, but at design discussions, consistent orthogonality is a common theme. Special modes are not orthogonal and one then has to deal with different application behavior in a mask multiple select in the text and graphics views when something is changed in text or graphics.

But that is me and I do not have to deal with the average Joe user out there.

Remember my comment about the FX bypass button. That is a sticky button. It sticks across projects and across invocations of Vegas. People click that and then forget they clicked it, or expect it to not be sticky, and end up in the forums, or contacting support, asking why are my FX no longer working. Ctrl-Z don’t help in all UI cases.

[Doug Jackson] “Sorry, but I don’t get how adding this feature is somehow an additional support burden. If your logic was applied, I doubt there would ever be many new features rolled out because, well, they would be too difficult to support. “

Well if you take my statement to a reductio ad absurdum argument, I guess to can conclude that. Or turn my statement to 11, to analogize Spinal Tap.

I clearly said “some hammers”, and yes EVERY feature added to programs has costs. Sometimes you anticipate additional support events, which are a cost of sorts. You always weigh cost benefit, make your best educated guess, and you may or may not go forward. It is a business trying to max profit after all.

You have to consider who you are selling to.

Look at Vegas 13. They added the new toolbar with the edit tool modes. The functions of this Vegas could already do with keyboard modifiers and/or shortcuts. So why add a new feature that does not add new functionality. Maybe because the existing functions not obvious but the new tool modes are.

All developers know users for the most part do not read help files, and the Vegas help index is pretty good, and they certainly do not read manuals. RTFM as we like to say…in private of course. 😉

[Norman Black]

Now that I think about it. I would implement this by doing…

When multiple keyframes are selected then draw a transparent window with hatch lines over the mask graphics display area. This makes it clear that those controls are no longer valid. If the user was clicking away and did not realized they multi selected, at least there is something very visual that something is different. They can RTFM to figure what the hatch means.

Then in the text panel the usual can be done. Conflicting values can be blank/empty entry fields and users can enter values that apply to the multi-selection. The user can RTFM to learn that they use the text entry panel in multiple selection mode.

The current UI is actually bad, IMO, in that when you have multiple selection, it provides no indication changing a value will not affect all selected keyframes. It is also not perfectly obvious which keyframe in the multi-select will change. Only with trial and error does one learn what is what.

[Doug Jackson]

Excellent idea!