2 new FR's

[MattmaN]

Are there plans for more rendering options at differant bit depths, etc.
How about a render to tracks option where you can render all your tacks at once as seperate files.

The other FR is during midi recording it would be nice to hear your recorded parts as the sequence loops in toggle mode.

[muzycian]

Are there plans for more rendering options at differant bit depths, etc.
How about a render to tracks option where you can render all your tacks at once as seperate files.

Yes, that's definitely on the whishlist.

The other FR is during midi recording it would be nice to hear your recorded parts as the sequence loops in toggle mode.

That's not yet planned.

[DaveL60]

The other FR is during midi recording it would be nice to hear your recorded parts as the sequence loops in toggle mode.

I'm obviously not paying enough attention, because I'm not sure I even know what that means!

Dave

[MattmaN]

The other FR is during midi recording it would be nice to hear your recorded parts as the sequence loops in toggle mode.

I'm obviously not paying enough attention, because I'm not sure I even know what that means!

Dave

When you have Luna set to loop record you can hear as you play, but not whats been recorded until you playback the sequence.
I'm not sure if I understood myself the first time, lol.

[grizzly]

How about a render to tracks option where you can render all your tacks at once as seperate files.

This would be awesome, especially if the process would be taken so far, that Luna optionally also places the audio files on new tracks in the Composer at the right time, compared to the sequences where they originate from!

rgrds,

grizzly

[grizzly]

How about a render to tracks option where you can render all your tacks at once as seperate files.

This would be awesome, especially if the process would be taken so far, that Luna optionally also places the audio files on new tracks in the Composer at the right time, compared to the sequences where they originate from!

rgrds,

grizzly

Hi,

Quoting partly myself now, hmm . Anyway, just thought about this a bit further, and came up with some ideas that would help at least my workflow. The context is such, that I normally make sketches of songs with VSTi and some effects (some on tracks, some on busses). But when you want to make a final mix of it, there's a whole load of manual work ahead. Here's how unnecessary manual work could be avoided when preparing mixdown:

• - render all or selected VSTi tracks to separate tracks
  - automatic filenaming, e.g. Composer track name (?)
  - option to "normalize" (ie make each audio file as loud as possible without clipping)
  - place new Audio tracks in Composer, at the right time
  - make new Rack for each new Audio track, connect these, name based on original
  - copy VSTi track rack effects to corresponding new Audio racks
  - copy VSTi track buss settings to corresponding new Audio racks

While Luna is going through all these renderings, one can do something else or have a coffee . And when it's done processing, you are ready to start mixing down audio tracks instead of pre-hearing VSTi stuff.

I could imagine there's a lot of work involved with this kind of thing, but perhaps one day it could be partly there. To my knowledge there isn't such a process automation feature in other sequencers, so it could be world first for Luna.

I'm sure something vital has been left out, or something is just daft, in my list, so I'd love to hear other views.

rgds,

grizzly

[muzycian]

grizzly,

I wonder: once you would have rendered your tracks, what if you want to make a change to one of these tracks?

Then you would have to switch mutes so to hear the original track again, make changes, re-render and switch mutes again. Right?

My point is, rendering tracks and "Freezing" tracks are very closely related.

Rendering a track puts the track audio into an audio file, while freezing goes further, it even reloads that audio file and uses that to generate the audio of the original track.

In fact, when i think about this, i want to do it part-based, if possible.

