Topic: Slooooooooow offline render (with possible cause)

@Zynewave wrote:

If the effect plugin CPU usage is constant no matter the input (even silence) then the bounce render time is proportional with the length of the bounce event.

That may very well be correct but even the zReverb produces a slow bounce. As does every plug in (Kjaerhus and Voxengo) that I have tried so far. These are of course very popular plugin developers.

Perhaps I misunderstood what you said but it does not appear to make any difference to slow bounces even with zPlugins.

When a new bounce track is created the sound event is set to the length of the arrangement.

In a nutshell this is the problem. Offline renders as far as I can tell are accurate and precise. It’s just the way the sound event is created that is the problem. Changing that (as I suggested in my initial post) solves this problem.

If you want it to be shorter just resize the bounce event.

Yes that works but is not something I would want to do every time. Offline bounces are much quicker than realtime bounces especially for longer passages of audio. It is supposed to make things quicker. In it’s present state it doesn’t.

You can also press undo once after creating the bounce track. This will undo the bounce event creation. A second undo command will undo the bounce track creation.

Correct but again I would much rather have Podium do the work, not me by Podium not creating a sound event that is based on the length of an arrangement in the first place. That is clearly what is causing slow bounces so fixing that either by using the suggestions I made (or anything similar) solves the problem.

It really becomes a problem using offline renders for high track count arrangements if workarounds have to be used every time. Seriously Frits.

Too many workarounds in a host can build up to a point where they just waste precious time trying to keep track of them all, when a given feature really should just work properly. This has always been one of Podiums strengths and is why I started this thread. Your track record for fixing bugs is exceptional.

@acousmod wrote:

And don’t forget to place a Punch in point if the bounce section doesn’t start at the begining, because Podium calculates all the blank space from the begining or the punch in point.
Or has this changed ?

I just checked this out in 1.72. I placed a two bar loop at around bar 70 and an equal length blank event above it on the bounce track. It did take longer. So that is still a problem.

So really there are two bugs here.

1.The slow bounces caused by the connection between the arrangement length and the sound event that is created. Should be separate.

2. Podium calculating the blank space at the start of an arrangement into the bounce render process. Perhaps there is a different technical way to describe it but that is what is happening.

Here is a very interesing twist to the first bug…

I just tried the New Group Track option instead of the New Group Bounce Track and it wraps any track in a bounce track, of course this has been around for some time but crucially it creates an empty bounce track, leaving the user to draw in their own sound event length.

So the already existing New Group Track option already works in the same way as option c in my original post…

“No Bounce Sound Event. User configures length option will simply stop Podium from creating any sound event when the New Group Bounce Track option is used. Allowing a user to draw in the exact length he wants anywhere on a Group bounce track instead, to ensure a normal and much faster offline bounce every time”.

So frankly this makes the New Group Bounce Track in it’s current state a longer, and more time consuming way to bounce a track.

I guess the New Group Bounce Track option was designed to speed things up by offering a dedicated bounce track option available on right clicking but it is much quicker instead with the New Group Track option.

I would much rather prefer if the New Group Bounce Track option remains in Podium but with some way to accurately produce a sound event length for any clip in a quicker and much more efficient way. Many hosts do not even need to draw in a sound event first. Perhaps looking into a way to avoid the need for a sound event to bounce to, would eliminate the problem of sound events being too long?

Definitely two bugs here with slow bounces and Podium calculating blank space into render processing time.

@acousmod wrote:

I don’t think that these could be called “bugs”.

Bugs, design flaws, unforseen problem areas, in any case they are not working as they should or could.

The first one is something logical : if you render a longer file, it takes more time..

Of course as in any host. But…a slow bounce is not logical unless Frits always wanted offline bounces to be slower than other hosts which would be another matter entirely.

The second one must be corrected. If I remember well Frits has said that it was on purpose to be sure that the end of a previous event was not missing in the render.

We are slipping into developer issues here which is just not my area of expertise so I have no idea if Frits can change this behaviour. It would be nice if it could be done. To avoid slowing offline bounces down.

Perhaps the problem is also that we must use the bounce track feature for very differents purposes : freeze, premix and final bounce.
In an ideal software, there must be perhaps different actions and results.
For example :
– freeze : click on a button and the content of a track (and sub tracks) is temporarily replaced by a rendered version of all the used segments (not the silences !) which is invisible for the user, and can be “unfrozen” at any moment for editing
– premix : the actual bounce track feature
– final bounce : a simple menu that bounces all the arrangement (or a selection) directly to the disk, without the need to creating a bounce track and saving the file after.

Maybe…I think Frits has made a great effort to include offline renders into Podium however as Podium continues to mature it is not really so much major features that are needed (outside of a few) but more a case of refining the great features that are already there. Hence this thread. 😉

But the current offline bounce technique in Podium is already good for me, except for the workaround at the begining

