Request for Essential Graphics Text Tool
It is wonderful to be able to gradation the color of letters!
Thank you very much! !! Very glad! !! All Japanese users are happy!

As a request for further creative creation ...
・ We want a gradation function for the border.
・ We also want a gradation function for shadows.
-Multiple boundaries can be used. We want you to be able to use multiple shadows as well.

Especially in the Japanese video industry, multiple boundaries and their gradations are really used a lot. Hopefully at this time, we hope for further evolution!
Thank you!

エッセンシャルグラフィックステキストツールのリクエスト
文字の色をグラデーションできるようになったことはとても素晴らしい！
本当にありがとう！！とてもうれしい！！日本のユーザーはみんな喜んでいます！

さらなるクリエイティブの創造のためのリクエストとして・・・
・境界線にもグラデーション機能が欲しい。
・シャドウにもグラデーション機能が欲しい。
・境界線は複数使用することができる。同じようにシャドウも複数使用できるようになって欲しい。

特に日本の映像業界では、複数の境界線、それらのグラデーションは本当に多く使われています。できればこのタイミングで、さらなる進化を望みます！
よろしくお願いします！

Cursor Frame Behavior (Affecting In Out, Ripple Edits).

Ok team, I know you had some guy complain about how the Cursor works in the timeline, and now you changed how it works, which completely screwed over the Ripple Trim to Previous Edit.

What WORKED before yesterday was if you were on the front of a clip in the timeline, and you hit the Ripple Trim to Previous Edit, it would remove the first frame and obviously move the entire timeline up a frame to compensate.

THIS WAS INSANELY HANDY because if you're trimming a clip, you could just hit that button a few times and make it work right.

Now, because you guys changed how the cursor works, I have to hit Right on my keypad, and then hit the Ripple edit button, and it'll remove that first frame.

Guys, you seriously screwed over an entire generation of editos who know how editing works. I know some people complain about how the cursor works, but this sucks.

Why not just create a preference option where you can make the Cursor act like FILM or act like it is now. All NLEs were based on film editing, which lots of people expect and relied upon. Now, I have to hit an extra keystroke all the time which is massively time consuming.

Can you please just put in a preference option to revert back or not? That would solve this issue for everyone instead of bowing to people that don't understand NLE history.

The fact that Pr always defaults to the last export location, regardless of which project is exported from, is completely illogical. Why would a user ever want to export Project B's sequence into the last used export folder if that folder belongs to Project A, for example? (see illustration 1)

There are already about a half dozen FRs that ask for this to be fixed, however since they only offer half baked solutions, I'm posting a new FR, offering a full fledged solution.

The solution is simple:
Provide a new 'Export' tab in the Preferences window that allows users to define the default location they want all of their projects to export to (both from Export Settings and Quick Export). (see illustration 2)

A 'Relative path' checkbox would allow users to make the export path relative to each project. In the illustration's example, the location is set to .\Exports. This means exports from Project A will automatically appear inside a folder named 'Exports' next to project 'Project A.prproj', and exports from Project B will appear in Project B's 'Export' folder, and so forth. If an export folder doesn't exist, Pr would automatically create it upon export.

Should a user wish to automatically export to the same location regardless of which project is exported from, setting this up would be as easy as browsing to one's preferred export location (for example, a "Pr Exports" folder on the Desktop), and unchecking 'Relative path'.

Note that these options would only set each project's DEFAULT export location. If a user chooses to export to a different location from a certain project, then that (and only that) project's default export location would be automatically set to this new location.

Example:
Project A: User exports to Desktop = New default export location for Project A set to Desktop

Project B: Default export location continues to be 'Export' folder (next to Project B.prproj)

This workflow would address the needs of all editors: those who want exports saved in locations relative to each individual project, as well as those who want exports from all projects to appear in the same place!

The current exporting behavior makes zero sense and is incredibly frustrating, especially for editors who work on more than one project at a time. Please fix this already! Thank you!

When you are "seeking," (which means QUICKLY looking through a long video by clicking and dragging the playhead with the cursor,) there is sometimes very high "prefetch latency," meaning that frames will load slowly, resulting in very few frames being shown. This can make it very difficult to find what you're looking for.

But when seeking, perfect frame accuracy is not nearly as important as seeing what you're doing. Therefore, to reduce the "prefetch latency," I suggest that the nearest I-frame is loaded and displayed FIRST, (because I-frames are always the fastest to load) while the exact B or P frame is still being slowly decoded. As soon as it's decoded, it can be displayed, replacing the displayed I-frame.

If the user is seeking quickly, there might not be enough time to load the P and B frames before the user has already moved the playhead nearer to another I-frame. This is fine! The I-frames should always take priority.

In VLC, there is a similar feature called "fast seek."

Combined with my "ghost playhead" feature suggestion, it would be made clear to the user exactly what is going on. (Linked below)

However, it would probably be important for fast seeking to be optional, and perhaps even off by default, as it may confuse some users.

NOTE: This works best if only ONE video source is visible. With more than one video on the timeline, the I-frames will probably not be in the same spots. Nevertheless, it COULD still work, but there would have to be multiple ghost playheads. This might be too difficult to code, and confusing and frustrating for users, who won't understand why premiere is showing video frames out of lockstep, especially in cases where one video has high prefetch latency, and the other is low.

