CAKEWALK SONAR 6 PE (Windows DAW) - NOW WITH CONCLUSIONS!

[Anderton]

The Pro Review of Sonar 5 was very popular, with a high degree of participation from Cakewalk, a lot of visitors from the Cakewalk forums, and we even managed to track down some bugs that were fixed in a rev while the review was still happening...so perhaps not surprisingly, we're back for Round #2 with Sonar 6 Producer Edition.

It's difficult to know where to start; there are a ton of changes, some of them subtle, some of them obvious, and some of them very complex. But I've decided to start with the AudioSnap and ACT (Active Controller Technology) features for two reasons: They're two of the biggest features in this upgrade, and also, there is a great deal of confusion surrounding them. Some people can't get ACT to work at all, some don't "get" AudioSnap -- or can use some of its functions, but haven't had success with others. So this won't just be a "it works, it doesn't work" type of review, but we'll take advantage of the Pro Review format to get deep into how these features work, covering both their strengths and their limitations.

The downside is that this means a more leisurely look at the program; it may be a while before we get to, for example, the very cool VC-64 audio processor. If you want a quick, more traditional review format that goes over the highlights of a large number of features, check out my review in the December 2006 issue of EQ magazine. It should be hitting the newsstands any day now, and it's a fairly compact look at the new features and what they mean.

And of course, there's a bunch of information at the Cakewalk web site if you want information on system requirements, pricing, upgrade policies, differences between Sonar 6 Producer Edition and the less capable/less expensive Sonar 6 Studio Edition.

Meanwhile, let's get this show on the road! As always, questions, comments, criticisms, and pearls of wisdom are not only welcome, but encouraged.

[Anderton]

AudioSnap is basically Cakewalk's answer to Pro Tools' "Beat Detective" and Ableton Live's "elastic audio" feature, but goes deeper than either one -- sacrificing user-friendliness in the process, but conferring additional power.

I believe one reason people have a problem wrapping their heads around AudioSnap is that it's an umbrella term for a variety of different features and functions; there's no one "magic bullet" AudioSnap function. Not only that, but even within a specific AudioSnap function, there may be different ways to accomplish a particular task for different types of material.

There are two main elements to AudioSnap. One element involves DSP-based time stretching, which can be used in a very elementary manner (e.g., stretch a clip to fit a particular length or tempo) or a very complex one, like having an entire tune following tempo changes added after the track was recorded. The stretch algorithms that form the basis of AudioSnap form the basis of all stretching operations, aside from the creation of "groove clips" (done in the Loop Construction window) and the playback of REX files (done with the RXP player).

The other element involves transient detection. This is what allows doing operations like pinning a tempo map to a clip, or pinning a clip to a tempo map. With transient detection, you can do things like build up a tempo map of beats, then tell the program "This transient should represent the start of the first measure, this transient should represent the start of the second measure," and so on. Then you can make the tempo conform to your definitions.

So far so good? Next...

[Anderton]

Clips that you want to subject to AudioSnap operations need to be enabled as AudioSnap clips. This is the same principle as how a vocal clip gets turned into a V-Vocal clip when you want to do pitch correction with V-Vocal, or how a standard clip gets converted into a "groove clip" when you want to do Acid-style time stretching. When you AudioSnap-enable a track, the AudioSnap Palette appears (click on the attachment to see it). This presents the tools available for various AudioSnap operations.

However, it's important to note that the AudioSnap palette also affects clips that aren't AudioSnap-enabled when doing simple stretch operations. Let's investigate this with a specific example.

[Anderton]

For simple stretching operations, Sonar has implemented Cubase-style audio stretching where you can grab the edge of a clip, and if you're holding down the Ctrl key, slip-edit to a particular length.

Click on the attachment to see an example of a drum track being stretched. Both tracks have the same clip, a Discrete Drums drum loop. However, the one in Track 1 has been slip-edited so it lasts exactly eight measures, whereas the one in Track 2 remains unmodified.

Look closely at the clip in Track 1, and you'll note a yellow "banner" across the bottom. This indicates that the clip has been stretched, with the percentage indicating the amount of stretching (in this case, 133%). Percentages above 100 mean the clip has been lengthened, and below 100 means the clip has been shortened.

This is a simple, effective way to get audio to fit specific tempos without having to deal with REX files or creating markers in groove clips. But the sound quality the clip delivers on playback varies tremendously, depending on whether you've chosen an "online" algorithm for real-time playback, or "rendered" for higher quality. I think that not understanding this crucial difference accounts for why some people say the stretching in Sonar 6 sounds fantastic, while others say it sounds terrible. Let's delve into these different stretching options, because it's of fundamental importance when dealing with any AudioSnap operation.

