Snap to Grid Bug?

[Diogo Tavares]

Hello.

Apparently, time stretched clips (CTRL+SHIFT+Drag) will not snap to grid properly.

The clip seem to snap according to its original start and end times, BEFORE it was stretched.

 

This happens independently of the "BY" or "TO" setting on the "SNAP TO GRID" panel.

 Bouncing the clip (Right Mouse Button->Bounce to Clip...) stops this behaviour.

 

Is this a bug or just some setting somewhere I am not finding? 

[Diogo Tavares]

Rolled back to the previous version. Same problem.

 

Copying the clip using only CTRL and dragging it produces the same result.

However, using CTRL+SHIFT and dragging the clip will copy it correctly.

Meaning it will snap according to grid settings. But ONLY using CTRL+SHIFT.

For now I am using this as a workaround.

Edited January 11, 2023 by Diogo Tavares

[Diogo Tavares]

So as soon as I time stretch the clip, a Snap Offset value is applied to its properties.

Defaulting it to zero solves the problem.

Why on earth would this happen is beyond me, but I'm still assuming there is

something I'm missing "configuration wise". (Hoping, even)

[Diogo Tavares]

It is apparently an old problem that was never solved.

 

http://forum.cakewalk.com/Snap-to-grid-fails-on-stretched-audio-m3080019.aspx

[msmcleod]

If you select your clip, then select "bounce to clip(s)", it will solve this issue.

Another reason for doing this:  By default, stretching a clip in the clips view will use the online method (e.g. Elastique efficient).  This is very quick, but results in lower quality results.

The idea is that you use the online method to get it to the correct stretch length, then use bounce to clip(s) to "commit" your results using the offline method (e.g. Elastique Pro) giving you much higher quality results.

Once you've committed your stretch using bounce to clip(s), the clip is no longer seen as stretched - it's now a new non-stretched clip in its own right.

[murat k.]

1 hour ago, msmcleod said:

If you select your clip, then select "bounce to clip(s)", it will solve this issue.

Another reason for doing this:  By default, stretching a clip in the clips view will use the online method (e.g. Elastique efficient).  This is very quick, but results in lower quality results.

The idea is that you use the online method to get it to the correct stretch length, then use bounce to clip(s) to "commit" your results using the offline method (e.g. Elastique Pro) giving you much higher quality results.

Once you've committed your stretch using bounce to clip(s), the clip is no longer seen as stretched - it's now a new non-stretched clip in its own right.

Can you fix this bug? When you come up with a workaround I have a feeling like: "This bug will never be fixed."

[Milton Sica]

1 hour ago, msmcleod said:

If you select your clip, then select "bounce to clip(s)", it will solve this issue.

Another reason for doing this:  By default, stretching a clip in the clips view will use the online method (e.g. Elastique efficient).  This is very quick, but results in lower quality results.

The idea is that you use the online method to get it to the correct stretch length, then use bounce to clip(s) to "commit" your results using the offline method (e.g. Elastique Pro) giving you much higher quality results.

Once you've committed your stretch using bounce to clip(s), the clip is no longer seen as stretched - it's now a new non-stretched clip in its own right.

Hello, even if it is an alternative solution, see if this would be a step-by-step to carry out this operation.

1-Select the CLIP and open the SNAP palette
2-Choose Quantize
3-Export to CLIP
4-Select the clip again and open the SNAP palette
5-Select a type off - something like Elastique PRO
7-Quantize again
8-Export to CLIP

[msmcleod]

I can't reproduce the issue here. Stretched clips are snapping fine for me.

@murat k. - I don't think there is a bug with snap and stretched clips. Looking at the linked post, it seems to be related to Snap Offset.  If the snap offset is non-zero, then it sounds like the snap is functioning correctly - i.e. it's correctly applying the snap offset to the snapped position.

The question is, what caused the Snap Offset to go to a non-zero value.

@Diogo Tavares - if you can narrow down the steps that cause the snap offset to change, we can look into it and hopefully find a fix.  If you keep the clip inspector open and keep an eye on the snap offset, hopefully you'll be able to narrow it down.


 

