Great post Big Lion. I've stayed away from audiosnap until now as I don't have much time for experimenting but when the next album/ep recording is under way, I'll be referencing this thread. I think Cakewalk should take note of the workflow described here and maybe try using as the basis of a new HD audiosnap masterclass - but we'll what improvements are in the next version soon enough.

The original 8.53 audiosnap 2 youtube videos looked fine, but I just haven't had the need to apply them yet.
 
Great work. i watched the videos and learnt a lot. Just wondering, if an audiosnap masterclass is in progress or planned, have you checked out Bog Lion's posts here? But just a thought if that's your thing.

Thanks again for such a detailed, well written and well structured post.

Big Lion,

I think I'll need a couple of weeks to digest your post and try them out myself...currently I have left AS in the Sonar shelf (temporarily) because it's so frustratingly hard to understand and to get right!

Cake should commission you to do the AS Master Class videos!! 


Btw, excellent post!

I doubt cakewalk will do a video on audio snap 2.0 until the new release.
Its very complicated and I am not so sure anyone except a very limited few (brunderfly and big lion) on here really understand how it works.
I feel cakewalk is struggling also in getting it right otherwise they would have a fix for the many problems version 2 created.

bvideo


Yes, very well thought out and possibly indicates that the designers and implementers of audiosnap confused themselves along the way.

Some points though:

Why have 2 methods of doing the same thing?(from post #2)

They aren't the same thing. Quantize to groove to me means taking a rhythm scheme essentially from a midi or midi-like specification. Grooves can be created from midi and saved as "grooves". That idea predates audiosnap as far as I can remember. That would be one reason for having the groove items on the menu bar. The audiosnap pool is integrated with grooves mainly by two ways:
1.converting the pool transients into midi and then saving that as a groove, or
2. using a groove as a source for quantizing audio. 

Quantizing from the pool skips the step of saving the pool as a groove. But quantizing from a groove requires either selecting a groove from the saved grooves or creating a groove by way of a midi sequence which by the way could be generated from the pool.

To me, the pool is a nebulous and, well, "transient" collection of transients, whereas a midi track is a much more clearly visible representation of a pattern. Some of the difficulties of editing and preserving transients in the pool would be much more easily managed by putting them on a midi track and editing them there and maybe even permanently saving them in a "groove". But maybe only because the existing implementation of the pool is hard to work and buggy.

-Quantize to Pool allows you to layer transients onto the pool from various sources.

Did you mean that Quantize to Pool layers the transients? I didn't think so. Or did you mean that the Pool is an aggregate of the layered transients from various sources. Which can then be used to quantize.

Anyway, it might be useful to keep in mind that the task of layering a rhythm that is not completely represented by any one audio or midi track is complex by nature. You want some beats, but not all, from one track and you want other beats, but not all, from another track.

It seems that a midi track might be an easier venue in the current implementation for constructing a rhythmic pattern. Many things that are difficult or buggy with the pool can be done maybe easier on a midi track. Then the midi track can be used as a "groove" for quantizing.

Bill B

Hey Bill B,

I just wanted to respond to some of your thoughts-

-Yes, Groove Quantize is designed to operate from Midi. But, isn't it presented as a method of quantizing from audio as well? All you need to do is click the "copy to midi" button in the Audisnap palette. So my question was, why couldn't all these quantizing functions just be combined under a single dialogue? For example, once the user has collected a "pool" of transients, (from either an audio, OR a midi source,) why not give the user the option of saving that as a groove file? Then this one dialogue can provide the functionality of both features. All I'm saying is, maybe there is a way to bring all this under one hood, along with a few check-box options that give the user options. So that it's not scattered about. But I'm not really a software designer, it was just an idea;)

-Yes, I meant that the Pool can be an aggregate of the layered transients from various sources, which can then be used to quantize.  Why not allow that feature as well, in the same dialogue. (Perhaps as a check box- ie, "Ammend or replace current pool.")The odds of someone at Cakewalk actually reading this and taking suggestions seem pretty slim though, so it's probably just water under the bridge;)

bvideo


Could you explain how your process in post #4 preserves the finer-grained timings? Seems like you might have meant that "all other beats in the measure will adjust proportionally" implies something that could align the finer grained transients, but I don't see how.

I see how using "quantize" (not quantize to pool or groove) would align the major beats that were used to derive the tempo map, but I don't see how the finer grained timing is applied. Or maybe it is good enough to let the finer grained timing of the different instruments to not be aligned with one another.

Bill B

So, everything I was writing about was colored by the fact that I'm dealing with human-played material. And I'm also assuming these musicians are not gawd-awful, to start with- let's say your players have "pretty good" rhythm (if they don't, they need to practice, then come back into the studio!)