[Anderton]

There are two types of algorithms applied to stretched clips: Those for online, real-time playback, and those for offline rendering. There are two algorithms for online playback, Groove-Clip and Percussion, and four additional algorithms for offline rendering (you can also render using the online algorithms). These are the Radius algorithms from iZotope, which have been licensed to other DAW makers as well. They are excellent, but some of them take quite some time to render, which is why they aren't suitable for real-time playback.

You access the default algorithms by clicking on the AudioSnap Options button to the right of the AudioSnap palette. This causes a dialog box to appear; click on the attachment to see this. Toward the bottom of this box, you'll see the option to specify both Online and Offline algorithms; the screen shot shows the Offline Rendering algorithms drop-down menu.

For the Online algorithms, the Percussion algorithm is (as expected) optimized for percussive material, while the Groove-Clip algorithm seems more effective for sustained material. However, as far as I can tell, the online algorithm applies to all clips that have been stretched. In other words, if you've stretched a drum part and a string part, they'll be subjected to the same algorithm.

But that's why rendering is so helpful, as once a clip is stretched as desired, you can make the stretching permanent by exporting or (more simply) invoking the Edit > Bounce to Clip option. In this case, the stretching will be calculated using the algorithm you specify in the Offline Rendering field.

Hey, how about some audio examples...

[Anderton]

I took the clip that was stretched 133%, and rendered it with several different algorithms. Note that 133% is a significant amount of stretching that really brings out the worst in a stretch algorithm, so using this amount of stretching helps emphasize the differences among the various algorithms by giving what's almost a "caricature" of each algorithm.

Click to download the first example. This uses the Percussion algorithm, which gives reasonably good sound quality -- but the timing is a little bit off on the grace notes, so the rhythm sounds a little sloppy.

CAUTION: When you download these examples, the attachment may have a .PHP extension and not be recognized by an MP3 playback program, such as iTunes or Windows Media Player. Simply change the file's extension to .MP3 and it should play without problems.

[Anderton]

Click to download the second example. This uses the Groove Clip algorithm. Note the flamming and artifacts; these would be far less obvious on something like a string pad, but don't work well for percussive sounds.

[Anderton]

Click to download the third example. This uses the iZotope Solo Bass algorithm, and is a perfect example of choosing the absolutely wrong tool for the wrong job. It flams, stutters, and generally messes up the sound pretty badly.

[Anderton]

Click to download the fourth example. This uses the iZotope Mixed algorithm. This has the tightest, most accurate timing of all the algorithms. It does add a bit of a "phasey" sound (which unfortunately is accented by the conversion to MP3), but at reasonable amounts of stretching, this becomes less and less noticeable.

Bottom line: How you feel about the sound quality of Sonar's stretching depends greatly on using the right algorithm, and recognizing that you're probably not going to get optimum sound quality until you render with the right algorithm for the job.

[Anderton]

A couple comments so far:

Prior to AudioSnap, Sonar supported DSP-based stretching, "Acid-style" slice-based looping, and REX files via a REX file player -- not exactly a miserly selection of stretch options. What's really new in Sonar 6 is the inclusion of the iZotope algorithms, which (as you've heard) can sound very good if you match the right algorithm to the right program material.

The other new element is transient-based pinning to tempo, or pinning tempo to transients, which will be our next focus.

Finally, how do you feel about deviating from the more conventional way or reviewing and doing more of a "review by application?" What I hope is that by analyzing what the program can do, you can decide for yourself whether it's right for you or not. But also, this will hopefully help any people who have the program and feel they need a better understanding of some of the new features.

As always...let us know what you think!

[Keith-Cakewalk]

Hi Craig,

Just wanted to say thanks for the excellent points you made. Looking forward to future posts.

I actually posted earlier but unfortunately the submit timed out so here's a 2nd write.

The choice of renderer both online and offline is critical to getting the results one wants. The key is to try them and give a listen.

In case anyone doesn't know, that choice can be specified globally as well as per clip. Globally, it's in the AudioSnap Pallette Options. Per clip, it's in the clip properties Audio Stretching tab.
By default, clips will use the global options unless you change that clip.

Here's some clarification on when you might use a particular stretch mode. Offline Radius Solo is good for monophonic material. One might think that for a guitar being 1 guitar that solo would apply. It might if you're playing single melodic lines. Throw some rhythm chords at it, and there may be some artifacts. There are three solo modes. Bass, one that's unamed (just called Radius Solo) and Vocal. They roughly equate to being more optimal for low, medium and high frequency bands.