[murat k.]

2 minutes ago, msmcleod said:

I can't reproduce the issue here. Stretched clips are snapping fine for me.

Same here. You can take my comment as general. I prefer a solution from you like: "This will come up in the next update" instead of a workaround. 

Actually this happens sometimes but in general you share workarounds, when a normal user does that it is OK, but when you do that, it makes me think that way.

[msmcleod]

6 minutes ago, murat k. said:

Same here. You can take my comment as general. I prefer a solution from you like: "This will come up in the next update" instead of a workaround. 

Actually this happens sometimes but in general you share workarounds, when a normal user does that it is OK, but when you do that, it makes me think that way.

Most features in Cakewalk have been developed with a particular workflow in mind.  What I described was the intended workflow, not  a workaround.

As far as bug concerned, there are a lot of posts complaining about bugs which aren't bugs at all - it's just users complaining that the software doesn't do what they expect, either because they don't understand the feature, or it doesn't work the way they want it to work.

If it is indeed a genuine bug, then the first step for the development team is to reproduce the bug.  Once we've reproduced it we can then look into what is going on, why it is doing what it's doing, and hopefully be able to come up with a fix.

But unless we can reproduce the bug in the first place, there's absolutely no way we can fix it.

In this particular case, from what I can tell there is no bug with snap and stretch clips.  It appears to be correctly applying a snap-offset to the snap.

If the snap offset is being corrupted somehow, then that is the bug.  However until we can get a list of steps to reproduce that, there's not a lot we can do.

[murat k.]

25 minutes ago, msmcleod said:

As far as bug concerned, there are a lot of posts complaining about bugs which aren't bugs at all - it's just users complaining that the software doesn't do what they expect, either because they don't understand the feature, or it doesn't work the way they want it to work.

When saying "general" it was  also containing feature requests. When you respond a feature request by a workflow which is not a quite efficient way, it disappoints me. Because I am expecting from you to prefer the best and efficient way. When you share a cumbersome way, sorry, I cannot accept it as a solution, it is a workaround. You have power to change things and make things better in the Cakewalk. So I expect from you prefering the most efficient and innovative way, because only with this way we can make an improvement.

This talk is out of topic right now. If you want we can continue this talk in this topic because it is directly related to it:

 

[Byron Dickens]

IT IS NOT A BUG WHEN YOU DON'T LIKE IT THAT THINGS OPERATE THE WAY THEY ARE DESIGNED INSTEAD OF THE WAY YOU WANT!

[murat k.]

6 minutes ago, Byron Dickens said:

IT IS NOT A BUG WHEN YOU DON'T LIKE IT THAT THINGS OPERATE THE WAY THEY ARE DESIGNED INSTEAD OF THE WAY YOU WANT!

Calm down Lord Byron. ?  

[msmcleod]

Thanks to @David Baay for a repro on this.

The issue has been identified, and fixed for the next update.

[Diogo Tavares]

On 1/15/2023 at 11:01 AM, msmcleod said:

If you select your clip, then select "bounce to clip(s)", it will solve this issue.

Another reason for doing this:  By default, stretching a clip in the clips view will use the online method (e.g. Elastique efficient).  This is very quick, but results in lower quality results.

The idea is that you use the online method to get it to the correct stretch length, then use bounce to clip(s) to "commit" your results using the offline method (e.g. Elastique Pro) giving you much higher quality results.

Once you've committed your stretch using bounce to clip(s), the clip is no longer seen as stretched - it's now a new non-stretched clip in its own right.

Thank you for your reply.

I did realise that bouncing the clip would work. However, that would not be the ideal solution for what I was doing, workflow wise!

To clarify, this project involved forcing A LOT of audio files to an approximate BPM. I do know I could be using audiosnap but to be honest I haven't had much success with it, specially with the quality lacking considerably on some of these files. So I used a simple method that involved splitting the audio file manually every one or two measures by hand and then using time stretch on each one of the split clips with snap to grid enabled to conform it to the grid. This has alway worked for me when automated processes don't and I am quite adept at the process. Metronome usually conforms perfectly once I'm done and it's a cross platform method that stayed with me from back when I was hoping between studios depending on who hired me for this or that project. My main DAWs at my home studio have been cakewalk and Pro Tools for two decades. (Cakewalk even longer). But even if I have to work with any other DAW, if it has a grid and time stretch, I can conform any audio reference to it.

