I often freeze a track to render a single clip to audio. As my set grows larger, there are more and more midi clips on a given track. This prolongs my time to render significantly. So much so that I just create an audio track and resample. This is inconvenient. Please make a feature to render a single midi clip to audio. I think you could simply extend the freeze function to a single clip, apply the same colour scheme to denote that the clip is frozen, and there ya go.

Siika wrote:I think you could simply extend the freeze function to a single clip, apply the same colour scheme to denote that the clip is frozen, and there ya go.

Combining frozen and unfrozen parts on the same arrangement track would be problematic because of the conflicts between deactivated and activated effect plugins (the state of something being frozen vs. the state of the chain being calculated in realtime). An alternative, additional "quick render on the fly" function would be very cool, just not to be tangled up with the freezing functionality

A quick render function like this would let you select a clip and, for example, holding a key modifier drag that selection somewhere else, rendering that selection on the fly when releasing the drag. Another way to do this (one I've been thinking about before, a design that could have nice additional touches added to it) is having a dedicated "quick render slot/zone/holder" neatly in the GUI somewhere. Basically, you could have functions like "render clip into quick holder", "render time selection into quick holder", and so on, in the relevant context menus. If you'd like to "freeze" a certain clip in the arrangement, to be used somewhere else, you could just right click that clip and render it into that quick render slot. Then you would have a visual cue there, that you have material stashed in the holder , and you could drag it from there where ever you'd like. "Render to clipboard" -- another cool thing to have -- would be somewhat similar, but instead of losing that content when copying something else during a routine edit, the holder content would be more persistent.

Nokatus wrote:Combining frozen and unfrozen parts on the same arrangement track would be problematic because of the conflicts between deactivated and activated effect plugins (the state of something being frozen vs. the state of the chain being calculated in realtime). An alternative, additional "quick render on the fly" function would be very cool, just not to be tangled up with the freezing functionality

Bitwig and Reaper deal with this just fine, so it's more like a challenge than an impossibility

Nokatus wrote:Combining frozen and unfrozen parts on the same arrangement track would be problematic because of the conflicts between deactivated and activated effect plugins (the state of something being frozen vs. the state of the chain being calculated in realtime). An alternative, additional "quick render on the fly" function would be very cool, just not to be tangled up with the freezing functionality

Bitwig and Reaper deal with this just fine, so it's more like a challenge than an impossibility

If by "this" you mean what I wrote in that quote, then hmm, no I don't think they do that . If that really is what you mean, you are perhaps confusing the above with some other functionality.

In below screenshot, I've FM-4 instrument with 5 effects embedded into it (5 rectangles in FX slot on the right-hand side of the FM-4) and 1 effect - Distortion - outside of FM-4:

When I bounced the 2nd clip in place, Bitwig generated audio from the instrument & all nested devices (5 FX), whereas any processing that's outside of it remains intact. So in this particular case, when running the track, FM-4 and 5 nested FX get dynamically replaced by audio sample, so they don't consume CPU cycles and they're turned back on as soon as MIDI shows up.

So yes, it's possible to combine "frozen and unfrozen parts on the same arrangement track" and it's not "problematic". Actually it's quite amazing

...and before you say "it's not freeze, it's bounce/rendering" (which is true) there are at least two ways I can save the original clip for later:

1) I can move it - before bouncing - to clip launcher:

2) I can group the track and bouce-in-place the time selection on the Group Track corresponding with my clip, so when I hit Play the audio on Group Track will take priority and MIDI won't be triggered (although I'd have to move Distortion to the Group Track, if I still want it processed and not rendered to audio):

I hear Reaper is even more flexible, being able to freeze at different points in device chain across the track.

Nokatus wrote:A quick render function like this would let you select a clip and, for example, holding a key modifier drag that selection somewhere else, rendering that selection on the fly when releasing the drag.

BTW, this is also available in Bitwig - I can grab the clip, drag it with a modifier (I think it's Alt, not 100% sure) further down the same track or to a completely different track and the instrument (+nested FX) will bo bounced to audio.

To make it clear - I'm not saying Bitwig is superior in everything because it's not, but there are things I miss a lot when I'm working in Live (I got Push2 recently, so I'm giving it a 2nd chance).

antic604 wrote:So in this particular case, when running the track, FM-4 and 5 nested FX get dynamically replaced by audio sample, so they don't consume CPU cycles and they're turned back on as soon as MIDI shows up.

Thanks for taking the time to demonstrate that, it really is quite cool and I wasn't aware of this functionality . I'm left wondering if it's indeed possible to switch devices on the fly like that in Reaper as well -- that's the one I have quite a bit of experience with, and I haven't bumped into a feature like this.

