Yes I know I have been blathering about comping the past couple days but it's what I'm doing right now. As I am building up my track clip by clip the time it takes for X3 to save (I save every few moves after I've accomplished something I like) is getting longer and longer.
 
Before starting comp: Save times = lightening fast as usual
 
Segmented first take into sections for auditioning = 1-2 second save time
 
Each section I promote = an extra second or so to save time
 
Is this weird? These are MIDI clips if it matters (which I figure would be easier for Sonar to deal with than audio).
 
I did also encounter a dropout as I was using the arrow keys to audition stuff but I had forgotten to turn up my buffers before starting. That seems to be okay now.
 
i7 2600k
7200rpm SATA drives
16GB DDR3 (Corsair Vengeance)
Win7Pro64
Focusrite Scarlett 18i6
X3c* 64bit
 
*if this is a known issue corrected by D then it will bump my patching priority but C so far is working fine so I haven't bothered yet for the sake of just keeping my project moving forward.
 
Cheers.

Try disabling Non-destructive MIDI Editing in preferences unless you really need it for some reason. With it enabled, every time you split a clip, you're doubling the number of MIDI events in the original clip. And if you every split is being replicated in multiple takes, the total number of MIDI events could go up pretty fast. I usually have it disabled because I just don't like some of the side effects. Disabling it might make comping work differently in some ways so you'll need to experiment.
 
In general, I don't think the comping logic works well for MIDI, but it depends on the material, and how surgical you're trying to get. In most cases I would still just pick the best performance and edit it as needed, maybe manually "comping" in a section or two from other takes that I like better if it's an improvised part.
 
 
 
 
 

Hello, brundle and thanks (sorry for the late reply... was logged out and had to do laundry this morning). I did not know that and it makes sense. I will indeed play around with it but if that does what I think it does it might make it so I can move my split points without losing sections (it would create gaps instead of just revealing hidden data). If I could "uncrop" without creating those gaps then that would be cool.
 
I find it a little odd though that it doesn't work like how I assuming audio clips deal with this which would be having the file stored and just accessing that same file. If I'm understanding correctly with every split of a MIDI clip I get two full MIDI clips stored somewhere on my HDD. In that case (and in current project) I would indeed be create a TON of clips in a very short period because the track I'm working on has about 16 or so different takes. I chopped up the first take into logical sections of beat cycles/riff patterns and then went further to isolate parts where there are fills or flourishes to try out the different takes. As soon as you do that to the first take it creates the splits across ALL the take in the track so now I've got around 16 or more clips multiplied by 16 or more takes. YIKES!!!
 
Taking that into consideration I guess my system is doing quite well because even at this point my saves are still under ten seconds. I'd kind of figure though that after the first round of splits and saving that it wouldn't be so taxing to save following versions but that's beyond my knowledge of how all that works. I guess it goes through the whole thing every time.
 
It also explains why I experienced a dropout shortly after creating the splits (as I said I had my buffers way down for recording... it's working now). I'll definitely have to make sure to flatten the comp, clone the final and archive the comp track. Hopefully that will free up some resources or I guess I'll just delete the originals.
 
I am actually finding comping my MIDI drums this way VERY useful though for multiple reasons. I am mainly a guitar player so once I have something worked out as far as bass/guit parts it's no problem for me to just record those tracks in on take (solos are a little different because sometimes I'll build those up in phrases but there is very little "comping" in this sense involved).
 
However for my drums I am performing them live on my padKontrol. Now I did play drums for a few years in a band quite regularly and got pretty good but I am by no means a pro drummer and I'm woefully out of practice. Add to that the fact  playing on a MIDI pad device with an on/off style expression pedal for my kick is VERY different than playing an acoustic kit and the quirks/limitations of the padKontrol itself (occasionally drops/doubles notes, no double kick unless I'm finger drumming which does not allow for normal drumming style, no smooth control over hats/ride artics, etc). So I can get some great sounding sections then flub or have a technical failure for a section and then pick it up again. I find it easier to just slam through the entire song to keep the grooves going which is WAY faster and easier than trying to hunt down anything resembling my wacky beat stylings or programming them in by hand which then requires endless humanizing then cobbling together the best beats and fills. The comping was way more tedious before so the new method is a godsend for this process.
 