I wonder: IF such part-based freezing/rendering system would exist in LUNA, then should the result be exactly the length of the part, or should it automatically include any tail (e.g. any reverbs or echos that process the part's audio)?

Mmm, still quite some thinking work to be done...

[grizzly]

grizzly,

I wonder: once you would have rendered your tracks, what if you want to make a change to one of these tracks?

I hadn't thought so far, actually. But I guess that then it'd be OK to go back to that (hopefully) single track, make changes and re-render just that track.

Then you would have to switch mutes so to hear the original track again, make changes, re-render and switch mutes again. Right?

Yep, that sounds right.

My point is, rendering tracks and "Freezing" tracks are very closely related.

Rendering a track puts the track audio into an audio file, while freezing goes further, it even reloads that audio file and uses that to generate the audio of the original track.

Unfortunately I'm not familiar with freezing. I've been away from sequencing the past years, when this function came to some sequencers, so I've only read about it. But based on your description here, it sounds like what I thought would be good.

How do Logic, Cubase and Cakewalk then do with final mixdown, are the freezed VSTi tracks at any stage converted to audio, or are they just treated as audio all the way (for all practical purposes)?

In fact, when i think about this, i want to do it part-based, if possible.

I'm not sure I followed what you mean here?

I wonder: IF such part-based freezing/rendering system would exist in LUNA, then should the result be exactly the length of the part, or should it automatically include any tail (e.g. any reverbs or echos that process the part's audio)?

For me it's clear that the tail should be included. But maybe there are use cases when one wants the exact measure, for example for making loops or such. Maybe user optional?

Mmm, still quite some thinking work to be done...

Yes, I can believe that. But thanks already now for even considering such functionality.

rgds,

grizzly

[DaveL60]

I think there's a distinction between freezing (as I understand it) and the FR grizzly made. As I understand freezing, the goal is to completely convert the track to audio, including all processing applied to the track,thereby recovering virtually all CPU power applied to that track. But I think was grizzly was after was simply to get the VSTi (i.e., the sound source) output rendered and replicate the effects chain and any sends with identical settings to the chain that follow the VSTi. This would only recover the CPU power consumed by the VSTi, but retain the ability to tweak the effects chain for tweaking. In essence, to move the track from a tracking / rough mix mode to a mode suitable for use in final mixing. Certainly for a hefty VSTi like ProteusX, this would be a very useful feature.

Given that, you wouldn't want to render any tail for what grizzly's after. I'd be 100% behind rendering tails in a traditional freeze, though, unless you want to make that an option. Given the ease of use intent of LUNA, I think it's much simpler to including tails when rendering a track (or part) to freeze it.

There's probably a little extra thinking here on how to handle multi-out or multi-timbral VSTis with either freeze or griz-render, especially if you make it part based. If one VSTi is supplying multiple outputs, it would seem that freezing anything less than all of them doesn't necessarily help much with recovering CPU.

DaveL

[grizzly]

Hi,

I think there's a distinction between freezing (as I understand it) and the FR grizzly made. As I understand freezing, the goal is to completely convert the track to audio, including all processing applied to the track,thereby recovering virtually all CPU power applied to that track. But I think was grizzly was after was simply to get the VSTi (i.e., the sound source) output rendered and replicate the effects chain and any sends with identical settings to the chain that follow the VSTi. This would only recover the CPU power consumed by the VSTi, but retain the ability to tweak the effects chain for tweaking. In essence, to move the track from a tracking / rough mix mode to a mode suitable for use in final mixing. Certainly for a hefty VSTi like ProteusX, this would be a very useful feature.

Yes, DaveL60 makes a good distinction here, that I didn't see myself. It is exactly the latter case that I was thinking about.

In addition to demanding VSTi like ProteusX, this would also benefit the use of RAM-demanding samples. OK, I should probably expand RAM from 1 giga, but with this I'm struggling to run the NS Free Kit and some other soundfonts in SFZ without crackling.

Hmm, on the other hand, here's probably a case where the freeze function would be handy .

Given that, you wouldn't want to render any tail for what grizzly's after. I'd be 100% behind rendering tails in a traditional freeze, though, unless you want to make that an option. Given the ease of use intent of LUNA, I think it's much simpler to including tails when rendering a track (or part) to freeze it.

For some VSTi I have so far used the patches built-in effects, for example the delays and verbs in Synth 1 are quite nice. Ideally one would, perhaps, always want to replace those with separate effects, but I'm not sure this is the case in the real world.

Perhaps for somebody who does all the patch programming from scratch, but I'm in tweak-a-preset land for the foreseeable future, and for me it would probably be too much work on most cases. Hence I see the case for preserving VSTi-inherent tails.

There's probably a little extra thinking here on how to handle multi-out or multi-timbral VSTis with either freeze or griz-render, especially if you make it part based. If one VSTi is supplying multiple outputs, it would seem that freezing anything less than all of them doesn't necessarily help much with recovering CPU.

Griz-render, I like that .

rgds,

grizzly

[DaveL60]

Given that, you wouldn't want to render any tail for what grizzly's after... I'd be 100% behind rendering tails in a traditional freeze, though, unless you want to make that an option. Given the ease of use intent of LUNA, I think it's much simpler to including tails when rendering a track (or part) to freeze it.

For some VSTi I have so far used the patches built-in effects, for example the delays and verbs in Synth 1 are quite nice. Ideally one would, perhaps, always want to replace those with separate effects, but I'm not sure this is the case in the real world.

Hadn't thought about VSTis with built-in effects (even though ProteusX has 'em), but I think Griz has a point that you'd want to include tails there. OTOH, since the tail is coming out of the VSTi as an audio stream before an VST effects, there may not be much practical difference.

Griz-render, I like that .

Well, after all, it sounds like a bear of a task to go through all the steps you listed on a large project.

DaveL

[muzycian]

Hey guys, this definitely is a very interesting thread concerning a very practical feature, and i'm looking forward to deep this further out!

But let me also present you LUNA Modular : http://www.kvraudio.com/forum/viewtopic.php?t=169949

[grizzly]

Hi,

I came to think about another, related feature, that would be neat. I usually lay down drums on one track (one part in Luna-speak, I'm not sure yet?). When mixing down I'd prefer to process different drum parts differently, when it comes to e.g. compression, verb and EQ.

Another great timesaver would therefore be the possibility to render just selected notes inside a composer view. That way I could choose to render bass, snare and hihats to separate audio tracks in one go.

rgds,

grizzly

PS. Related to this, it would also be good to be able to select the whole row of notes by clicking on the piano roll key. Currently this plays the sound, but selecting all C2 notes would make it easier to shift them two steps up to e.g. another drum sound.

[muzycian]

Hi,

I came to think about another, related feature, that would be neat. I usually lay down drums on one track (one part in Luna-speak, I'm not sure yet?).

A track is the full horizontal lane, a part is one "block" on a track

When mixing down I'd prefer to process different drum parts differently, when it comes to e.g. compression, verb and EQ.

Another great timesaver would therefore be the possibility to render just selected notes inside a composer view. That way I could choose to render bass, snare and hihats to separate audio tracks in one go.

You then have to split the sequence so that you have a part for the bass, one for the snare etc...

PS. Related to this, it would also be good to be able to select the whole row of notes by clicking on the piano roll key. Currently this plays the sound, but selecting all C2 notes would make it easier to shift them two steps up to e.g. another drum sound.

That's in the Piano Keyboard context menu.

So right-click (osx: control-click) on the note you want and choose "Select All Of This Note"

[MattmaN]

After thinking about it.
For professional use(to render each instrument seperately) I think it would be better to be able to render mixer channels, since when using multi-out vsti you often have sounds routed to differant mixer channels.
Rendering to parts should stay, but render to mixer channels would provide some more versitility with multi-out vsti.
Could apply to Luna modular too?