Radius Mix would be more suited for polyphonic material or mixed material. So for the guitar, it might be optimal to split the clip into sections where there's lead lines to process with either the Radius Solo or even Radius Solo (Vocal) and others where Radius Mix applies.

The online methods are faster but may have artifacts depending on content and how far stretched. The Groove-Clip is the Acid style of stretching we've had in Groove Clips for some time. We introduced a new one in Percussion. That one is akin to Recycle. If you compress(shrink) audio with drums for instance, each note still sounds the same duration so polyphony actually increases, just as it would if a real drummer played faster. So for drums, definitely try the Percussion mode first.

For the Beat Detective folks, you can split clips at the transients and move the slices around, etc. I'm sure that will get covered soon, so I'll conclude for now.

Thanks again and have been a long time fan of your work.

Keith [Cakewalk]

[Anderton]

<<In case anyone doesn't know, that choice can be specified globally as well as per clip. >>

Well this is why I like pro reviews, I learn a lot! I knew about specifying clips globally, but didn't realize that the per-clip stretching option overrode the global setting. Thanks for that! Please continue to keep an eye on this thread to make sure I don't spread any misinformation, and thanks for the additional tips. That kind of material is very helpful to all.

[DeeringAmps]

In answer to your question about "review by application" IT'S GREAT!

Tom

[johndefiore]

The "review by application" is a great format.

As far as audiosnap is concerned, has anyone had good results with acoustic guitar strumming? No matter which offline rendering algorithm I try I can't get an acceptable result with a strumming style where the chords and some open strings ring between strum transients. Granted, I haven't spent huge amounts of time with it yet, but I've had good results on vocals, bass, percussion and staccato (e.g. reggae) guitar.

John

[Anderton]

<<o matter which offline rendering algorithm I try I can't get an acceptable result with a strumming style where the chords and some open strings ring between strum transients. >>

That doesn't really surprise me. I've been working on a new sample CD, and recorded a guitar riff that had staccato parts alternating with held chords. It went through a synched delay, so the notes really had to hit EXACTLY on the beat or the clip would end up being impossible to "acidize." Seemed like a perfect job for AudioSnap.

Only problem was if I chose an algorithm that worked for the staccato parts (Percussion), then the held chords sounded awful. Similarly, if I used the iZotope Mixed algorithm, which gave good results with the held parts, the staccato parts didn't sound right.

A workaround was copying the part, lining up the staccato parts on one track and bouncing to clip using the Percussion algorithm, then lining up the sustained parts on the other track and bouncing to clip using the Radius Mix algorithm. I then cut away the nasty sound sustained parts on the staccato track, and then nasty staccato parts on the sustained track. It took some effort, but worked.

With something as complex as strumming, though, I think it will be hard to get decent results. Let's see what happens as the review progresses...

[Anderton]

Before going any further, it's worth noting that most of what AudioSnap does is transient-based. In other words, the process analyzes a clip for transients, and draws transients where it finds them. This is important because if, for example, a kick drum hits on every quarter note and AudioSnap finds those transients, you can immediately let Sonar know those transients indicate beats, which makes calculations such as changing tempo much easier.

However, as anyone knows who’s used Cubase’s “Hit Points” feature, tried to slice a REX file in ReCycle, or edit the Acidization markers in Acid or Sonar, transient detection is by no means a perfect science. Sonar has Threshold and Sensitivity controls to let you cut out some of the “chatter” and restrict the selection of transients to rhythmically useful values, but the effectiveness varies with the material. With a straightforward drum part, it’s easy to identify and mark transients, but with sustained material, or material that was not cut to a click track, the process of isolating rhythmically important values is far more difficult.

Click on the attachment to see AudioSnap enabled for a drum loop from Discrete Drums. Note how there's a transient (the light gray line) drawn for every single drum transient; this is a case where transient detection works just about perfectly.

However, not all clips are as cooperative. As a result, manual labor is involved with a lot of material. One thing that helps is adjusting the Threshold parameter with a mouse scroll wheel; it just seems easier than dragging the slider. But ultimately, with "problem" material, you have to tell Sonar which transients matter and which ones don't. For example, if the transient detection process is pretty good except for some extraneous transients that don't correspond to beats, you can disable those transients (they're never really deleted, just disabled so they don't have an effect).

