I know, I know. Previously requested. But never delivered and highly desired!

Let me generate my song and then freeze everything.

Then let me choose any track and any set of bars and regenerate just that set of bars on that track.

Also let me choose any track and any set of bars and freeze just that set of bars on that track while regenerating the rest.

For me, this would complete BIAB and be the last major feature I'd ever need!

So here is how this might be implemented...

As I created my mockups it seemed to make more sense to drop the Freeze moniker and instead have one option called "Regenerate Selected" and one called "Regenerate Unselected".

In the first mockup it goes like this,

1) bars 24-29 have been selected
2) REGENERATE option is chosen
3) Guitar and Soloist tracks are selected

When the REGENERATE button is clicked only bars 24-29 on Guitar and Soloist tracks will be regenerated. ALL other tracks and bars are completely unaffected.


In the second mockup it is opposite day and goes like this!

1) bars 24-29 have been selected
2) REGENERATE option is chosen
3) Bass, Piano and Drums tracks are selected

When the REGENERATE button is clicked EVERYTHING EXCEPT bars 24-29 on Bass, Piano and Drums tracks will be regenerated.

Oh yes, definitely another vote for this.

+1

yep +1

This would be terrific.

I have a question: if a track is frozen, it becomes a form of audio file. You see this because of the huge increase in file size. If you then regenerate only a part of that track, won’t you have possible clicks, odd voice leading, and/or register jumps?

Not sure about that but however they do the behind-the-scenes magic with regenerating sections in Realband might work here.

Matt, I don't think if a track is frozen that any audio is created. I did a Chord Sheet of 8 bars using a RealStyle with 5 instruments - Bass, strumming ac guitar, drums, FP ac guitar and another FP ac guitar.

I saved the file with no tracks frozen and the sgu file was 3.3 kb
I saved the file with one track frozen and sgu file was 11.2 kb
I saved the file with all tracks frozen and the sgu file was 42.3 kb

While there is a significant increase in size of each subsequent sgu file, it appears to me this is due to additional data content and not audio.

It's my opinion there's no audio created in a BIAB project until a track is either saved or rendered and that no physical audio of a track exists until a render is saved in an audio format. Until then, I think it's only data instructions detailing where and what RealTrack audio file to use. That's my speculation.

I'm guessing that the program intelligently decides the exact length of the phrase and exactly where it can be positioned into the song so as to avoid such potential issues, i.e. user might ask for 5 bars but the program might need to deliver 6 bars to get the replacement to insert and transition smoothly.

I agree with Charlie in that I also think the added size for frozen tracks is the list of meta-data that identify how the song is assembled, which real-tracks phrases to use.

Above are only an assumptions. I have no real knowledge of the process.

This is how I think it would work, generating in RAM:
I will use the example below using a physical wav file, you have your generated track, that is the top track in the Plugin,
the track is Frozen but you highlight the bars you want re-generated,
that section is cut out of the RAM,
a new section of bars will be generated (on second track in Plugin) and merged into that section.

This played seamlessly when I tried it.
In the Plugin you can select bars and it will just generate that section up.

Full Screen

Yes, the RealTrack info of frozen tracks are saved in the SGU.
It will represent the time start/end in the source wav/wma, stretch and the transpose amount.
That's why you can change a frozen RealTrack to the same Direct Input track by changing the source wav/wma to the DI ones (temporarily then save track to wav).
If you knew what you were doing you could copy a section if a HEX editor of the bars of a saved frozen SGU and paste it into another,
then when you opened that frozen SGU it would have a new section of track.
It's the same if I drop a wav into Reaper, slice it up, change the pitch and rearrange it,
when I play it back it will still be playing the same original untouched source wav file.
The Reaper project file is still small, same like the SGU but just stores the wav start/end/pitch/stretch change info.

Thanks, that seems to answer about the file content. And I do know that RealBand has this feature, although I do not have experience using it. If PG Music could adapt that from RealBand into BIAB, that would seem to be a large step forward. We have had many discussions about this in which users recommend using different tools for different purposes, and I'm usually in that camp since I use a bunch of audio programs in the course of one project. In this one case though, if I could stay within BIAB longer, I would really appreciate it as a composer.

What I just posted got me thinking about how it generates to RAM and how a lot of time is taken to generate to RAM then render to wav for the BB Plugin.
Why can't the BB Plugin do what Reaper does, play direct from the RT/RD wav/wma source files ?
It would only need the reference info generated.
This is what is done in Reaper to create a track instantly, sure it's only simple random matching, Biab would do more musical calculations but it should be near as quick like generating midi only is.
Then in the BB Plugin you would get instant tracks, and with Vol/Pan and audio sends it can be all done in the BB Plugin without using any physical hard drive space in SavedTracks folder with tracks that you don't like.
The render time would be then when dragging a track you are happy with rather than all the time it takes to render tracks that were not right.

Does that sound feasible or have I missed something ?????

Now this is the render time, it will render all those sections to a new wav: