render item to new take should respect item looping logic

[deeb]

in this example i would expect that rendering to new take could keep the looping:



This is just a small example for demonstration since usually loops are much longer and probably full song.

If i render an item with 1 bar looping for 150 bars, the rendered take should be also looping 1 bar during 150 bars, but Reaper just renders 150 bars and ignores it's a loop that i am rendering.

Reaper by doing this takes more time for rendering and just eats disk space with no need, and give user extra work for going back to the original looping need.

[Sibben]

REAPER is a linear arranger. It makes sense for it to treat looped items as a convenience of content creation rather than an architectural paradigm. Not saying it has to be like that but from a design standpoint it’s a reasonable way to handle it without having to figure out which parts are identical and can be rendered only once. The renderer can just chomp its way from left to right and punch out whatever it encounters. I’m guessing.

[deeb]

Originally Posted by Sibben

REAPER is a linear arranger. It makes sense for it to treat looped items as a convenience of content creation rather than an architectural paradigm. Not saying it has to be like that but from a design standpoint it’s a reasonable way to handle it without having to figure out which parts are identical and can be rendered only once. The renderer can just chomp its way from left to right and punch out whatever it encounters. I’m guessing.

I really I don’t get the point of why it is logical and I don’t see any benefit of current logic. I just see disadvantages here.

[Sibben]

So what would happen if you have effects that modulate over time? Like a hi-hat line with a phaser.

[deeb]

Originally Posted by Sibben

So what would happen if you have effects that modulate over time? Like a hi-hat line with a phaser.

I see your point now. Thanks. That is the only exception use case in which what I am proposing does not fit. I would never have a phaser on the item in that case and I would use the tools according to what I need. If I need a phaser on the item then I would put that phaser on the rendered item take. The thing is what I am proposing give options to work however fits the need, while the lack of it give us no option and all the disadvantages I referred ealier.

I know you not desagreeing with me, you just pointing there is an exception. Thanks

[Sibben]

No problem. Cheers.

[deeb]

The exception that Sibben told doesn't remove the need and the benefit. We have brain and we use tools in the way that benefits us! Or please make this optional

[heda]

Looping the rendered item could cause glitches in the loop point, like non continuous sample points. It doesn't necessarily create a seamless loop like the MIDI did.

[deeb]

Originally Posted by heda

Looping the rendered item could cause glitches in the loop point, like non continuous sample points. It doesn't necessarily create a seamless loop like the MIDI did.

Thank you Heda. I understand that this could be an issue in some situations but if by option or by having a different action then we could use when appropriate and not use when it is not. We could save CPU , Disk space and time if used in the situations that it makes sense. I would put Things like phasers , delays, reverbs on the top of the rendered item.

I mean in term of availability of the tool makes sense. And one tool does not make the job of everything. We use them when there is benefit and not use when there is not, right?

[heda]

It is ok. I agree it could be interesting and work ok in many cases. This could be done with a small script action.

[deeb]

but yeah, at this point i get that is more of a request/wish then a nitpick. Thank you Heda!