Queued time-lines should consider track statuses

At the present time, when you put a time-line in queue to be rendered, the tracks statuses are ignored (mute, solo etc).


It will be nice, to expedite workflow, if the queued time-lines consider also the status of the tracks at the moment they were queued.

For instance:
timeline with audio A live, audio B muted. Queued
same time-line newly queued but with audio A muted and audio B live.

When rendered:
the first video has same video but audio A
the second video has same video but audio B

[EDIT] Corrected some mistypings[/EDIT]

+1

only workaround at the moment is to duplicate the timeline....

only workaround at the moment is to duplicate the timeline....

Indeed hence the request. Less workload

Personally would not want this. I often add a job to the queue and go back to it to render multiple times. Would not want to have to remember what tracks were active at the time of job creation.

Sent from my Pixel 4 using Tapatalk

Also on the case of audio, you could just route to different busses to easily archive this.

Sent from my Pixel 4 using Tapatalk

Personally would not want this. I often add a job to the queue and go back to it to render multiple times. Would not want to have to remember what tracks were active at the time of job creation.

Sent from my Pixel 4 using Tapatalk

You wouldn't have to... the idea would be that the track status is encapsulated as part of the 'job' ie it would remember for you.

Also on the case of audio, you could just route to different busses to easily archive this.

Sent from my Pixel 4 using Tapatalk

Doesn't work for video tho, Nathan ... that's the issue for me.

Totally understand. I think we might have to agree to disagree on this one. I totally see how this could be helpful in some situations but just saying that this would not be a positive change for my workflows.

Sent from my Pixel 4 using Tapatalk

Yeah man, its horses for courses.

For me, if I'm exporting episode masters, I can switch to the Deliver Page, choose my "Texted Master" delivery preset ... it automatically sets my all render codec settings as needed, disables Data Burn, enables subtitles (and sets them to Burn into video) and sets my audio output tracks to output the Full Mix and International Mix buses... it's all good. I just give a name and add it to the render queue.
Next I choose my "Textless Master" delivery preset... which is largely the same except it disables subtitles and sets my audio output tracks to the various narration, dialogue, atmos, effects and music buses etc... but this job I can't add to the render queue because I also need to disable the texted elements track in the edit first. Hmmm. Although the 'Disable Video Track' buttons are presented in the Deliver page (with Tooltips etc) the buttons don't work ... and if I'm foolish enough to actually go back into the Edit Page and disable the unwanted texted elements track there, and then go back to the Deliver Page... sure, I can now name and add the 'Textless' job to the render queue... but if I go ahead and render both queued jobs at this point... uhoh the first job is now buggered because it gets rendered without the texted elements.

Of course, creating a separate copy of the entire programme, just to disable a few seconds worth of texted elements is totally doable (and is exactly what I do do at this point) ... but my life would simplified if I could just toggle the wanted/unwanted track state directly in the Deliver Page and submit my job (with that setting recorded) so that I didn't have to jump through those hoops.

Its cool though, hoops are okay. This is far from my number one request.

I totally get you I also am involved in a lot on online deliverables.

A little insight into our workflow might provide better context to why this might not be a positive change for some. We tend to have to do multiple outputs per show. Some shows have many different outputs (Premiere, Evergreen, Textless, INTL, INTL Textless etc.) . Something that we have found that works great for us is nesting or using mezzanine files for these multiple outputs. This allows us to render out the show in a fraction of the time (especially with the setting where you can bypass processing on output). If we have QC changes we can just pop them into the nest or patch them into the mezzanine and spit back out the sequence. It allows us to make multiple timelines and save those as jobs that can then be rendered at any time.

If this feature was implements before any output was done I would have to double check all of the track settings before render. Also how would that work if a track was added? Would it be included or disabled? How would that effected nested sequences? Would the render job remember the track state for all nested sequences as well?

Totally understand where you are coming from but just wanted to give you my perspective. We try to build our workflows to be as efficient and rock solid as possible. This change would add a level of unpredictability.

On the flip side. I 100% agree with you and wish that you could enable and disable tracks in the output page. That would be a great feature.

Very fair points Nathan... I guess you can please some of the people all of the time and all of the people some of the time etc... bloody people. :)

Totally understand where you are coming from but just wanted to give you my perspective. We try to build our workflows to be as efficient and rock solid as possible. This change would add a level of unpredictability.

On the flip side. I 100% agree with you and wish that you could enable and disable tracks in the output page. That would be a great feature.

As id doesn't add any unpredictability in a DAW, it cannot add it here. Premiéer itself did it. And no one died for it. Right?

