Tag Archives: keyboard

Enhance your Premiere Pro productivity – keyboard shortcuts galore

By | | , , ,
4 Comments

There’s a tip that I wanted to share with you, which increased my productivity with Premiere Pro tremendously. And it’s very simple: customize your keyboard shortcuts. But make it wisely.

First tip: make use of the search box which is present in Keyboard Shortcuts dialog in Premiere. There is a ton of shortcuts, and if you know the proper name, or even part of the name, it’s easier to type it in the search box, and browse among the remaining entries, than to wade through all the options.

First and foremost – track selection

Separated from source patching in CS4, constantly improved, but still hardly perfect, track selection tends to be one of the most annoying things if you don’t remember about it (like wondering why match frame shortcut does not work). It has also been pretty cumbersome. But in CS5 we got a nice addition that allows us to finally make it more of a feature than a nuisance.

Assign keyboard shortcuts 1 –8 to Toggle Target Video 1-8. By default they are assigned to multicam, and if you are doing a lot of multicam work, you might consider remapping your Select Camera shortcuts to F1 –F12 . This way you will overwrite the defaults for help (F1 ), capture (F5 ) and batch capture (F6 ), but the chances are you’re not using them very much, and if you do, simply find a better place for them. Like Shift+Ctrl+Alt+H 😉

Then assign 9 to Toggle All Target Video On, and 0 to Toggle All Target Video Off.

Track selection is vital to every editing operation in Premiere, and once you get used to the new shortcuts, I assure you, that you will never go back, and will be ready to strangle anyone who would like to take it away from you.

Perhaps you might also find it useful to assign Toggle Target Audio 1-8” to Ctrl+1 to Ctrl+8 , although personally I found myself using only the shortcuts to Toggle All Target Audio On/Off (Ctrl+9 /Ctrl+0 respectively).

Be mindful that shift+number shortcuts are assigned to panels, but if you change them you will not be notified about it! And there will be no undo, you’ll have to revert these changes manually.

And while we’re at it, why not map labels to Ctrl+F1 and further on? It’s a bit more complicated, you need to navigate to Edit->Label in the keyboard shorcuts dialog, and then assign keys to each label, but it also might be pretty helpful at times.

Manipulation of In and Out Points

Setting the In (I ) and Out (O ) are pretty decent standards, but some of the other shortcuts in this area are suboptimal, considering the fact that you need to perform thousands of this kind of operations a day, and adding half a second to press Shift , or even Shift+Alt+Ctrl is a pain. This time it’s worthwhile to take example from Avid, and get these under your fingertips.

The most important one: Clear In/Out – map it to G . This used to be Premiere’s default before FCP users started to put pressure on Adobe to adopt their  keyboard mapping.

Clear In and Clear Out is not something I use very often. If I want to change the In, I just set an In in another place. However, if you find yourself using them often, E and R seem to be pretty good places to put them.

On the other hand Go To In, and Go To Out tend to be useful, and I map them under Q  and W .

Mark Clip also tends to be useful for many reasons, gap removal included, and I tend to have it under the slash key / . Mark Selection – not so often used, I map it to Shift+/ .

Setting Render Entire Work Area  to Shift+Enter is worthwhile. I generally turn off the work area, and use In and Out, and this option is replaced with Render In to Out in my workflow, but the shortcut stays the same.

A few more tips

An idea that navigating markers should use the M key is quite alien to me. I prefer having Go To Next Marker as Ctrl+PgUp , and Go To Previous Marker as Ctrl+PgDn . It frees the M key for more important things, like for example assigning Edit Marker to Shift+M .

Another function that I often use is Add edit, and Add edit on all tracks. Default Ctrl+K  is not necessarily so bad, but it still requires at least two fingers. Let’s reduce it to one. Throw out the zoom tool shortcut (honestly, when did you last time use that one?), and assign Add edit to Z , and Add edit an all tracks to Shift+Z .

Speed/Duration and Audio Gain – who says that invoking dialogs needs a modifier key? Map them to D and H respectively. Who cares about the hand tool anyway?

Ripple Delete – default Alt+Backspace is almost fine, but why not map it to the del key itself? You’ll have to remember that the Backspace and del will then have different behavior but I think it’s worth it. I would map it to backspace, but then it interferes a bit with the way project panel works, so delete is the way to go for me.

Two real kickers and trimming