Another approach is if you're, for example, trying to quantize a clip to tempo. If you put transients at the beginning of each beat, it's easy to do this kind of quantization (we'll describe how to do that later on). However, it's unlikely you'll have only those transients; there will be plenty of others. So in this case, you can "promote" the transients that occur on the beat, then set a high threshold that ignores all the other transients (promoted transients are immune to threshold changes and are always in play).

Yet another way to tweak transients is to simply add you own transients right on the beat; the AudioSnap palette has an Insert Transient Marker button.

Now, all this may raise more questions than it answers. However, as we work through some examples in subsequent posts, it should all make sense. And if it doesn't...well, this is a Pro Review, ask your questions and things will be clarified.

[Anderton]

Let's try getting tempo to follow along with a groove, using the AudioSnap feature. Just to make things tough, I'm using a drum loop played by an Actual Human so there are some little variations and timing inconsistencies. The clip is 8 measures long.

The first thing you do is right-click and select AudioSnap Enable. Fortunately, this clip has a prominent downbeat for each measure. What we'll do is "promote" each downbeat, then raise the threshold so that only the downbeat transient markers are active. If all goes according to plan, I should be able to then tell Sonar's tempo to sync up with these.

BUT take it from me, the first thing you want to do is make sure that any tempo changes are erased, and you're dealing with "flat lined" tempo. We can add changes later if desired. If there are already tempo changes, AudioSnap can become hopelessly confused.

So I played through the clip, identified the beats that fall at the beginning of each measure, right-clicked on each one, and selected "Promote." You can also just Ctrl-click all the ones you want to promote, and promote one of them to promote them all.

Next I set the Threshold to 100%. This left only the "promoted" transients. Then I clicked on "Align Time Ruler." I decided to try the "Extract Timing" option, as the clip is pretty short and when this works, it's the fastest way to go. So I selected an "Expected Pulse Duration" of a whole note, but didn't check "Find a steady rhythm" because there's nothing much steadier than a transient at every measure. Click on the attachment to see how this was set up. Will it work? Let's click on "Extract Timing"...

[Anderton]

Bingo! Click on the attachment to see what happened. All the time ruler measure indicators snapped right to the designated measure transients on the clip. Remember, there was no processing of the clip; the clip is the same, it's the tempo map that's changed to accommodate the clip.

There's still a loose end: The clip doesn't end exactly at measure 9, which I'd like it to do. I tried just slip-editing the clip (without stretching) to the beginning of measure 9, but the little silent part was noticeable. We'll attempt to fix this in a minute, but first, let's take a look at exactly how Sonar 6 pinned the tempo to the clip.

[Anderton]

Sonar 6 does this magic by altering the tempo map to "fudge" the tempo between designated transients. Click on the attachment to see the "post-pinned" tempo map. If there had been a transient at, say, every 1/4 note, then the tempo map would likely show smaller changes at every 1/4 note.

Now let's see if we can fix that silent part at the end.

[Anderton]

Okay, I tried a bunch of different stretching techniques to deal with that silence at the end, like splitting off just the end of the clip and trying to stretch it. But ultimately, what worked best was just zooming in really close on the tempo view, and adjusting the last tempo change until the end of the clip lined up exactly with the start of measure 9, then I added a very quick fade...problem solved.

However, although we've proven a point here that you can match tempo to a clip, this isn't a very practical example in some ways. It would be very practical if the clip was an entire tune, because then we'd have a tempo map for the entire tune. But if we wanted to use that clip throughout a song, we would need to copy and paste the tempo map to go along with the clip.

So, if we indeed wanted to use this clip throughout a song, it would make more sense to match the clip to the tempo. That way, we could just copy the clip over and over again, secure in the knowledge that it would line up with the project tempo. There's an easy way to do this that doesn't involve stretching.

First off, because of the pinning-tempo-to-clip exercise we just did, we know the clip's tempo is somewhere around 122 BPM. So, we can "flat line" the tempo, and just tweak the tempo until the beginning of measure 9 lines up exactly with the end of the clip. As it turns out, a tempo of 122.02 causes the beginning of the clip to land at measure 1, beat 1, and the end of the clip to land on measure 9, beat 1. Perfect.

Of course, this doesn't deal with any timing variations that occur within the clip, and suppose we want to use this loop with various electronica loops that have perfect timing. The fact this clip was played by a human creates some flams and inconsistencies that don't work with the "perfect" loops. We now have two choices: We can have the perfect loops follow the human one, or the other way around. For now, let's quantize the humanized loop and make it perfect.