Rendering Or Merging Clips Doesn't Work

[spoontechnique]

When I try to merge or render clips, the progress bar comes up, but nothing ever happens. It just stays at 0%. Am I missing something obvious or is this a known bug?

[spoontechnique]

To clarify, this applies to all versions of rendering, including merging, rendering, and flattening clips. And by 0%, I meant that the progress bar shows no progress, not that it shows a value of 0%. I've waited up to 15 minutes on a clip and still no progress.

[jabe]

Rendering is working okay here and is fairly much immediate.

[PierreG]

Rendering via Export has been working well for me on version 9.2.2.

This is likely nothing to do with your issue, yet it's a recent rendering observation I reported to Tracktion Support.

"This one had me scratching my head for a good while, yet I finally figure out what was going on.

When you render with Automation Read Mode turned off, and you have volume plugs that have automation tied to them, they will be muted when the render takes place, thus producing a blank audio-less render. This seems like it's intentional, yet I don't see why this would be helpful. I would like the option to create renders with automation settings disabled, so hopefully this is resolvable.

Thoughts?"

[spoontechnique]

That's useful information, but it still doesn't work. Not even for midi clips.

[PierreG]

Did some more testing and discovered that I can duplicate this issue when rendering clips inside a submix. Moving the clips out of the submix resolved the described rendering issues on my system (9.2.3).

This is strange, in that I've been rendering whole edits successfully that are full of submixes. I just verified that I can still render submixes correctly, as long as I'm not specifically selecting clips to render that are nested in submixes.

Is dRrowAudio in the house?

[dRowAudio]

I can confirm this is an issue. It's probably due to the fact that if you try to render a clip in a sub-track, only the track that the clip is on will be included in the render. As that track isn't directly feeding the output, there isn't anything to actually render...

How would you expect rendering of a single clip within a submix to work? For example, if you're rendering an audio clip with a delay on the track and then a reverb on the submix track, should the reverb be included in the render?
If you then simply replace the clip (with the rendered delay and reverb applied), the submix's reverb will still get applied, making it double "reverby".

What would everyone expect to happen in this kind of situation?

[HansP]

technically, let me suggest "orthogonality" i.e. all principles have enough independence from each other so that we can have meaningful superposition.

in this example, the question of replacing the track that is under submix hierarchy, by itself answers the question about switching on or off the effects that come in the umbrella hierarchies.
but it has to be visualized.
so the typical problem of software engineering remains, that the sequence of user decisions and popup forms with [x] options may not be in sync with the logic of the process itself.

a short hack for this might be to repeat an option if it has become questionable, while going through the chain of decisions and necessities.
(a question like - "replacing the track means we should switch off all effects _after_ this track, ok?")
for the switching itself, a versatile workhorse function about all that solo-ing and muting, including the intelligence behind the "track freezing", would have to be invoked. its smartness resides in re-use of the positional information of the "freeze ice crystal" in the graph. you can create a temporary virtual freeze point just for the sake of passing on this information to the plugin-mute mechanism.
it has parameters that tell it where we are coming from at all, so it understands the goal of the switching. this workhorse would also have its own data storage about previous status, in more than one dimension, qualified by the purpose of what happened to change that status.

[dRowAudio]

But that doesn't relate to the case where you're rendering or merging Clips. In this instance, you might have other clips on the track which you haven't rendered and hence removing any plugins etc. from parent tracks would affect these non-rendered clips.

I also don't like the idea of some kind of "stateful" rendering process that "its own data storage about previous status", this makes it unpredictable in operation, basically impossible to document, difficult to implement (what happens if you shut the app down and then start it up again), and different for each user/computer etc.

A render operation should be simple and predictable. If the behaviour isn't well defined, then it shouldn't do the render operation. Perhaps we just need to add a warning display about why the render can't be performed?

[chico.co.uk]

I'd question what you're trying to achieve, rendering a clip deeply nested in a submix. What's the use case, why d'you want to do it?

[Robert Randolph]

But that doesn't relate to the case where you're rendering or merging Clips. In this instance, you might have other clips on the track which you haven't rendered and hence removing any plugins etc. from parent tracks would affect these non-rendered clips.

I also don't like the idea of some kind of "stateful" rendering process that "its own data storage about previous status", this makes it unpredictable in operation, basically impossible to document, difficult to implement (what happens if you shut the app down and then start it up again), and different for each user/computer etc.

A render operation should be simple and predictable. If the behaviour isn't well defined, then it shouldn't do the render operation. Perhaps we just need to add a warning display about why the render can't be performed?

Would it be possible to have a process that moves these newly rendered clip to a new "blank" track below with the same routing routings.

It seems like that would achieve the goal of the user in most scenarios.

[Lutin mutin]

I have an other point of view in order to try to have ideas to answer to the dRowAudio question :
"what the other well known DAWs do in the same case ?"

[dRowAudio]

I have an other point of view in order to try to have ideas to answer to the dRowAudio question :
"what the other well known DAWs do in the same case ?"

Yes, I think that falls in to the category of being "predictable". What do other hosts people use here do in this situation?

Would it be possible to have a process that moves these newly rendered clip to a new "blank" track below with the same routing routings.

It seems like that would achieve the goal of the user in most scenarios.

Possibly... but then we'd have to hide all the "render replacing" options in the render window just for this use case which feels like a bit of a hack. I also think the behaviour of this at the moment would be to render to a track and place it after the current track which means it would still be in the submix.
Again, I think this means adding special cases for plugins in a submix where they behave differently to every other case.

There's also no full way to replicate the routings once you've moved the clip out of the submix. What if there was a Rack or aux send somewhere in the signal chain but not right on the end?

I'd really like to know what the OPs intention was when doing this as that would at least help us to research what the desired behaviour should be.

[spoontechnique]

I'd really like to know what the OPs intention was when doing this

Initially I was using submixes as buses for almost everything, so I thought rendering was just broken.

Recently I was trying to render tracks of drum multis (setup like the tutorial video or Chapter 44 of the manual about using multi-output racks with MTPower Drum) within a submix and I discovered this applies to tracks as well as clips. I suppose it's a non-issue, since I could pull all the channels out, render them, and put them back. But this means that submix behavior isn't what I expected.

With rendering clips, it makes sense that rendering them would apply the effects of a track twice, unless you move them out to a blank track. ut with rendering tracks in a submix, I'd expect different behavior. If I have a submix with reverb on it containing a snare with distortion on it, I'd expect rendering the snare track/clip to give me a snare with distortion that only has reverb applied once as it goes through the submix.

I guess submixes are a different kind of thing than I thought. My assumption was that the tracks within the submix output audio to the submix, so changing the tracks within a submix doesn't break the submix. If that's not the case, I've found nothing in the Waveform manual to indicate what submixes are actually doing.

[dRowAudio]

No, that is how submixes work, but because they route through the submix track, you can't render the sub-tracks without also rendering the submix track. I do agree though, it should be possible to render a whole track within a submix which would effectively render that track but not through the submix.

Hence if you had a MIDI sub-track with a synth on the submix, rendering that track would yield a silent render.
I'll see if I can add that without too much hassle. It could be complex though as all the routing with submixes is handled automatically...

Are you sure you don't just want a folder track? I think you can render contents of folder tracks without a problem (as the folder VCA just works as a volume scale) but I could be wrong on that.