Either the linear mode isn’t working or the pattern mode, but it renders pattern by pattern in all cases.
Multi-track selection mode wouldn’t be a wrong thing either, in case some instrument plugins are routed to other tracks than the track that contains the notes for it.
And a minor correction:
-- We can only load 120 'notes' worth of patterns
if #renoise.song().patterns > 119 then
renoise.app():show_error("Sorry, track freezing currently only supports up to 120 patterns.")
return
end
You can load 256 samples if you would use the layering as well.
Are you copying Send devices over to the new track?
People need to be aware that if they were using a Signal Follower on the original track this will affect things assuming it was controlling a parameter on another track. Only way around this would be, in the even of their being a Signal Follower (with destination outside of original track, although this could be achieved through a Hydra) is to then copy the original track including DSP chain. Then delete all DSPs after the Signal Follower (except any Hydras just in case) then add a Gainer with -inf at the end to silence output.
Second point is probably far too much to worry about with this tool and best people consider the fact they may be using the track for more than it’s own audio themselves!
Great tool!
Perhaps an option to not freeze the DSP. Instead, add a new note column in the track you are freezing, add the freeze on this column and them solo this note column. Then you can still use all the DSP’s live.
I don’t have this issue? I’ve successfully rendered various tracks of the demo songs that come with Renoise in linear rendering mode. Is this issue repeatable? If so, could you post further details. Thanks!
Good idea! (Althought a bit of a hacky workaround). I added the work ‘currently’ into the error because I knew someone would think of a solution!
I did think about this but some users enable/disable DSPs with pattern commands.
I don’t really want to go through all patterns to identify, cut to memory, render and then reinstate all these commands - there is too much that could possibly go wrong. I don’t want to end up with a tool that becomes unstable and could potentially mess up users songs.
I’d rather (for now) let the user (duplicate, if required) and manually disable all track DSPs before freezing. If you have mixer view open you can easily drag and copy the DSPs to the frozen track and reinstate them afterwards.
Does this happen with normal Renoise rendering (i.e. song rendering?). I believe some VSTs have an issue rendering at speed (high priority). Try realtime or low priority rendering to see if it makes any difference.
The tool solos the selected track, if you solo the track you are trying to freeze does that also result in silence on playback?
I couldn’t reproduce.
The first thing i tried was the linear rendering and it did a pattern by pattern rendering.
I have tried several different combinations of rendering to see if i could get the problem back, but i couldn’t.
I figured out this is a problem on the Midi routing area.
I already commented out the solo lines in your tool (because i wanted to freeze the tracks that i didn’t muted and didn’t wanted the tool to mute other tracks for me).
But i use multiple instruments that are triggered by the Midi output of the first instrument.
Renoise disables Midi input triggering during rendering that’s why some instruments aren’t rendered.
Normal rendering is fine as well as high speed rendering to disk. I tried the realtime and low priority and a bunch of different vsti’s but still get the same missing first note. Hopefully not another problem specific to my system.
You could try toggling the “Static buffering” option with these VST plugins (click the question mark on the upper right corner for the vst handling options), missing first notes in a lot of cases is a static buffering problem (needs either to be on or off).
‘C:\Documents and Settings\tom\Application Data\Renoise\V2.7.1\Scripts\Tools\com.mxb.FreezeTrack.xrnx’ failed to execute in one of its menu entry functions.
Please contact the author (Martin Bealby | mxb (mbealby@gmail.com)) for assistance…
main.lua:516: attempt to index field ‘?’ (a nil value)
stack traceback:
main.lua:516: in function ‘unfreeze_track’
main.lua:575: in function main.lua:574
I’ve expected this “first note skip” behavior with Madrona Labs Aalto. Even if that checkbox is pressed (and even without that script, when simply rendering song). By the way, Aalto is very CPU-hungry.
I also noticed that panic is not called before rendering is started (though panic should be called automatically when the rendering routine is called, but i don’t know if this panic mode calling is embedded in the rendering routine or it is a separate process called before initiating the rendering routine). That might perhaps resolve the thing, but that is a thing for Mxb to add.
Taktik’s technical decision was “Let’s remove the “all controllers off” thing on panic completely, and only set the sustain pedal off. This is the only CC which could cause hanging notes, which is the only thing we want to fix here.”
I don’t know if this is behind it. But i guess this all controllers off thing also goes for plugins that might probably not be reset properly.
I’ve just uploaded version 1.21 (and 1.2 slightly earlier) to the tools page so it should be available when it has been checked and approved by the tool moderators.
Changes for this version:
Bug found by Tom de Rooy identified and fixed
Panic called before rendering as discussed above by vV
Tidied up the settings dialog to be more ‘Renoise’ like (thanks taktik)
Rendering settings (samplerate, bitdepth etc.) are stored and will the defaults for next time the tool is used. So, for those of you who set track headroom to -0dB in your song template (e.g. gmm04e) you should only need to set the compensation to +0dB once and it will be remembered.
