What is the difference between Instant vs Delayed functioning in your opinion?

I'm rest assured that if on my systems there would be a Delay and on yours the same function would be Instant you would say offensively:

Dude, you may want to wipe your system and reinstall everything from Windows on up.  You seem to be having a LOT of issues that I can't reproduce on two different systems.

But when there's an obvious Program fault, you're saying inadequately that it's the way it should be, it's by design, it's just work differently, I'm not seeing an issue, etc.etc. Even Adobe Employees are not such an app defenders.

Anyway, thanks for entering discussions, you are probably one of the most active participant on the forum.

FYI, each of my described bugs have it's own workaround(s). But in most cases workarounds are slow. I start Discussions to confirm that I am not alone and the issue is Program-specific, no need to defend the app reputation. Current issue is solved by a macro script which uses it's own methods to alter Audio Gain by manipulating Premiere's Audio Gain Dialog Box.

When you say "adjust it by 5" it has to check the current peak gain on the clip and make a relative adjustment, not an absolute adjustment.

imho, a Calculation of %iCurrentGain% +5 should not invoke the Calculating Audio Peeks progress bar.

I would tend to agree that once the peak gain level has been determined that no more adjustment is made. In that case, no further analysis (calculating) should be required

exactly

but the program may just be set to check it every time by default when a relative adjustment is being made.

But why? It's needless. Could you imagine that after using a Clip Speed/Duration and setting a checkbox to Ripple Edit an unnecessary Calculating Ripple Edit, Shifting Trailing Clips progress bar dialog box would appear? Would you say in that case that the program may just be set to check the clips location every time by default when a ripple edit is being made?

Looks like you are defending app's operation behaviour like Jim did.

Adobe developers will have to answer for you.

Hopefully in this Discussion.

This case is definitely cannot be a Feature Request and it is defenitely not a thought-out design of an app operation.

Can you assume that it's simply a mistakenly written code?

http://en.wikipedia.org/wiki/Software_bug

A software bug is the common term used to describe an error, flaw, mistake, failure, or fault

a mistake in program code is also considered as a bug

When you will have an opportunity, try changing Audio Gain for a > 1 h long audio clip.

Simply type +1 in Adjust Gain by editbox, and then do the same thing, but use Set Gain to editbox. It's interesting that Set Gain to can be used in the same manner as Adjust Gain by.

Activate Adjust Gain by editbox, then press End and type +1. New Gain will be calculated in the same way as when typing relative values for Set Gain to, but with a difference - the change will be Instant, no Progress Bar.

Thanks for the feedback.

It's great that somebody can benefit from my manifests.

I suspect it's working as designed.  But only an Adobe engineer would know for sure.

An Adobe engineer would just confirm a mistake in program code or, if you wish, not deliberately a function("Calculate Audio Peaks") is used in wrong place

Are you tried the tool? Is it a good idea to develop such tools?

It's great to know who is who

Currently I know only:

• Kevin Monahan - Help Files, Community (maybe more)
• AkilW - Audio Specialist

I'm just an editor since '99 with a huge loan for an apartment

Pleased to meet you!

You have quite a huge list of capabilities

Kevin, please take my respect