It is good yes but I would prefer to not have the workaround as well.

@Zynewave wrote:

Conquistador: If you have a project using zReverb (and only zReverb) that suffers from the slow bounce, please email it to me. I think it may be easier to understand what you’re talking about if I can see it in action.

Ok…a basic project has been sent over. You only need to simply render the track as is. But try it a second time, but this time draw in a sound event that is equal to the loop length. If you need the original file I can send that over.

With longer passages of audio it is even more noticable. It simply takes longer to get a rendered file when the sound event on the group bounce track stretches to the end of a project than when it matches the file size to be rendered (on the child track).

The problem persists with any length of file.

@Zynewave wrote:

Ok, I did not find anything unexpected in your project. It works as intended.

If you mean the bounce process was accurate, then yes it does work as intended. It’s the slower bounce process when using the New Group Bounce track sound event length (which is as long as an arrangement) that I was trying to draw attention to here.

Even though your audio file playing into the reverb is shorter than the bounce event, there is no way for Podium to know that the plugin will be silent after the audio file has stopped playing.

You are talking about Podium not having any way to know the plugin will be silent. Maybe there is no way, but it should matter either way. It certainly should have no negative bearing on the speed of an offline render.

The necessity that Podium has with a sound event to bounce to, is really I think, the real problem here as other hosts that I have use/d, Tracktion, P5, Live, Sonar, Cubase e.t.c do not need a blank sound event to bounce to for offline rendering.

In the case of zReverb you have the tail that slowly dies out. Other effect plugins may produce audio continuously. So Podium will process the entire length of the bounce event (even if only feeding the plugin silence), because it assumes that the bounce event is set to that length for a reason

All well and good but…Podium really should not be processing the entire length of a blank sound event because it is causing slower bounces. Why process a bounce sound event that is 80 bars long when the child track event is one bar!

Fx tails in other hosts can be included without the necessity for a sound event that stretches all the way to the end of an arrangement…by default every time.

I do not know of any host that does this. Yes of course it does the job in Podium but really this area of Podium is behind other hosts. Some refinement to the feature cannot hurt surely.

In other hosts I simply select the track and bounce the contents of it. Simple. Or select a particular clip on the track and bounce that. Podium would benefit greatly from that level of simplicity with offline bounces.

Podiums realtime bounces on the other hand are fantastic and unique. Just not as fast as offline bounces for longer audio passages.

The need for a sound event for offline rendering makes the process work in Podium, but is slows it down compared to other hosts.

In the case of zReverb you’ll notice that once the progress bar goes past the section where the audio file is playing, the bounce render speeds up significantly because the zReverb is optimized to consume less CPU when input is silent and the reverb has died out.

But it is still slower than if I had drawn in my own sound event on the bounce track and then rendered. Every FX I have tried in Podium has this issue. zplug, kjearhus or Voxengo.

Btw. The bounce render even for your long bounce event took less than a second on my machine, so it was difficult to notice any difference between a short and long bounce event. How long does your render take with the long bounce event?

To make this clearer I have copied the file four times and then bounced with a long bounce event, (as long as the arrangement) it took about 5 secs and with a short bounce event that was only as long as the child track events it took about 2 – 3 secs.

Whichever way you look at it and however small or not the difference my be to you offline rendering is slower with a longer bounce event.

I am not the only one who has brought up the issue of slow bounces.

Perhaps if there is simply no way to avoid the use of a bounce event in Podium for offline renders because of the way it was designed (just guessing here) then the bounce event IMO could always be a little longer or as long as a child event but Podium could intelligently add FX tails to a render.

How do you get FX tails in a render?…you might ask, well other hosts have an option to include FX tails in renders. Perhaps this is how they avoid needing a blank sound event to bounce to.

Either way it works very well in other hosts. Or is faster as it does ‘work’ in Podium of course, but slower. Unless the bounce event is drawn in by a user.

I really think the suggestions I made in my first post on this thread will help. Here are some more…

1.(a) The provision of a user configurable FX tail option.
Let the user decide if FX tails will be included in a render.

1.(b) Allow a user to configure how much additional length will be added to a bounce sound event…1bar, 2bars e.t.c But the default length will match the child track event/s that are selected. This option allows for any user configured additional length to be added to that default length.

2.(a) Avoid the need altogether for a blank sound event to bounce to, as this is another step to take which is just not a necessity in the hosts I have used, and clearly slows offline renders down.

2.(b). Allow any individual clip to be rendered from a track or all clips on a track.

2.(c). (Same as 1a) Allow a user to configure how much additional length will be added to a bounce sound event…1bar, 2bars e.t.c But the default length will match the child track event/s that are selected. This option allows for any user configured additional length to be added to that default length.

In summary (yes I know it is a long post) 😉 …
I am just trying to suggest ways to refine the offline bounce process here Frits. It can and should be better. Especially compared to other hosts. 😉