LINK TO FULL EXPLANATORY VIDEO: https://youtu.be/XeFezzmG22c

LINK TO GHOST PLAYHEAD USERVOICE ENTRY: https://adobe-video.uservoice.com/forums/911233-premiere-pro/suggestions/42186274-a-ghost-playhead-which-always-marks-the-timeline

In Transcript: Export to text file.. To make this useful it needs to take clip name (all takes on timeline) and timecode info across so my (old school) documentary director can make a paper edit from interviews etc. Then provide me with time codes to build the assembly. (often barked down the phone!)

If I was self-directing and doing a project entirely within Premier. fine, I wouldn't need to export anything.
But filmmaking is a collaboration and the director doesn't want to touch the edit program but happy to look at text in Word or similar.

If the exported text file looked the same as what I see in the Transcript window that would be perfect. With Speaker (Custom)name/number, line number (from captions window - v.useful ), AND TIMECODE !!

Thanks,
Mark

My first test and the AI worked amazingly on a boomed IV clip to get nearly all text correct! Exciting times!

(Perhaps "current view indicator" is a better name than "ghost playhead.")

Here is the problem: The (cyan, user-controlled) playhead does NOT necessarily correlate to the frame that is being shown in the program or source monitor.

Sometimes, an old frame continues to be displayed, even though the user clicked elsewhere on the timeline (or "time ruler," as Premiere calls it.)

Depending upon computer specs, network bandwidth and latency, video codec, and other factors, it can sometimes take several seconds for the chosen frame to actually load and be displayed.

In the meantime, users need some kind of indication as to which frame is currently being displayed. This would be "the ghost playhead," which could perhaps be colored red.

If the normal playhead IS NOT on the same frame as the ghost playhead, it should be a different color, perhaps purple. This could be called the "Pending playhead."

If the normal playhead and ghost playhead ARE on the same frame, they should combine to form a different color - probably cyan as it is now.

Here's a video explanation:
https://youtu.be/XeFezzmG22c?t=311

Here's a link to a closely related feature request: https://adobe-video.uservoice.com/forums/911233-premiere-pro/suggestions/42186322--i-frame-first-fast-seeking-for-inter-frame-compr

When exporting a video sequence premiere randomly leaves out part of the audio. Those part were not muted, but in the same channel and of the same kind of other parts exported fine, not even cut: so for instance you have a talker that randomly get the voice silent.
This is a big reliability issue, because there is no correspondence of what you have on timeline and what you are going to have on final export. This happens on different machines and happened also with previous versions of Premiere different from this one at moment of writing 15.4.1 (build 4).
The only reliably working workaround has been export only the single audio channels in wave files and then import it back into the timeline, that is time consuming and unacceptable for a professional software.

After having no issues with 15.2 on small projects, Premiere became completely unusable after about a month of working on a feature film. It really seemed like an access error, as I'd get errors like "Unable to access resource 'SErrorXlN_D@2x' (type svg)," "Error Retrieving frame XXXX at time XX," and "Unable to access resource 'CursorDataID-19 (type xml)." The errors came with frozen or black video, I could still hear audio, and it usually fixed itself after about 10-20 seconds. I also couldn't export anything no matter which renderer I used. I thought it had something to do with Canon MXFs, since those have always been problematic for Premiere, but I got the same errors on ProRes 422, HQ and 4444 clips as well. The issues happened about once a day at first, and gradually increased to once every minute. At that point we shut down editorial until we figured this out.

This is a very specific issue, because openning the same projects (part of a large Premiere Production) with the same media storage on iMacs or iMac Pros on Big Sur or Catalina worked just fine. This made me think it was a hardware issue with my system. I have a Mac Pro (2019): 16-core on Big Sur 11.4 (I had to upgrade because PrPro 15.2 caused regular kernel failure with Catalina, and upgrading to Big Sur fixed those issues), 128 GB ram, Radeon Pro Vega II 32 GB graphics. We troubleshot everything from uninstalling every bit of software and drivers I could think of, including all Adobe apps, physically uninstalling my second GPU, switching media storage from a Raid to a single spinning disk (still external), and nothing made any difference. The last step of troubleshooting I tried was to downgrade Premiere to 15.1, and suddenly everything worked great (except for rendering with GPU acceleration, but switching to Software Only gets the job done).

In conclusion, something was introduced in 15.2 that causes read errors on large projects on a Mac Pro, and the issue persists with 15.4, but goes away when downgrading to 15.1. Thank you, Adobe, for allowing me to open projects in previous dot-versions, otherwise I would be in a very tight spot right now.

If you enable the check box in Preferences > General > Display color management, it will adjust the colors on the Source and Program monitors according to that monitor’s associated .icm file. However, this is only for viewing purposes on that specific monitor.
For an eyedropper to work properly, it must sample the color as it exists BEFORE color management is applied to it. But most of the eyedroppers inside of Premiere will only sample a color AFTER it has been adjusted by color management.
You can prove this by turning on color management, then trying to use a Color Matte’s color picker to match something else with solid colors. The results will always be different. (As shown in the image with the color bars.)
Currently, the only way to properly sample any color is to turn off color management first, as I demonstrate in this short clip. (45:41 to 46:21)
https://youtu.be/QPubgoqtfbk?t=2741

Currently, only the eyedroppers inside the Lumetri Color effect work correctly when color management is enabled. (As far as I know)