Of course this means I end up with dozens of small clips I need to snap back to grid. (To be honest, Pro Tools makes these kinds of edits easier with the "Shuffle" option since I never need to separate the clips from one another when time stretching so they don't overlap. Overall stretch quality is better in Cakewalk though, and this is one of the few things that are actually better/easier in Pro Tools. Not that many now a days!!)

 

On 1/15/2023 at 12:30 PM, Milton Sica said:

Hello, even if it is an alternative solution, see if this would be a step-by-step to carry out this operation.

1-Select the CLIP and open the SNAP palette
2-Choose Quantize
3-Export to CLIP
4-Select the clip again and open the SNAP palette
5-Select a type off - something like Elastique PRO
7-Quantize again
8-Export to CLIP

Like I wrote above, audiosnap doesn't cut it. Some of these Audio files are references recorded/sung on to a cell phone with a laptop playing a stripped down orchestration in the background for reference. (Sometimes it's just a beat so I can know what the overall idea for it is) My job is to orchestrate it and believe me when I tell you that it is A LOT easier to do this when the reference is conformed/quantized to a stable BPM. Even when they send me something like an MP3 (some of the authors are using cakewalk per my request to record these references) with an Instrumental taken from Youtube or wherever, the bpm will drift and I end up having to quantize it. Some of them play the guitar a bit and prefer to record a reference with it... It's a nightmare. For me AND for audiosnap!!!

 

On 1/15/2023 at 12:32 PM, msmcleod said:

I can't reproduce the issue here. Stretched clips are snapping fine for me.

@murat k. - I don't think there is a bug with snap and stretched clips. Looking at the linked post, it seems to be related to Snap Offset.  If the snap offset is non-zero, then it sounds like the snap is functioning correctly - i.e. it's correctly applying the snap offset to the snapped position.

The question is, what caused the Snap Offset to go to a non-zero value.

@Diogo Tavares - if you can narrow down the steps that cause the snap offset to change, we can look into it and hopefully find a fix.  If you keep the clip inspector open and keep an eye on the snap offset, hopefully you'll be able to narrow it down.


 

I apologise. I thought my third post had clarified that the problem was a snap offset being applied to the clip as soon as it was time stretched. I wasn't clear on that. I went back a few versions to see if this was a new problem but stopped rolling back when I found the link to that old post describing the same problem on a pre Bandlab version. 

And yes, I can see the value being applied as soon as I time stretch the clip. No idea what the error's criteria is since it seems that the value is quite random. Maybe it isn't since the resulting clips are never the same size. What I've been doing as a workaround is: time stretching all the clips and once that is done, I select them all and default the Snap Offset to zero. Then it's just a matter of putting them all together again with snap to grid on. This adds some time to the process but it is still faster than playing around with the audiosnap markers. (Deleting the extra ones, creating the missing ones, moving them around, etc...). 

 

On 1/15/2023 at 1:04 PM, msmcleod said:

Most features in Cakewalk have been developed with a particular workflow in mind.  What I described was the intended workflow, not  a workaround.

As far as bug concerned, there are a lot of posts complaining about bugs which aren't bugs at all - it's just users complaining that the software doesn't do what they expect, either because they don't understand the feature, or it doesn't work the way they want it to work.

If it is indeed a genuine bug, then the first step for the development team is to reproduce the bug.  Once we've reproduced it we can then look into what is going on, why it is doing what it's doing, and hopefully be able to come up with a fix.

But unless we can reproduce the bug in the first place, there's absolutely no way we can fix it.

In this particular case, from what I can tell there is no bug with snap and stretch clips.  It appears to be correctly applying a snap-offset to the snap.

If the snap offset is being corrupted somehow, then that is the bug.  However until we can get a list of steps to reproduce that, there's not a lot we can do.