Hence: when you add something into a queue, everything you add should be there and the queue executed with all settings it gets.
It will be very nasty if the queue is changing if I change anything after have added the element to it.

Good practice is: if you need to change something in the queue: just remove it form the queue, make your changes, and re-add it. As in any DAW / Premiére is performed and also well.

Being aware of this, I asked this feature (and I still ask it) in DaVinci, making it more flexible. At the actual state it isn't.
The BUSS routing doesn't work as I need. I exposed this in 2 topics here (about bilingual production).
So: drop it

To duplicate the timeline: it's the solution I'm actually adopting. For 10 minutes stuff is ok. For 1h stuff: please avoid it like a hell.

To duplicate the timeline: it's the solution I'm actually adopting. For 10 minutes stuff is ok. For 1h stuff: please avoid it like a hell.

Why avoid it like hell Bart? You realise that Premiere 'solves' this by writing an entirely new project (containing the target sequence and media references) to a temp directory, and then sending that copied/temp project's sequence to the Media Encoder queue as the job source? In Resolve, duplicating the target sequence yourself and using that copy for the specific render job is effectively the same thing... and just like AME, we can either save the job (keep the sequence copy) or delete it (delete it) after the render is done. Don't get me wrong, I'm right up there '+1' ing your request, I'd like an option for using saved track status within a job... I think it could be an option for users to either choose to use or not and would, for some user workflows, obviate the need for making sequence copies... but the current required workflow isn't actually problematic in itself, its just more convoluted.

To duplicate the timeline: it's the solution I'm actually adopting. For 10 minutes stuff is ok. For 1h stuff: please avoid it like a hell.

Why avoid it like hell Bart? You realise that Premiere 'solves' this by writing an entirely new project (containing the target sequence and media references) to a temp directory, and then sending that copied/temp project's sequence to the Media Encoder queue as the job source? In Resolve, duplicating the target sequence yourself and using that copy for the specific render job is effectively the same thing... and just like AME, we can either save the job (keep the sequence copy) or delete it (delete it) after the render is done. Don't get me wrong, I'm right up there '+1' ing your request, I'd like an option for using saved track status within a job... I think it could be an option for users to either choose to use or not and would, for some user workflows, obviate the need for making sequence copies... but the current required workflow isn't actually problematic in itself, its just more convoluted.

Perhaps I expressed myself too quickly and with not proper words. My apologize
I ment: I see that for 10 minutes video it stucks therefor a while. I'm afraid to duplicate 1h. I wouldn't want it become totally unresponsive (and loosing the project, if ever the database is polluted with that instruction). You know, I developed a kind of allergy to the unresponsiveness of the programs. Just my fear.
I didn't tried yet to apply it to 1h footage, because I'm really afraid, and I avoid it like a hell
Viceversa I do use it for short stuff, because it doesn't hung up too much (although I'm always in tension when I do it)

P.S. I didn't tell Prémiére "is way beter" ... not at all. I just said that when I queue in Premiére, it was queuing the full status of the timeline. So, the point of Nathan, that underlines the kind of problems with such solution, is not existent ...

The way the Render Queue works currently, all that gets saved is a basic list of metadata: what timeline to render, the preset and preset settings, output filename, etc. Nothing is saved regarding the contents of a timeline, so whenever the job runs it always renders the timeline as it appears at that moment.

I imagine it would be reasonably straightforward to implement an optional system, where:
- There's a new option in Deliver: "Render timeline at current state" or "Save snapshot for render" or whatever wording.

- When this option is selected and the user clicks Add To Render Queue, a snapshot is made of the selected timeline, and this saved in the render queue. It would effectively be like saving a DRT export of the Timeline, inside the queue.

- When the job is later rendered, Resolve loads the timeline from the saved snapshot, ignoring its current/active state.

Because this would be controlled by a new option on Deliver, it would only affect those users who wanted it. The new option would default to off, so pre-existing jobs and presets would be unaffected.

I can't imagine this would be too hard to implement. But it would be a structural change to the render queue, so it doesn't seem to me like a change that would be done in a minor release.

But it would be a structural change to the render queue, so it doesn't seem to me like a change that would be done in a minor release.

I do fully agree with you. however in a major update I would expect these.
In the last minor updates they supported ASIO (which is great! A big thank you for that).
In another one they can implement a bit of what's required (an MVP: Minimum Viable Product).

then in a Major, I certainly expect this and perhaps also the improvement with Immersive Audio, for instance adding a binaural mixdown, so that it can be used also in music, and so on (just for example).

This surely.

I did notice big improvements andy major release. So, I keep my hope high