There are some things that still make it problematic, though, as I was thinking of cases where the effects following the instrument (or the instrument itself) produce a tail/release beyond the MIDI clip boundaries. So if you have multiple subsequent clips of MIDI data, side by side, and you want to freeze just one in the middle, on the fly, the freeze function needs to account for the tail section that doesn't actually overlap the timespan of the actual clip. This can be solved elegantly though, and probably already is.

I agree it's very cool. I'm using the word "problematic" in the sense of "non-trivial." As in, it poses actual problem cases to solve, and can also be challenging depending on the underlying architecture, so that it's not merely a straightforward incremental change to an existing feature (for example, in Live one track cannot host both MIDI and audio data, and starting to solve for a freeze function that activates and deactivates devices on the fly also needs a different underlying track/routing design to begin with). Naturally I'm not implying that it's at all impossible . If something's impossible, as in requests that would need DSP that has data from the future (that does happen), haha, then that's the appropriate word.

antic604 wrote:BTW, this is also available in Bitwig - I can grab the clip, drag it with a modifier (I think it's Alt, not 100% sure) further down the same track or to a completely different track and the instrument (+nested FX) will bo bounced to audio.

antic604 wrote:So in this particular case, when running the track, FM-4 and 5 nested FX get dynamically replaced by audio sample, so they don't consume CPU cycles and they're turned back on as soon as MIDI shows up.

Thanks for taking the time to demonstrate that, it really is quite cool and I wasn't aware of this functionality . I'm left wondering if it's indeed possible to switch devices on the fly like that in Reaper as well -- that's the one I have quite a bit of experience with, and I haven't bumped into a feature like this.

There are some things that still make it problematic, though, as I was thinking of cases where the effects following the instrument (or the instrument itself) produce a tail/release beyond the MIDI clip boundaries. So if you have multiple subsequent clips of MIDI data, side by side, and you want to freeze just one in the middle, on the fly, the freeze function needs to account for the tail section that doesn't actually overlap the timespan of the actual clip. This can be solved elegantly though, and probably already is.

I agree it's very cool. I'm using the word "problematic" in the sense of "non-trivial." As in, it poses actual problem cases to solve, and can also be challenging depending on the underlying architecture, so that it's not merely a straightforward incremental change to an existing feature (for example, in Live one track cannot host both MIDI and audio data, and starting to solve for a freeze function that activates and deactivates devices on the fly also needs a different underlying track/routing design to begin with). Naturally I'm not implying that it's at all impossible . If something's impossible, as in requests that would need DSP that has data from the future (that does happen), haha, then that's the appropriate word.

Cheers!

Regarding the tails, you have (at least) 2 options:
- leave the effect that produces tails outside of the instrument's nested slot - it will process both audio & MIDI the same,
- instead of bouncing a *clip* you can select time (so a clip + eg. 1 bar) and bounce-in-place that which should contain the tail of the effect nested in the instrument,

Bitwig is hugely flexible in that regard, for example you can select time on group, send or master track and bounce-in-place which will give you the sample of sound being generated there. It's much faster than resampling in Live. Obviously this is the result of designing it with hybrid tracks in mind, so a track is just a container for clips, that can be MIDI or audio and setting the priorities, eg. if there's audio it has a priority over any sound coming in.

Nokatus wrote:If something's impossible, as in requests that would need DSP that has data from the future (that does happen), haha, then that's the appropriate word.

Well, actually - Bitwig has an aptly called Time Shift device that can delay your signal or move it forward in time (by delaying everything else). Really clever and useful (eg. to do a look-ahead compressor):https://www.youtube.com/watch?v=MQfSwv_bcSE

antic604 wrote:Well, actually - Bitwig has an aptly called Time Shift device that can delay your signal or move it forward in time (by delaying everything else). Really clever and useful (eg. to do a look-ahead compressor):https://www.youtube.com/watch?v=MQfSwv_bcSE

Hehe, yes I'm of course aware of actual look ahead techniques, but that's (obviously) not a request that requires physically seeing into the future, in the impossible sense

antic604 wrote:Well, actually - Bitwig has an aptly called Time Shift device that can delay your signal or move it forward in time (by delaying everything else). Really clever and useful (eg. to do a look-ahead compressor):https://www.youtube.com/watch?v=MQfSwv_bcSE

Hehe, yes I'm of course aware of actual look ahead techniques, but that's (obviously) not a request that requires physically seeing into the future, in the impossible sense

Yes, but that was just a typical use case.

You can for example send the sound to Reverb, but then use Time Shift to delay the actual sound source so you're reverb will sound before the signal it responds to.

It's just an example of Bitwig's out-of-the-box thinking, because many DAWs will have delay compensation setting per track (to align one track with the rest), but Bitwig takes it a step further, by allowing you to do that within the devices' chain.