Just tried it twice, each time with a lengthy clip (well, two piano ballads that were major hits) ... but when I drag the clip to the timeline, Sonar gets stuck at 1% progress, uses 1 CPU, keeps reading from disk (according to win10 PM) but never returns nor increases progress ... had to kill it after a few minutes ...
 
anybody else seeing this?
 
EDIT: The issue was resolved by completely uninstalling Melodyne, upgrading to Melodyne 4.1 and reinstalling Melodyne - see post #18

everyone gone to the bakery already ;-)

It would be nice if there was more participation over there but that is not what you really want to discuss in this thread is it?
 
There is not really not enough information in the OP to test. How long are the clips? What sample rate are you using?

Don't know how long your song was, but just for your comparison, I dropped a 3 minute, 4 second 60's pop song onto the time line.  My system (specs in signature) is several years old and runs on a single 500 Gb 7200 rpm drive.  My system was tied up for just a little over 4 minutes with the hard drive constantly running during this time.  SONAR did produce a tempo map at the end.
 
Hope this helps,
-- Ron

I just tried it with a 3:53 song in MP3 format.  Dragged it to an audio track, then dragged that to the timeline, and Sonar completed the tempo map in seconds (something like 10 seconds).
 
The song used was stored in a folder on a 7200RPM HDD.  My system and Sonar folders drive is SSD. All of my Cakewalk content folders are located on the 7200RPM HDD.
 
I am running Sonar x64 2016.12 with no apparent issues here.  Using ASIO driver at 44.1/24.  My system is a few years old modest i3 3.4Ghz 8GB on Windows 10 Pro 1511 x64, but is running rock solid at this time.

scook
It would be nice if there was more participation over there but that is not what you really want to discuss in this thread is it?

 
no. not really ;-)
 

scook
There is not really not enough information in the OP to test. How long are the clips? What sample rate are you using?

sorry. when trying to get some work done, I usually don't feel like debugging problems like this.
 
anyway, here's more info:
 
Sonar 2016.12, projects @96/24, win10 fully patched
 
In order to work with a new singer I was simply trying to get a metronome track for 2 piano ballads, so the most easiest thing to try would be to drag it to the timeline (which hung Sonar), followed by giving audio snap try (which was bound to fail due to missing regularly spaced transients in the piano+voice only recordings), followed by manually determining the tempo (which I did and was surprised that both were tracked to a metronome grid, only one having a short section where they slowed down and a slightly differen last chorus) ... so I got the task done manually in about 10 minutes ...
 
Now debugging this ...
 
I tried on my other DAW (which is all SSDs) and song number #1 (Sarah McLachlan, Angel, 4:30) actually takes 30 seconds to analyze (progress bar), then Sonar sits there busy for another 30 seconds and then it crashes all by itself without interaction ... reproducible 3 times in a row, new empty project ... song number #2 (Adele, Someone Like You) slightly longer, hence longer wait for same crash ... if I try another full song, next crash
 
Now, splitting these songs into random pieces so that it has to analyze e.g. 5 relatively equal sized clips instead of 1 => no crash
 
Splitting 2 small clips off the end (as it starts to analyzing from back to front) successfully analyses the 2 small clips at the end, but crashes at the long one.  So to me this looks a lot like a clip length limitation / overrunning some length buffer at 96 kHz
 
Next bug: if you make the mistake to drag the "track waveform preview" which is the combined display of various comped takes of e.g. 4 takes, the ARA analysis is performed on every (!) take and not just the one that is not muted. you can actually watch it cycle through all takes, bouncing muted takes internally to silence and then trying to ARA analyse it ...
 
However, this does feel like beta testing ... not fun ... grrrr ...
 
 
Let's hope someone cares to reproduce this, so that a moderator can move this to the problem reports forum
 
 

confirm this as a 96kHz issue: I just tried the same songs using 44.1/24 and it works fine (!!)

I assume you're not running under a Windows compatibility mode, but if you are...don't. 
 
 

Anderton
I assume you're not running under a Windows compatibility mode, but if you are...don't. 
 
 

no. no dirty tricks involved ;-)

I just tried it at 96 kHz with: 

• A relatively short 44.1 kHz mono file, sample rate converted by dragging it into the project
• Long (5 min) 44.1 kHz stereo file, sample rate converted by dragging it into the project
• Medium length (2 min) mono file, recorded native at 96 kHz
• Medium length (2 min) stereo file, recorded native at 96 kHz 

Everything worked as expected. Because I can't get it to misbehave, I can't tell you how to avoid having it misbehave.
 
The only suggestions I have are:

• Try changing Melodyne to the Percussion algorithm. 
• I noticed as it was doing its thing that the first screen shows "mixing down audio." Maybe try using half of the stereo pair?

As to this...
 
Next bug: if you make the mistake to drag the "track waveform preview" which is the combined display of various comped takes of e.g. 4 takes, the ARA analysis is performed on every (!) take and not just the one that is not muted. you can actually watch it cycle through all takes, bouncing muted takes internally to silence and then trying to ARA analyse it ...
 
This probably isn't a bug. Remember that although Melodyne is integrated with SONAR via ARA, it is not part of SONAR. When you drag the parent track, you're dragging all the Take Lanes. Melodyne probably doesn't know which ones are muted and which ones aren't. This would need to be a feature request, but for now the solution is don't make the mistake of dragging a parent track with muted comp tracks into the timeline.