Hello everybody,

First off, I've been a dedicated Cakewalk user since year 2000 when I started with Pro Audio 9.  I'm not going anywhere.  With that said, this issue desperately needs to be addressed by the Cakewalk guys because I've had to split my production process between REAPER 5 and Cakewalk Sonar.  I'd sincerely wish to keep my entire process within Sonar.  Anyway, I will explain the situation here.

I'm going to give an example with the latest session, which is just a simple rock/metal track.  No blast beats and just three sections with some double bass notes.  I don't experience any real problems using the AudioSnap pane or marking transients.  In fact, I really like this and I find it quite versatile.  

The first thing I do is export a kick/snare mono track so I can have a reference track for transient markers.  I'll go through, make adjustments, and then either add the clip to the pool or lock the track and markers to all tracks and then unlock.  This is where the real problems begin.

Once I click on "Split Clips,"  Sonar literally implodes.  Depending on the length of the song and how intracite the drum parts are, this takes 3-5 minutes just to split clips.  Absolutely unacceptable as REAPER 5 is nearly instanteous for me.  (I'm us an FX-8350 with 8GB of RAM.)

If Sonar hasn't already "Stopped Responding," the program moves at a snail's pace.  Selections are nearly impossible.  Scrolling the session is nearly impossible.  Not to mention, saving a session takes upwards to 10 full minutes.  In the case of my latest session, I was able to edit transients, split the clips, and while trying to quantize, the program locked up and crashed.  This is repeatable without fail and I'd be willing to record my desktop trying to do this.

Going on in this fashion can take hours and is simply not viable for editing multi-track drums.  This is a huge stopper for potential clients who are not using loops or creating rap beats, but are full-on metal producers that need these tools.

As it stands right now, I'm forced to do all drum editing in REAPER 5, where I think import the fixed stems to the Sonar session.  I paid for Sonar Platinum and I'd really prefer to keep my entire workflow within Sonar Platinum.

I don't think it's AudioSnap that is causing the issue, but there definitely is something wrong that doesn't allow me to take full advantage of AudioSnap.

I love Sonar, so I'd be absolutely grateful if the Cakewalk folks could at least acknowledge this problem and let us know they are working on it.  I'm not cancelling my rolling updates or anything like that, I'm committed, but this seriously needs to be addressed.

Thanks a LOT for all the AMAZING updates you guys made last year with the Style Dials and optimizations.  It's sincerely appreciated on my part. 
 
Cheers!

At last someone else suffers the same nightmare like me. Not to mention that when using auto detect transient in audiosnap it almost always detects the transient late, splitting it in two so when you quantize you have to go and manually fix every kick or snare hit.....
I´ve switched to PT for editing in general, it´s unbelievable retarted in Sonar PE

so let's clarify.  You're saying that after your timeline now has the drum tracks all split into clips for every "event", Sonar becomes less responsive?  Is this only once the action has been completed?  Is it the same experience upon closing and then opening the session fresh?  What is your CWP filesize difference (before and after clip separation)?

Something tells me you may want to check your drives with HDTune or similar app, and look into the SMART status to see if there are any Reallocated Sectors Pending... This means sectors that are still marked as active and available for use by the OS are failing but the data has not been reallocated to new, undamaged sectors - likely resulting in stability problems.

I would suggest also opening a support ticket and submitting your problem step by step if you can recreate it every time.  It would also help to know if this happens on just that particular project of if it's across "every" (multiple) projects with different material and different settings.

Soulburned
so let's clarify.  You're saying that after your timeline now has the drum tracks all split into clips for every "event", Sonar becomes less responsive?  Is this only once the action has been completed?  Is it the same experience upon closing and then opening the session fresh?  What is your CWP filesize difference (before and after clip separation)?

I'm using AS in a 'Beat Detective' way where I split the clips at the start of the Transient marker.  (Where I would then try to quantize.)  However, the moment these clips are split (hundreds to thousands, depending on the note density of the drums), the session literally just stops being responsive.  I could liken it to a person trying to play a computer game with a GPU that is severely underpowered to play the game.  CWP filesize becomes very large after the clips are split.

Soulburned
Something tells me you may want to check your drives with HDTune or similar app, and look into the SMART status to see if there are any Reallocated Sectors Pending... This means sectors that are still marked as active and available for use by the OS are failing but the data has not been reallocated to new, undamaged sectors - likely resulting in stability problems.

My drives are perfectly fine.  This behavior is only exhibited within Sonar.  As I mentioned, I can edit drums much bigger in size with more notes-per-measure nearly instantly using Reaper 5.  Pretty much every aspect of multi-drum editing in Reaper 5 is nearly instant - from clip splitting, bouncing, saving, etc.  I'm honestly quite shocked how badly Sonar runs when trying to do similiar actions.
 

Soulburned
I would suggest also opening a support ticket and submitting your problem step by step if you can recreate it every time.  It would also help to know if this happens on just that particular project of if it's across "every" (multiple) projects with different material and different settings.

It's for everything.  I've even noticed these drastic slow-downs in the PRV with a lot of MIDI information.  I'm beginning to suspect it's a coding issue.  I could make a video demonstrating this.

sounds like this: http://forum.cakewalk.com/FindPost/3361422

I can only subscribe every word Scott just said.
I7 with SSD and 16gb RAM on my side

When I read about audiosnap and large cwp, I recall this thread http://forum.cakewalk.com/FindPost/2901079

scook
When I read about audiosnap and large cwp, I recall this thread http://forum.cakewalk.com/FindPost/2901079

that also looks like a history thing; saving flushes the history, hence the ctrl/s helping, but if the last history step was corrupted, also explains not being able to re-open some projects
 
my speculation is: there's (a) bug(s) in the both the saving and recalling of history/do entries; i think it's caused by "disconnection" between "skylight" and the underlying older codebase; i'd bet a shiny euro ;-)
 
hth

I do a LOT of Audiosnap work with metal music, in fact I'm mid project now doing exactly that.
 
My workflow is this:
 

1. Record the takes (duh)
2. Select each track, enable Audiosnap and set the threshold level to 100% to disable the transients
3. If this is a simple drum track with no kicks playing in time with the snare (so you're getting possible flamming), I bounce kick and snare to a new track ** (see note below)
4. On that track, enable Audiosnap, drag the threshold slider down until it detects most or all of the hits, adjust accordingly by moving transients around or inserting / deleting as necessary.
5. On that track, right click it and choose Pool > Add Clip to Pool
6. Select every other track, right click on one and choose Pool > Appy transient pool markers
7. Manually tighten or quantize your guide track as you see fit.
8. Select every other track, right click and choose Pool > Quantize to Pool

 
No splits, no crossfades needed, no weird gaps, no endless clips. All of the phase is correct and it just works.
 
** Audiosnap has a BIG problem with ghost notes and weird detections. What I tend to do is put a gate on the kick and snare track and get them extremely clean sounding (to the point of them sounding bad, but so there's a definite attack to each hit, and no noise between the hits) and the bounce THAT to a new track. You can delete the gates after that. You new guide track will have super clear hits and Audiosnap will be a million times better at detecting the transients.
 
This get a bit more complex with double kick work where things fall on the same beat, or places where you want to set your timing guide from something else (ie: you have a killer ride pattern which is a bit off but that's where everything follows.) You need to decide what is most important, quantize minus any overlapping hits, then go back a few more times and lock in those remaining transients with the rest of the group. Not ideal but I've had great results from doing that.

Lord Tim
** Audiosnap has a BIG problem with ghost notes and weird detections. What I tend to do is put a gate on the kick and snare track and get them extremely clean sounding (to the point of them sounding bad, but so there's a definite attack to each hit, and no noise between the hits) and the bounce THAT to a new track. You can delete the gates after that. You new guide track will have super clear hits and Audiosnap will be a million times better at detecting the transients.

Actually I tried gating an already clean kick track bouncing it to a new track. The detection becomes a bit better, but is still unusable for me. Too many signals are cutoff in the middle. After copying the pool transients to the other tracks the program became very slow, and saving the project took about 5-10 seconds.
Like the others here in the thread I still have to switch to another program to do this kind editing. Fortunetaly I have both a Platinum and a Pro Tools License.
 
Here is a screenshot of the two tracks, the original one and the bounced one. You can clearly see it's not a ghost note or poor attack problem. It's simply buggy detection.