Comping MIDI take lanes results in massive CWP file size and slow load/save times in Cakewalk Sonar

[Josh B.]

We used an Alesis Strata Prime as a MIDI controller and recorded five different takes on a Superior Drummer 3 virtual instrument track. MIDI notes, velocity, and CC for the hi-hat pedal were recorded for each take. All the drums/cymbals were mapped correctly to SD3 and sounded fine when we replayed the takes.

Before any segmenting or comping, with all take lanes in their original format, the CWP file size was 2,086 KB.  After I isolated different sections for auditioning and re-saved, the CWP file size ballooned to 102,459 KB.  Opening the file takes around 2 minutes, and saving takes about the same amount of time. 

I went back and bounced all the MIDI takes to remove any sections I created for auditioning, which reduced the file size to roughly 2,000 KB.

Does anybody know what's going on with the filesize after segmenting the MIDI take lanes? Is this even a viable workflow, or should comping take lanes be reserved for RAW audio?

I suspect it may have something to do with the MIDI CC. Years ago, I had issues working with MIDI CC when I recorded some modulation via an AKAI MPK mini. Anytime I tried to manipulate the MIDI CC, Cakewalk by Bandlab would hang and/or crash... not sure if this is similar to what's going on now with what I'm doing in Cakewalk Sonar, but I wanted to mention it.

BTW, I'm on a PC with 32 GB RAM and an AMD Ryzen AI processor with an Audiobox USB96 interface.

[Amberwolf]

If you are using non-destructive midi editing, then every clip you split / cut duplicates the *entire* clip, but exposes only the part of the clip between the cuts. 

So if you make a lot of cuts, you get a lot of copies of the full data of the original clip.

If you bounce all those clips (individually or together) you erase all the hidden data. 

If you never slip-edit stuff back into view, you could temporarily or permanently turn off NDME in your options, but doing this means that every slip-edit you do to a midi clip destroys the information you hide, not just hiding it.   

 

Audio clips are always nondestructive edits, so the same applies there.  

 

If you have a lot of clips with hidden data, you can make a project VERY slow to save.  Frequent autosave can be hell.  

 

 

 

[Josh B.]

I see! Ok, so that makes sense. So, I guess segmenting every single verse beat that repeats in the song wasn't a great idea? Lol. Noted. 

Thanks for the timely reply, @Amberwolf! This definitely helps, and I'll just have to adjust my workflow to only audition the different drum fills instead and then bounce everything to clip when finished. 

[Bass Guitar]

What I remember from back in the days when we were using floppy disks is any continuous controller data would quickly run out of room on the disks.. 

You had to thin out the data manually. I was very disappointed when I bought my GR50 midi guitar that it was next to impossible to record the midi due to the constant pitch bending that was recorded. 
 

But 100MB sounds like a small project to me? That shouldn’t take more than a few seconds to open? 

[msmcleod]

As an alternative to Bounce to Clip(s), you can also use Apply Trimming. 

For a single clip, there's really no difference between the two.  For a selection of multiple clips, there is a difference:

• Bounce to Clip(s):   Removes all of the hidden data, and merges all of the clips into one big clip.
• Apply Trimming: Removes all of the hidden data, but keeps them as separate clips.

This also applies to audio clips as well.

[AB99]

Apply Trimming is a great feature.

I always create a backup before doing it. Sometimes, that trimmed off data is needed later. 

[Josh B.]

2 hours ago, Bass Guitar said:

What I remember from back in the days when we were using floppy disks is any continuous controller data would quickly run out of room on the disks.. 

You had to thin out the data manually. I was very disappointed when I bought my GR50 midi guitar that it was next to impossible to record the midi due to the constant pitch bending that was recorded. 
 

But 100MB sounds like a small project to me? That shouldn’t take more than a few seconds to open? 

That is a good point about the file size. I assume the slowness is due to all the duplicated MIDI tracks from the cuts. Maybe @msmcleod can clarify this? 

Referring to what @Amberwolf said about each entire take being copied every time there was a cut, this means with 5 take lanes and 70 total cuts on each of them (I counted them), then there would be 350 total copies of the takes... right? Is my math correct? 

If so, then does that mean Cakewalk is loading/saving those 350 take lane copies each time the file is loaded or saved?

[Bristol_Jonesey]

4 hours ago, Josh B. said:

If so, then does that mean Cakewalk is loading/saving those 350 take lane copies each time the file is loaded or saved?

Yes