Preview Or Pre-render Feature Request

hi!
I was observing Renoise development for a long time and I decided to buy it as for me it seems that is one of the best trackers around. Great work guys!

However, for me it seems it lacks one of quite important feature. Actually, I was using non-linear video editing software a lot in the past (like AVID, Final Cut Pro, Adobe Premiere). And the idea comes directly from such software. There we are able to mark some certain fragment/track/effect of the movie to be pre-rendered for preview. For example I was able to successfully cut and edit full HD material on a very old machine using this feature as I pre-rendered all my effects before playing.

It would be very nice to have such feature in Renoise. It is something like combination of “Render selection to sample” feature, however more sophisticated. So how does it work in general?

Firstly user selects tracks or places marking them that they should be pre-rendered. Rendering should be done automatically before playing. Pre-rendered data is stored in the temporary folder. So for example if I put a lot of computationally expensive effects on one track it should be pre-rendered every time I change something and played (mixed with other tracks) from already rendered file. Of course it is clearly visible (hearable) that pre-rendered part is little bit different as draft one, but we have in mind that it is a preview. The idea behind that is quite simple. Instead of user who have to select, right click, render to sample, mute tracks with VSTs/effects, add another track, put “rendered-to-sample” instrument and also having in mind that before final render we have to remember to mute rendered-to-sample tracks and unmute computationally expensive ones - the Renoise should do it for us automatically.

For example:
On track 1 I have many effects and it is not possible to play this track with others as CPU usage goes very high. So I mark this track/notes to be pre-rendered before playing (for example using “dark blue” color). Then I hit play. Renoise shows me a dialog “rendering preview”, and it renders all such marked places for me automatically. When rendering preview is finished, it starts playing normally, however taking pre-rendered data for final mix instead of realtime mixing effects.
When I hit the “play” button again, already pre-rendered data should be taken from the temporary folder for such marked places. However if I change for example just one note on such track, after I hit “play” that track should be pre-rendered again. It is obvious that first pre-render takes longer time before play, but it allows us to use as many effects as we would like to have and also gives us free mind as we do not have to play around with “render selection to sample” all the time.

I hope you understand it a bit, it is very nice feature in video-editing software I’m using a lot. I was surprised that it is not implemented in the Renoise. I know - somebody will say that “come on you have render-selection-to-sample, don’t bother”, my answer is simple: “yes, but should I click and mute/unmute/remember which tracks were rendered to sample or should it be done transparently by the software?”
:slight_smile:
I assume this is not so complicated feature, and as I’m also a programmer I think it could be implemented quite easy. Just we have to remember where to store preview and when to play/render it :wink:

cheers!

Nice idea. I could use a feature like that. Although, i would like each track to have a small checkbox wich you could click to have that track always make a preview sample like you explain. when that button is checked original track data and DSP, could be automaticly disabled to save CPU power. although when rendering the whole song rendering should use best possible quality not the previews. =) Nice idea, and i would use it quite a lot. since my songs tend to get quite resource heavy after a while.

Search the forum for “freeze” and other similar phrases, and you will find many people talking about this feature request.

yeah, like Dblue said…this sounds like a ‘freeze’ function request. I guess plugin delay compensation should be added first then if this’ll ever get implemented.

for example FX Freeze VST does not re-render if I change just one note, right? I know that HDD streaming could be tricky, but such preview feature is a really nice one.

Correct. When using an external VST to handle the freezing/preview rendering, there is really no way for it to detect changes to the song structure in Renoise. You would have to manually re-freeze/re-render after you make any changes. (And you might as well use Renoise’s render-to-sample in this case)

Yep, it would be very nice!
I think lots of people want this freeze/preview function, so don’t worry, you are not alone :)

Good :)
I used to create really CPU expensive video material using just a common machine, so it is possible - and the video stream takes more resources.

+1.
The way you suggest this feature here is more interesting than the feature itself :) I’m a premiere user too, and I exactly got what you meant. Such ‘preview’ or ‘freeze’ or anything-called feature can be one of the most important advancements in trackering & renoise, also a very good solution in handling long samples.

Exactly.
Unfortunately after about one week playing around with Renoise I decided to come back to the other software solutions I was using before. Yes, it’s one of the best trackers indeed but I think I’m too lazy to render-to-sample bunch of DSPs and cut long vocals/live instrument recordings to fit my patterns. Certainly, lackness of the “preview” feature is a big hole here. Hope to see this feature soon!

please read this
http://www.renoise.com/board/index.php?sho…7&hl=freeze
i need this feature too) but developers say that it will be implemented in future)

this feature will be one of the best. becuase cubase containe it now.
FX Freeze vst dont work as i wont and sime time dont work correctly. And native feature will be better.

Hmm, so it’s really some demand on it.
I was thinking a little-bit about these features from programming point of view.
So let us assume we’ll have one temporary file per each pattern arranger position. Actually I saw AVID’s temporary folder and it’s full of small files, so I think they store preview data in several files not just one. Obviously that way we need to perform many open/close file operations all the time (which I don’t like) or keep many file handles opened (in a pool?). Other solution is to have just one preview file for each song, but with this one we need to completely reorganize it if we change the pattern length (but it’s not so bad idea though). Also we could think about having one file just for each pattern, but what if some patterns are played in different tempos?

[preferences dialog]
add option to set the temporary folder

[loading song/new song/new pattern]
for every arranger position check if we have preview selected and alloc “preview information” with each position
alloc and check raw-audio files in the temporary folder if they need to be rendered (using some pattern’s last change time/version stamp)

[pattern editor gui]
add possibility to select tracks for preview (have to add additional attributes to the pattern structure/object)
every change inside the pattern clears the ‘preview-ready’ marker

[player]
this here is quite complicated as I assume we need to have another thread to read the preview from a file and a song parsing engine which is always few ticks before the realtime rendering one, sync issues and also additional thread communication is neccessary; reading chunks of data from preview file should be done into synchronized circular buffer (kind of FIFO). If we’ll store each track preview in a separate file I think we’ll get the HDD-speed limit quite easily, but we have to take into consideration that this is a preview, so I suppose we can perform dirty-mix of ‘previewed tracks’ and mix them later with the master track or store tracks in chunks, interleaved one after another; however I think this should be decided by the user (“perform preview mix?” option in preferences).

in ‘start playing’ and ‘pattern advance’ function: check if we have preview for upcomming pattern rendered
if not:
…stop playing
…show dialog
…render preview:
…triggering only selected tracks
…optionally pre-mix them not taking into account effects on the master track
…store tracks or pre-mix to file
…update preview information in the song structure (put time stamp/increase version)
…resume playing.
if yes:
…open/seek to the rendered preview

in real-time-player thread:
…render tracks normally but without these selected for preview
…get chunk of data from circular buffer
…mix rendered tracks with data readed from preview, apply master track effects

  • every ‘start playing’ should force the reading-preview-thread engine to very fast “play” few ticks to fill the buffer before real-time playing thread
  • every ‘move/change pattern position’ should force the reading-thread engine to seek the preview file and very fast “play” few ticks to fill the buffer before real-time playing thread
  • changes in the preview-marked areas during playing should not be possible (if tracks are pre-mixed even volume changes in the mixer will not give any hearable changes).

And some changes to the ‘render to file’ (also for preview-render), so we can have negative plugin delay-compensation (should play earlier) quasi-solved:
every track should have a circular buffer added. each track’s circular buffer length depends on the selected delay-compensation value. tracks that have highest negative delay-compensation value abs(HVAL) should have circular buffer length set to 0. others should have more samples, from equation: (abs(HVAL) - abs(actual negative track’s delay compensation)). if track does not have any delay-compensation the length of a circular buffer will be that one from the highest negative delay: abs(HVAL). then we start rendering/feeding data into circular buffers normally, however storing the result from buffers after abs(HVAL) samples have been rendered. Obviously positive delay-compensation (should play later) can be performed in the same way: circular buffer should have (abs(HVAL) + positive track’s delay compensation) length. Hope I didn’t mixed abs’es ;> Of course this creates latency so isn’t perfect solution for realtime-rendering.

Such implementation solves two things, as plugin-delay-compensation could be performed via rendering preview - but this is some solution anyway.

problems:

  1. tempo changes:
  • it’s neccessary to calculate for each song tick the position in preview-file to be able to seek…
  1. sends
  • what about sends…?
  1. for long-duration effects/notes it’s neccessary to have tracks previewed for a whole song (thus many patterns), so assumption to have only one preview per each arranger position is not so good. during preview rendering of the pattern it’s neccessary to go back and render from the previous note (in previous patterns), or even re-render whole song (maybe mark such tracks somehow manually?)

Anyway, as we can see it’s quite complicated feature to implement (but solvable ;))

:w00t:

-> move to “Feature Design” subforum?

Wow!

And while you are at it…

Let’s get the automation curves from Adobe Premiere put into Renoise. I was using the AMAZING automation curves that move like HEAVEN in Premiere over 3 years ago. This should be in Renoise now.

Hell, even Logic had these curves in 5.5 which is soooo old now.

Keeping all the file handles opened could lead to problems on windows machines in bigger projects. The CRT allows a maximum of 512 open files per process, which can be raised to 2048 if needed. When running in a VM this is often limited to 256. See _getmaxstdio() and _setmaxstdio() on MSDN. I guess there is also some sort of upper limit of open handles for the operating system too.

That’s why I suggested a pool of opened file handles (for example 250 handles at time), kind of: http://en.wikipedia.org/wiki/Object_pool :slight_smile:
For example: having the limit of 2 simultaneously opened files:

  1. we would like to access file #1:
    we open the file and put to our pool
    POOL: #1

  2. we would like to access file #2
    we open the file and put to our pool
    POOL: #2, #1

  3. we would like to use file #1 again
    we get it from pool.
    POOL: #1, #2

  4. we would like to use file #3
    we remove file #2 from pool as it is last in the queue, close file #2 handle, open file #3 and put to our pool
    POOL: #3, #1

etc.