Yes. I understand this completely.  Hence my natural reluctance to post this and any other possible/past "Bug". I've seen a few posts from people saying "This is a bug" when in reality it is an "option" or a "choice" from the programmers. Also, like I wrote previously, I use both Cakewalk AND Pro Tools extensively. Even though, overall, I do prefer Cakewalk, I must admit there are a few features in Pro Tools that I would ABSOLUTELY LOVE to have available in Cakewalk like the Clip Shuffle, that I have mentioned earlier; the fact that Pro tools is recording AS SOON as you press play, even if you haven't punched in yet (allowing you to slip the clip to a previous start time); or a pre and post roll option. But here's the thing:

-Sometimes, what you assume is a feature lacking in cakewalk is, in reality, an option you just didn't look hard enough for

-If you start asking for stuff that other DAWs offer, you're setting yourself up for a "Just use that other software then you idiot" kind of answer. (Justified, IMO)

-Do you have any idea of the amount of features Cakewalk offers that I would love Pro Tools would have too? Start with anything MIDI and you'll get the picture.

-Cakewalk is free... Actually FREE nowadays. Be humble and thank the guys instead of bitching around for everything you want them to GIVE YOU!

-Pro Tools is, nowadays, a subscription based DAW. (Which I refuse to sign up for). That is the reason why I use an old version of it. (And I've payed for a few, even   after spending A LOT of money on a lot of Digidesign and AVID hardware back in the day). Cakewalk is FREE and CONTINUOUSLY UPDATED. So "Thank you guys". 

 

18 hours ago, msmcleod said:

Thanks to @David Baay for a repro on this.

The issue has been identified, and fixed for the next update.

Again, thank you very much...

Edited January 16, 2023 by Diogo Tavares

[Diogo Tavares]

It's always a fun experience when you get caught in your own trap. 

Just to get the record straight, the Pro Tools "Shuffle Edit" option I mention above is ALREADY included in Cakewalk. It has been for a long time, actually!

It's called "Ripple Edit" and you can access it through the [options] drop down menu in the "Track View". It actually adds to it when compared to Pro Tools.

So I just proved myself that sometimes you should look harder or even read the manual before complaining about or even requesting an option/function!

(Pre and Post roll would be nice though...

[jono grant]

A quick note: 

People  using the reply: "The program is free"

GUESS WHAT? Many of us paid $900 for the damn thing! I'm also sick of work-around suggestions to fix decade old problems. Just sayin....

 

 

 

 

 

 

 

[Diogo Tavares]

On 3/5/2023 at 8:34 PM, jono grant said:

A quick note: 

People  using the reply: "The program is free"

GUESS WHAT? Many of us paid $900 for the damn thing! I'm also sick of work-around suggestions to fix decade old problems. Just sayin....

 

 

 

 

 

 

 

I second this... (and even empathize, btw)

And I will add that EVEN IF YOU DID NOT pay for the software in the past, this IS a forum for "BUG REPORTS" and "FEATURE REQUESTS". Telling anyone that is doing EXACTLY what the forum is for that they shouldn't because the software is free is just plain silly. 

In cases where the OP is asking for something that already exists, telling him so politely will actually help. (This is also a "help forum" after all)

 

And requesting a feature for cakewalk that you like and find useful in any other DAW is also NOT a bad thing in my opinion. Imagine a DAW containing EVERY useful feature and function and option and workflow possibility.

Impossible, I know... But wouldn't it be great though? THAT DAW would leave any other DAW in the dirt!!!  (For me, cakewalk already does in many ways... But still...).

And I know that there are almost as many "workflows" as there are people using DAWs but let's not kid ourselves. It's every developer's dream to be able to cater to EVERYONE no matter what their prefered workflow or even main area of work is. Even in cakewalk. You've got Video and Midi and Virtual Instruments and Audio Plugins and MACROS and shortcuts presets and Staff View and Matrix View and whatever else your workflow may desire. 

Anyway, I am pretty damn happy that this problem was detected and that it will be corrected upon my request. THAT's what this forum is for and it worked pretty damn well for me.