[Nat Jencks]

Yikes, if this is true this is REALLY bad, and in my opinion a major problem. Can anyone else confirm this?

I was thinking of upgrading production machines to v12 but if color grades from v11 will change that is a HUGE problem.

best-
-Nat

[Nat Jencks]

Although of course its true technically that prores4444 or proresXQ are compressed formats, the real world perceptual difference between a Prores4444 or Prores XQ and uncompressed DPX is frequently zero.

Of course if you plan to manipulate the image further then going uncompressed could provide some benefit, but if this is an output which is not intended to be further manipulated then Prores4444 or XQ is typically not going to be perceptually different from uncompressed DPX.

best-
-Nat

[Nat Jencks]

[Eric Sternberger] “Thanks Nat, that has done the trick.
However, I find it not very intuitive, that a setting in the editing tab should influence the delivery tab.”

I’m usually the first to encourage changes to make the GUI more intuitive, but in this case I think the current design with the routing in the audio mixer really does make sense.

The audio routing isn’t linked to rendering, its just part of your timeline setup, and makes sense that you would look at this while cutting in your audio tracks, and looking at the audio mixer.

This determines how audio is played out while you work and screen films, not just how things are rendered at the deliver stage.

Best-
-Nat

[Nat Jencks]

check your audio routing in the audio mixer

[Nat Jencks]

I agree regarding occasional mysteries of conform “conflicts”, I frequently see conflicts where more than one shot is matches, where there really shouldn’t be any doubt, e.g. the ReelID and TC are all very clear and there is only one actual match, and yet resolve will find alternate clips as possibilities. This is usually with XML. The matching logic with EDL seems more cut and dried.

It would be great if the matching logic for XML conform were outlined exactly somewhere so we could know the logic behind some of these mysterious extra matches and conform conflicts.

best-
-Nat

[Nat Jencks]

This is not going to be possible, the RMD metadata includes quite a lot of variables which will not be possible to convert into a color cube.

It would have been convenient if RED allowed users to build an in camera look which could be saved out as CDL values and or a standard cube, but not surprisingly they went their own way.

best-
-Nat

[Nat Jencks]

Yes its pretty crazy that a sequence can’t be exported and imported into a new project including color grades. And given that color trace can be a little finicky thats not always a perfect solution either.

I encourage anyone that agrees to email BMD and voice your desire for this rather basic feature.

best-
-Nat

[Nat Jencks]

I just find the whole thing bizarre. This can’t be the expected behavior. Wasn’t v11 released with great fanfare as a potential editing platform?

Like I said, it actually doesn’t bother me that much since I spend so little time in the edit page, but Its just hard for me to imagine the developers thinking it was a good idea to work on stuff like asymmetric trim modes when basic playback wasn’t working?

I’m talking about just playing back a simple ProresHQ clip with no grade whatsoever… For me the GUI is weirdly stuttery. SDI is fine. Seems odd that such a fundamental thing as basic playback would be overlooked while rafts of other features were piled on.

I’m going to give BMD the benefit of the doubt and assume that there are some systems which don’t exhibit this strange edit window behavior.

I get concerned when I see stuff like this where new features are added before basic functionality is complete.

Hopefully v12 will be part of the solution to this trend rather than continuing down the same path… fingers crossed.

best-
-Nat

[Nat Jencks]

Bill, I think in your case the system your using simply doesn’t have enough memory (either vRAM or standard RAM) to do what your trying to do (I agree it would be nice if it failed more elegantly than giving an out of memory error and quiting).

In my case I think there is something different going on, as this is something which has changed with the recent update of resolve or the OS, and this “vaporizing” behavior is new for me and I’m seeing it on multiple machines. In my case I don’t think the vaporizing is due to lack of VRAM or standard RAM (the systems I’m using are maxed out at 6GB VRAM and 64GB RAM) but rather are the result of specific buggy code with the GPU either in the AMD drivers, OpenCL, or Resolve which is causing these “GPU RESET” errors.

Thanks for the feedback!
-N

[Nat Jencks]

I know this is an old thread, but 3 years later, this is still an issue.

I second Roman’s question, why would the AAF need to be in the same file path that is was originally imported from? This seems like a bug.

I just wrapped a project where the initial AAF was imported from a location on local storage but which was later consolidated to a new location.

It now seems to be impossible to export an AAF for the avid. The AAF itself is very little data? Why not copy the needed information into resolve when the AAF is imported? Or at the very least allow it to be relinked to throw up a dialog allowing the user to find the original AAF if its not in the original path.

But really I don’t see any reason why the data from the AAF can’t just be imported into resolve when the sequence is first imported.

Please consider this somewhere between a feature request and a but report, thanks!
-Nat