I’ve experienced a very weird behavior in a recent song of mine where rendering it would seemingly randomly stop at different times in the song but never the end. sometimes it would stop 2 and a half patterns before the end of the song, sometimes it reaches the end and wraps around when the progress bar isn’t even half filled.
After some tinkering I found out what causes it: Changing BPM using Hydra does weird things when rendering.
Here are the steps to recreate the scenario:
render the song
expected outcome:
the song gets rendered once, the rendering has the length of the song just like it’s playing live in renoise. after rendering is complete the play position rests on the last line of the last pattern.
actual outcome:
the rendering will either stop before the song is over or it will repeat the song multiple times, depending on the bpm that were set for the line your play position was at just prior to hitting render. after rendering completes your cursor most likely doesn’t rest anywhere near the end of the last pattern unless you got lucky.
this does not happen when you automate bpm directly in the master track without using hydra, but I like using hydra to set bounds for my min max values in order to have more fine grained control (who always needs a range from 32 to 999 anyway?) and in order to use the max as a hard limit so I know I’ll always return to the value I’ve previously used after a temporary tempo decrease. It also makes making the whole song a bit faster or slower really easy after you’ve already automated BPM during composing.
I believe this is in dire need of a fix because under no circumstances would anyone expect the behavior that can be observed
I think this doesn’t work because the BPM change is applied when the next row is processed, because the BPM change is done before the Hydra is given a chance to change it (hence the change the hydra submits, is applied in the next cycle).
I think a fix could be to make the BPM/LPB/TPL part of the post mixer or put it before any DSP device that can control these automation values.
But i’m not sure that is really the issue.
I could imagine a possible 2-pass rendering fix:
First pass:run without playing any notes, but apply tempo changes and lock the end time for rendering. (first pass could be done in the background with a status message:“Calculating song time…”)
Pass 2, render with notes, the way you see things happening now but cut at the given pass-1 calculated time.
Then random outcome is desired.
including too long recording or too short.
You can’t expect software to be capable of synchronizing a lot of elements based on precalculations with random timings.
Also it is not expected you want to render such kind of outcome. these are situations that perfectly fit live performance but prerecording not so much, afterall:once rendered, it will sound the same as rendered anyway.
So randomizing bpm for rendering doesn’t make any sense here.
What about a function to bake bpm changes of devices to the bpm automation lane of the master track? Random crazy LFO would not be a problem then.
I can well see a reason to have some semi random events in a song I’d want to render, if just for the ease of making them happen. (Random LFO that creates desired results most of the time is easier than hand-automating the same effect)
Extend that to baking any meta output to the corresponding automation lanes. It would be more of a new feature, but I can see a lot of use for it
(right click output of hydra/LFO/etc. select bake to automation lane, output gets disabled, ready to be re-baked at a later time if so desired)
you know… actually, why are we complicating things so much? … why can’t the renderer have a kind of open ended mode without a progress bar or some pre-allotted space, and just stop when the play position hits the last line? it is updating the GUI live after all, so it knows the position of the play head at all times. How hard would it be to have it run until it hits the wraparound point, then just stop?
I could see it as a third mode alongside realtime and offline. It could even still have the progress bar, just not based on time but based on lines left until the end of the song. The most elegant solution could be having it rolled into the other rendering modes and it gets triggered automatically when renoise determines there is a meta device modifying BPM
No it doesn’t.
Renoise has to buffer VST plugins and incorporating their delays to synchronize them properly with the rest of the tracks, so it has to do ahead calculation of what material is coming and trigger plugins on the right time to send them the correct parameters.
I would be surprised if synchronizing vst plugins would work at all with randomized bpm changes (try it).
