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!

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

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

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

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

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!

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

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)

Sometime in the very beginning of January 2021, using Arrow Keys to move masks, (or mask points) directionally around the window by pixel accurate methods, changed over to moving the playhead instead!?

And when I go into Keyboard Shortcuts, and try to manually change it, it doesn't work! And I also tried removing all the default settings, and just add back in, Move by 1 pixel for each direction, and it still doesn't work!

I BELIEVE THIS IS A BUG, AND A LOT OF OTHER PEOPLE DO AS WELL:
https://community.adobe.com/t5/premiere-pro/i-can-t-move-mask-with-arrow-key/m-p/11677100/thread-id/317272

https://www.reddit.com/r/premiere/comments/kbav8l/using_arrow_keys_to_move_a_mask_no_longer_works

Adobe, if this is NOT a bug, and is some sort of new feature, please give us back the ability to manually change it to the way we want it.

If it IS a bug, then please throw some of your extensive resources (as given you by the millions of users paying you $53/month until the end of friggin time!) to FIX THIS BUG!

THIS IS EFFECTING MY ABILITY TO DO MY JOB FOR OVER A MONTH NOW!

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.