Once it's all done then I'll be able to flatten it and fix any remaining off beats and toss in any double kick work in the PRV. For my double kick stuff (gallops, marches, runs, blasts) I might even try deleting the existing kick notes for the section, switching to Sound On Sound then finger drumming in the kick parts and bouncing.
 
Basically I'm kind of figuring out a good workflow for my drums and I gotta say the new comping stuff is working out awesome as an intermediary between all my not so great live performances and getting down to the refining stage.
 
Now that I am aware of this "doubling the data each split" phenomena though it is something I will definitely bear in mind as I work. Thanks again. Cheers!

MIDI data is stored in the cwp file.

scook
MIDI data is stored in the cwp file.

Thanks. That is helpful and I guess I should have come to that conclusion. I feel the back of my brain starting to cobble together the purpose behind keeping each file fully intact with every split but I haven't quite reached that "D'oh!" moment yet (and I seem to remember coming across an explanation before and perhaps the answer lies in brundle's post but it isn't clicking).
 
I'm sure it will come to me but perhaps you could nudge my grey matter into the right direction... if you have the time or inclination that is. You have always been quite good at that. ;-)
 
Hope you've been well.

I would image it would be for the same reason most prefer to perform nondestructive audio edits. Nondestructive edits can be undone even after the session history is gone.

scook
I would image it would be for the same reason most prefer to perform nondestructive audio edits. Nondestructive edits can be undone even after the session history is gone.

Right, but I figure it would reference the original file (like non destructive audio... if I understand that concept correctly) as opposed to creating multiple copies of it. Perhaps it is just one of those things that harken back to the old days and just hasn't been recoded to be more efficient... which would mean I'm over thinking things... as usual.
 
Still I'm glad I started this thread because I definitely learned some things I would not have otherwise.
 
Thanks, guys.

Okay... I think I'm figuring it out. It is in case someone does note edits to a specific clip beyond the boundaries of the currently active section so it keeps them isolated whereas with audio you aren't able to do those kinds of edits and print them without creating a new wav file.
 
I guess maybe how I would prefer there was a mode that used the original clip and any edits I wanted to create a saved file for would require a bounce like I would with audio. Perhaps that is what destructive MIDI editing means but that I'd still be able to stretch out the clip with the original data. I'll have to experiment with that.
 
hmmm...
 
 
 

As far as I can tell, Non-destructive MIDI editing has only one real use, which is that you can "delete" a portion of a clip, and be able to restore it later by slip-editing one of the remaining sections back over the hole. But you can achieve the same thing without having Non-destructive editing enabled by spitting and slip-editing to create the hole in the first place. This is essentially the mode you're asking for; slip-editing preserves the hidden data until you bounce to clips, and there's no duplication of the original data.
 
 
 
 

brundlefly
As far as I can tell, Non-destructive MIDI editing has only one real use, which is that you can "delete" a portion of a clip, and be able to restore it later by slip-editing one of the remaining sections back over the hole. But you can achieve the same thing without having Non-destructive editing enabled by spitting and slip-editing to create the hole in the first place. This is essentially the mode you're asking for; slip-editing preserves the hidden data until you bounce to clips, and there's no duplication of the original data.

That's awesome. Thank you kind, sir for the timely and extremely useful info. Although yesterday I did actually delete some things as I comped, thus creating holes, I generally don't do that with MIDI and there is certainly no real need for me to do so. I was just doing it to visually remove crappy parts from my potential comp pool but after a while I stopped because it wasn't as beneficial to my developing workflow as I thought it would be.
 
Now that I understand Sonar (in general) better and all the available options I'm pretty much just trying to map out the most efficient ways to do what I need to do with my current project... so still some trial and error. My last effort was desperately fumbling my way around just to find where things were and how to accomplish simple tasks which was much more tedious and annoying. Guess I still have a long way to go but at least the work is getting done.
 
Seriously this info is golden and will obviously help my project files from getting unnecessarily huge. Thank you again... and to scook as well.