[SOLVED] drag LONG clips to timeline to extract tempo map not working in 2016.12 @ 96 kHz

everyone gone to the bakery already ;-)

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

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
 
 

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

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. 

Rob[atSound-Rehab]
I stayed at Melodyne 2.1.2 and so far have not bothered to upgrade as version 2 does the job.

I wish you had included that information earlier, I think that's your answer. I tested using 4 Essential although it also works with 4 Studio. 

Rob[atSound-Rehab]
I stayed at Melodyne 2.1.2 and so far have not bothered to upgrade as version 2 does the job.

My test was run with Melodyne 4.1.0.001.   Celemony significantly improved the tempo detection capabilities in version 4 and I believe the latest SONAR ARA improvements were targeted at version 4.
 
-- Ron

Thanks. Now this is a reason to justify the upgrade. So far I was under the impression that the ARA stuff implemented in Sonar is independent of whether there is Melodyne / which Melodyne version there is ...

OK, thanks for all this help in the thread.
 
The issue was resolved by completely uninstalling Melodyne, upgrading to Melodyne 4.1 and reinstalling Melodyne.
 
Apparently there must have been some sort of confusion between a Melodyne 4.1 runtime version and the previously installed Melodyne version, which was still at 2.1.2. Now everything is at 4.1 and all symptoms described are gone. Tempo detection also works much better.