1 person found this helpful
I reported the same bug back in CS4 days. After going 10 rounds with technical support (where I was at one stage told that this was expected behaviour) there was eventually an admission that this was a bug and "not compatible with expected workflow". I was also told to look out for an update to fix the problem.
So whether you get a response to your bug report or not is anyone's guess. IIRC my experience was a couple of years ago.
The workaround is to nest your time-remapped sequence, import this back into your main timeline and apply your other key frames on that. This works as expected.
I consider this not a bug, but as designed. Effects are handled top down, starting with the first, then the second and so on.
Without time remapping, keyframes in the motion effect are applied, as shown in the red boxes below. Now when one adds time remapping, the duration of the clip changes and the earlier applied keyframes move along, as shown in the blue boxes below.
There is logic and consistency about this. Not a bug IMO, but as designed. See here:
If you don't want to have that, the logical approach is to first apply time remapping and nest the result in the sequence where you apply keyframed motion effects.
Trying to get my head around this one, so bear with me...
I would agree that what your diagram suggests is desirable, but I'm not convinced that is what happens.
The simplest way to show the issue...
- Place a single clip on the timeline.
- Time-remap it... e,g, 50% so the clip is twice as long.
- Now add a couple of opacity key frames somewhere in the clip - set the first to 0%, the second to 100%.
With this example, wouldn't you expect the clip to be at 0% opacity exactly at the first key frame, and 100% to be exactly at the second? It is a while since I've done this - and I don't have CS5 - but in CS4 the displayed keyframe positions don't match the actual opacity rendered. In CS3 they did.
Apologies if I've missed the point here! But if this is desirable and consistent behaviour I wouldn't mind getting my head around why!
In your example when you scrub to the 100% keyframe, does the rendered display reach 100% exactly at this point? Or do you have to scrub further along to the right of that keyframe before 100% is reached?
In CS4 - using this example - you only get to 100% once you've reached a point much further to the right of the keyframe.
According to my (quite possibly warped) sense of what is intuitive, this isn't!
But if CS5 has fixed it, that's yet one more reason to upgrade.
Then again, I'm not entirely sure you agree that what I'm getting isn't what I should expect anyway?
Hi there Tim,
Your support and witness is much appreciated, sometimes it takes a super human effort to remain calm in the face of what seems to be blind and stubborn refusal to recognise the unfinished and unsatisfactory nature of things such as this. Whether it is a bug or design is immaterial if working with it is just too damned hard.
Fear not, they have not fixed it in CS5, I am about to demonstrate that to Harm, who seems to think that a Non Linear Editor has to be used in a Linear fashion, just to fit in with the unfinished nature of the software that is shipped to us (oh sure it is fantastic software but it is not without fault!).
seems to think that a Non Linear Editor has to be used in a Linear fashion, just to fit in with the unfinished nature of the software that is shipped to us
It doesn't have to be used in a linear fashion, but some conventions need to be followed to ensure that consistent results can be obtained. Even in After Effects, an industry standard application that can hardly be called "unfinished", you must be very careful about the order that effects are applied in a composition, and forcing a certain order is done by pre-composing layers. It is expected and necessary behavior. In Pr, "pre-composing" is done by using nested sequences.
That said, I believe you are 100% correct that the behavior you are seeing in this case is a bug. The keyframes indicate one thing, but scrubbing shows you something else. That needs to be fixed. The keyframes should always represent exactly what is occurring in the timeline. I just wanted to give you some perspective on the usefulness and flexibility of nested sequences, and why, in this case, they can save your bacon until a real fix comes along.
Hi there Harm,
Thank you for replying, I ended up sending two sets of bug reports to Adobe because the first two were not as concise and clear as they might have been (and included a lot of Capitalisation!).
First up I have a screen shot to attach:
Here you can see the end result.
Firstly on a fresh 25fps HDSLR 1080p sequence I insert a clip,
Secondly I placed two time remapping keyframes near the beginning and dragged the play speed line between them up to about 350%.
Next, I added two Positional keyframes after the time remapping keyframes, they both work fine.
lastly I move the play head between these positional keyframes and change the value of either the X or the Y coordinate.
The result is that the value changes, there is a keyframe created, but the image is not effected!
But wait, if I scub backwards on the timeline at some point the change made can be witnessed happening, there is nothing there to mark where the change happens so how am I expected to work with this? Seriously?!
IT IS A BUG!
Secondly something that irratates the hell out of me:
In this scenario, when I am applying the time remapping keyframes (lets just say they are being applied to the end of the clip), I need to zoom in to the timeline and then move to the area to be remapped. I apply keyframes, reveal the play speed line, drag it up as much as I can before it frustratingly returns to zero again, then let it go... Bang the view zooms right back out and I am only part of the way towards the value I wish to attain!!! I have to zoom in again, move to the keyframes AGAIN, etc, just to have it snap back again after altering the speed a little bit more.
Don't tell me why this happens, I can guess and figure that out for myself! The point is that is what GOOD developers do, they realise where their software is falling down and say "This is not acceptible" and work hard to fix it so that the end user will be empowered by their product and happy to use it because they recognise that it is USER FRIENDLY...
It reminds me of the markers I have used in Sony Vegas, no matter what you do to the time line, the markers stay attached to the place they were attached to, in PPro, you move a clip or change its speed and all your markers are good for are being deleted!
Anyway, what do you think Harm?
Sorry to be long winded...
I'm glad you agree about the definition of this issue, it makes me quite happy. I believe that most people resort to other means often forgoing the use of graduated play speed change, to the point that many just wont to go there even to report the bug because it is so confusing...
The way I was looking at what harm was pointing out (if I understood him correctly) is that we have to make our changes to items at the top of the list before we make changes to items lower down the list (say positional and opacity changes before the time remapping changes). This implies that once we alter time remapping, 'convention' (and reality) states we cannot adjust position or opacity again?!?! That IS linear...
Even using a nested clip becomes Linear to an extent in that if we want to alter the changes we made to the play speed we then have to go through the whole process again, without any of the aides that exist on the original timeline like markers and other reference points! It is just too hit and miss to be called functional as I would see it. Just the complete lack of robustness in the markers (you can't even select them!)(they are not affixed to the clip in any way!) is almost enough to give pause to my calling PPro a user friendly editor... And Adobe has pittiable user support appart from these great forums.
That's just my five cents worth...
1 person found this helpful
It seems to me that your description of what is wrong with Harm's logic, as well as your description of the drawbacks of using a nested sequence in this particular case, could be solved if the underlying bug was fixed. That is, as soon as the keyframes you see in the Effects Control Panel actually represent what is happening in the sequence, all would be well. You wouldn't care in what order changes were made because the keyframes would show you visually what was going on. And you wouldn't need to resort to nested sequences, so all of your original reference points would still be available. Is that an accurate analysis of your current perspective?
Just the complete lack of robustness in the markers (you can't even select them!)(they are not affixed to the clip in any way!) is almost enough to give pause to my calling PPro a user friendly editor
Check out Clip Markers.
NB: The Help files don't mention an alternative way to set clip markers: select the clip under the playhead in the timeline and go to Marker | Set Clip Marker | Unnumbered. An unnumbered clip marker will be placed under the playhead.
Yes Jeff, I think that seems to sum it up really.
It appears that everything works appart from the keyframe markers ability to reflect their new position... Which effectively breaks the whole thing, not only the play speed change (which is why I get so hot under the collar about it).
On the clip markers; I chuckled when I saw them, I have seen them before but got confused about them. They do indeed attach to the clip, but they are just too robust now, they cannot be moved? They have all the functionality of the sequence markers apart from the lack of movement now I made some keyboard shortcuts which is good. Still the ability to select multiple markers and then move or delete the group of them is powerful or for that matter, name them so you can recognise them still if you are zoomed right in to the timeline. Good steer though, thanks.
P.S. I hope Harm does not take any offence, I should imagine he is quite thick skinned but still... It was just his initial statement that there is no bug but simply design, irked me somewhat.
They do indeed attach to the clip, but they are just too robust now, they cannot be moved?
How are you trying to move them? They should move with the clip. To move them within the clip, double-click the clip in the timeline. It will open in the Source Monitor. In the SM, drag the clip marker wherever you want.
If you try to do that in the timeline, you will drag the clip and not the marker.
Unlike Sequence Markers, Clip Markers can not contain any data or comments. They are reference points only. I assume you know where the bug report/feature request form is by now?
You have another helpful reply Jeff!
It is just that I virtually never go to the Source Monitor, everything just gets dragged from the project panel into the timeline panel and trimming and cutting and juggling clips I do all on the Timeline in the timeline panel. Anything else is done in the Effects Panel. The SM I look on as kind of pointless but I realise it used to be an intigral part of the editing process...
Yes I have the Feature request/Bug report page bookmarked now, but I have limited faith in their sincere care or intent. Having recently become aware that my upgrading to Production Premium CS5 made me elligible for a 'complimentary benefit', I tried to apply for it. I followed the links, there were two and they both took me to the same page, a page which had NO links on it at all (This Page Here). I opened a 'customer support case' and they told me to go down this same path and choose my 'benefit'. I did so again and found no links there, so I took Screen Captures put them into a JPG image and wrote on the image, and in the reply, that there was no links there. This was their response:
"Thank you for your response. I have viewed the screenshot that you have attached to this case. From what I saw, you clicked the "See your benefit" lik and when you clicked that you were then directed to a page that shows the 4 available benefits ( Adobe Text face, 30 days of Lynda.com online video training and Magic Bullet Quick Looks Plug in).
Have you tried clicking one of the available benefits?"
I mean, really!!! My patience is severely tested...
Anyway, thanks Jeff
> Yes I have the Feature request/Bug report page bookmarked now, but I have limited faith in their sincere care or intent. Having recently become aware that my upgrading to Production Premium CS5 made me elligible for a 'complimentary benefit', I tried to apply for it. I followed the links, there were two and they both took me to the same page, a page which had NO links on it at all (This Page Here). I opened a 'customer support case' and they told me to go down this same path and choose my 'benefit'.
The bug reports and feature requests go directly to the core engineering team for Premiere Pro. The people who process and read those reports are right next to the engineering manager, product manager, and so on. I'm the person who processes these reports for After Effects, and I work closely with the folks who do so for Premiere Pro. These reports and requests are very important to us.
The folks that deal with registration benefits, web pages for the overall suite, customer service, et cetera... well, they're in an entirely different group. You can't draw any conclusions about how we treat bug reports from how bad (or good) these other things are.
That's not to say that we on the Premiere Pro team can't help get those other things fixed. I, for one, make a point of pointing out issues like these to the appropriate folks. I'll be picking up the phone and calling some folks to point out the issues that you mentioned here as soon as I hit Submit on this response.
It is very difficult for anyone to get some 'Answered Correctly' points from this topic, but I think you have just fulfilled the criteria! I guess it is too late now for the present phone call but I would remind you about the needing to zoom back in after any play speed alterations, while it is not game breaking it is one of those things that provides no end of irritation...
Please convey my apologees to the people who read the Bug reports for my tersness aswell but I am sure they will hear more from me at some point down the line, comes with the artistic nature I suppose, sigh...
Hope I see something concrete in an update to come, it has been a long time broken.
Has there been bug fix for this? CS5.5 still seems to have it!!!
Just wanted to chime in and report that this is STILL A BUG in Premiere CC!!!! Holy crap get on this Premiere!!!
On CC, same problem... :/
So I was banggin my head on my desk wondering why my opacity keyframes where shifting around. Atleast its nice to know im not the only one that thinks this is BAD implementation of TIME-REMAPPING.
The resign this is happening is a EFFECTS PIPELINE issue. Time-remap is triggered AFFTER all your other keyframes
you have a 100 frame clip
you keyframe an opacity fade out from frame 75 (100% opacity) to 100 (0% opacity)
everything works fine.
You do a TimeRemap of 200%, paking your clip 50 frames
Now your keyframed opacity fade out is from frame 37.5 (100% opacity) to 50 (0% opacity)
your fade down is in the SAME FRAMES OF THE CLIP.
But what we want is the opacity & motion keyframes to be relative to the BAND ON THE TIMELINE NOT the MEDIA'S FRAMES.
Nest the clip,
time-ramp in that nested timeline
then in your original timeline apply your opacity
give us a checkbox "keyframes respect Time-remap"
6 years after the original bug report was made, this is still an issue. This is my first time using time remap in Premiere and have to admit I became incredibly frustrated when I couldn't explain to my creative director what was happening to the carefully-edited clip.
I have been experiencing the same issue (frustration) over the last few hours and it seems that once I nested (as mentioned above) everything fell into place!
This bug/"intended behavior" is driving me mad trying to edit timelapses more than 7 years later.
Nesting the sequence when I need to sync camera orientation with the time remapping is not an option.