Given that, what I'm finding is that it's not necessary to quantize every last 8th note to the groove source, one by one. And remember, the groove source that I am referring to here is not "Perfection." It's just another human player's groove. The whole premise here is to preserve some of the timing "imperfections" that make a performance sound human. (ie,  soulful...)

So if the beginning of every measure locks in to the groove, or at most every half-note, then I am finding that the rest locks very well, using this tempo mapping method.

Because by aligning the project time ruler with the groove, the smaller notes in between will effectively "stretch" themselves proportionally, between the locked beats of each measure.

The problem I had with "Pool quantize" is that if you set it to "half note" accuracy, then only those beats that fall on the half note get quantized, and the rest are just ignored and left off rhythm. This makes no sense.

But if you quantize to an 8th note of accuracy, an 8th note beat will only be quantized if your groove source track (from which you got your pool) had a note played on that 8th note. Again, the rest are ignored.

I'm saying, for me, this is the critical flaw in Pool Quantizing. With the tempo map, all the smaller "in between" beats will stretch proportionately between the beats that you locked in at each half note or measure, whether there is a "pool marker" there or not. And I'm finding that makes my material sound very tight (so far:) 

  "Until your project is mixed and finalized, it is recommended that you use the Freeze function instead of Bounce to Tracks(s) or Bounce to Clips(s) if you need to temporarily off-load CPU processing power. "
  I did this on several songs I was recording thinking I could come back and fine-tune audiosnap markers later.  That was unfortunately wrong.  When I opened up most of these songs at the later time, tracks were missing transient markers and waveform displays on sections of the tracks but not others.

Yeah, I think that freezing tracks is very suspect for planting bugs in a track. I can't prove it, but I'm staying away from freezing tracks for now because I've had the same experience. Cakewalk's solution was to bounce the bugged clip to clips, but when you do that, your transient edits are all lost, like I pointed out in the earlier post... bumma.

More Sonar bugs today while working with audiosnap in a new project.

1) Multiple transient markers are stacked immediately on top of one another. So what you see on screen is a non-time stretched marker, but hidden underneath it, is another marker that is stretching time without your knowledge. This introduces major problems. The only way to correct it is to reset all the markers, thereby allowing the hidden/ timestretched markers to move out into the open, where they can be seen and disabled.

2) Wave display disappears when working in audiosnap.

3) Merging and locking transients across two clips causes all transient disabling to be undone in both clips, resets all transients.

4) A transient marker appears enabled, but when you right click, "disabled" is checked. You must re-enable, then disable it again. Then, the marker will appear disabled on screen.

5) Transient markers disappear/ reappear if you zoom in or out, or scroll. These same transient markers cannot be selected. The only choice here is to bounce to clips, which causes all transient marker editing to be lost.

I'm beginning to think this tool should basically just not be used.
Does X1 have any bug fixes on AudioSnap?

I'm beginning to think this tool should basically just not be used. Does X1 have any bug fixes on AudioSnap?

 
BL - I just stumbled on to this thread today.  VERY interesting stuff.  And, I definitely am of the feeling that AudioSnap is best put on the side except for those occassions where the task is simple and easy to accomplish.
 
For complex stuff - like using multiple clips/tracks and adjusting the pool, etc...  it's just not "there" for me yet.   So I do prefer not to use AS if I don't need it.
 
I suspect X1 isn't going to see a whole lot of fixes/tweaks to a few areas  (AudioSnap, The Matrix, who knows what else) because I suspect this new interface rewrite is the main focus and they probably want to see what bugs shake out when it's released to the public.
 
I DO hope X1 point releases DO see improvements in the other areas most/many of use have expressed with concerns.
 
But I, too, want to thank you for your amazingly thorough and thoughtful post on this entire subject.  So Thanks!
 

It's "amazing" that Brandon and/or Seth have not made any comments on this thread. ASnap was a major selling features in S6(?) and now with SX1, it still doesn't work the way it's supposed to.....(at least no mention of bug fixes yet....)

C'mon guys....we paid for this feature. Shouldn't it work as advertised?

Big Lion, thanks for all the work on this. I have run across many of the issues you outline and thus end up working with short clips only or manually align the tracks. Audiosnap and the transient analysis of audio needs additional work.

What I basically need is to get bass and drums perhaps one rhythm instrument to align quickly after recording. That is where a reasonably automated approach would help the most.