The next two will save you tremendous amount of time during editing. I used to perform this operation with a mouse – when I felt that I had to make a cut, I ripple-trimmed my next edit point by dragging it with a Ctrl key pressed (which was BTW the best timeline interaction I’ve ever had with any NLE) – and now I can do it without, saving quite a lot of time. There are two great shortcuts that should again be at your fingertips by default:

  • Ripple Trim Next Edit to Playhead – ]
  • Ripple Trim Prev Edit to Playhead – [

They take time to get used to, because the shape of the characters is opposite to what it does, but their position is correct. I still sometimes press the incorrect one, but they are a real timesaver, especially in connection with track selecting. However, if you find yourself thinking too much, you might consider switching them, and seeing if it doesn’t work better for you.

There are also two of the less often used – Extend Next Edit to Playhead and Extend Previous Edit to Playhead, which I tend to map to Shift+] and Shift+[ respectively.

I have never used Extend Selected Edit to Playhead. Ever. Perhaps I still don’t know something about editing, but I have not come upon a situation where I couldn’t replace it with any other available option.

Sometimes however I find it useful to immediately move to the nearest edit point and select correct trim mode. Therefore I usually map the following:

  • Select Nearest Edit Point as Ripple In to Ctrl+]
  • Select Nearest Edit Point as Ripple Out to Ctrl+[
  • Select Nearest Edit Point as Trim In to Shift+Ctrl+]
  • Select Nearest Edit Point as Trim Out to Shift+Ctrl+[

Transitions

For a moment I toyed with an idea to assign D to Apply Default Video Transition, but I decided against it. I needed other shortcuts much more, than I needed the transitions.

Interestingly, in CS6 you can specify a separate shortcut to add each of the following transitions:

  • Audio Crossfade
  • Video Crossfade
  • Dip To White
  • Wipe

If you tend to use any of these, definitely apply a shortcut to it. Also, if you use any other transition often, like for example Dip To Black (why it’s not in the list I have no idea), then use this one as a default transition, and apply a shortcut to Crossfade. Possibilities are really interesting, and I sincerely urge you to explore them.

Finally

Here is the .kys file for all of you lazy and impatient people to download:

Bart's keyboard shortcuts (14754 downloads)
Feel free to use it and distribute it as you wish. However, I strongly urge you to explore keyboard shortcuts on your own.

To install the shortcut keys you need to exract the .kys file to the following folder (substitue $username and $version for appropriate values):

  • c:\Users\$username\AppData\Roaming\Adobe\Permiere Pro\$version (Windows)
  • ~/Library/Application Support/Adobe/Premiere Pro/$version (OS X)

I hope you’ll find these tips as useful, as I do. Enjoy.

Tactile input is important

By | | ,
Leave a comment

Recent (?) fascination with touch-controlled interfaces is perhaps good for their development, but in my opinion they are not necessarily the future of device manipulation.

One of the big mixed blessings is that you have to rely on the visual feedback to operate such an interface. While it is perhaps a tad faster to manipulate directly items that you’d always want to look at—like photos—or that wide-sweeping gestures are faster than looking for “next” or “previous” buttons, it is not necessarily so with interfaces that rely on mixed tactile/visual, and sometimes even auditory feedback.

An excellent example is a keyboard. A keyboard gives you at least three kinds of input: tactile (feeling of pressing the key and its shape), auditory (click of pressing the key), and finally visual – letters appear (or not :) ) on the screen. Many people do not appreciate the first two, mostly because they were not trained in typing without looking at the keyboard to find each letter that they type, or to use all their fingers while typing. Personally I believe that classes of quick typing should be obligatory in primary or high schools and would be more useful in daily life. For example, when visiting a doctor, I often find that he takes more time to use his computer to type the diagnosis with two fingers than to actually examine his patient. What a terrible waste of time.

Anyway, the reason that mixed input is important is about efficiency. Once you learn to stop looking at the keyboard while you type, you reach a new level of efficiency. You start relying on your tactile and auditory input to feel and hear if you have pressed your key, and to an extent to know which key you pressed, only using visual feedback for confirmation, not estimation. For those who wonder why there are small embossed dashes on the F and J keys – they are places where your index fingers will be when you use proper typing technique.

Touch screen does not give you this advantage. You use visual cues to find the proper key, robbing yourself of the input by covering the key you want to press at the same time, and then for verification. You use a single channel to process the information. It is slower not only because tactile information reaches your brain and is processed 10 times faster, but also because you use serial processing instead of parallel one. While typing on a classical keyboard I know I have pressed a wrong or a good key even before I get the confirmation on the screen. Therefore it is much easier for me to switch from typing to correcting mode (and yes, there is a noticeable switch going on), than I would when I am typing on a touch-screen keyboard. My impression also is that the responsiveness and robustness of touch screen interfaces is still not at the level of keyboards, but I might be wrong, since this field evolves very quickly.

Another example where tactile input is vital, are the devices which one would be able to operate without having to look at them. One that comes to my mind is an mp3 player. Usually this device sits in my pocket or in a place that I do not have an easy visual access to, and for a good reason. Therefore if I want to increase the volume, lock the controls or change/rewind the track, I would prefer not to need to put the device in the center of my visual attention. Running, cycling, driving — these are the activities that do not lend themselves well to visual distractions. Admittedly, using any device while driving will lessen one’s concentration and might result in an accident, but this is precisely why most of the car interiors are built in such a way that you can rely on tactile input to turn on radio, heating, conditioner and all else.

Therefore, it makes little sense to design an mp3 player with touch screen input. When the buttons are present, you can learn their layout, and operate the device without the need to look at it. You will get immediate auditory input — increase in volume, next track will start playing etc. And you can easily lock/unlock controls, which perhaps is the biggest advantage of all.

There is also another issue. While using touch-screen to manipulate photos you often cover the part that you’re interested in manipulating, therefore robbing yourself of a visual feedback that the touch-screen is supposed to give you. This is not necessarily an optimal way to work. I would agree that it is the way that we manually paint or write, but it only shows the limitation of our tools (limbs). Personally, when faced with a choice of a touch-screen tablet, and a standard screen with a cursor, and a traditional tablet, I prefer the latter, simply because my field of view is wider. Motion estimation is similar in both cases, even if the second way takes more time to learn, and to get used to, like learning to use any tool or device.

All these examples show that if touch-screen interfaces want to become more useful, they will have to evolve additional feedback mechanisms. As of now, there are too many applications where they are detrimental to efficiency, and when we consider them setting their “coolness” factor aside, their application is still limited in scope.