With Audacity V3.3.3 I sometimes have a mystery which is, in my opinion, a failure with the yellow bar prompt at the tracks window. I am recording successively track by track using the playback and overdub feature. In my projects I am cutting, copying, pasting, shifting and duplicating clips.
Normally the yellow bar prompt works perfect across lots of tracks and clips. But sometimes I can never get a yellow bar prompt at a time point where I haven’t made bad things. Here an example screenshot:
The yellow bar prompt should be displayed at time 50,0 sec. But I can no longer find it with my selection. Therefore I can no longer do an exact cut at time 50.0 sec.
In the meantime I made some investigation for describing this behavior and here are my results:
Before the above shown selection I have made a cut at track “Sopran Horn” at time 50,0 (ctrl + alt + K ) and I didn’t move that clip. Making the deepest zoom in at that point shows this picture:
The cutted tracks are looking frayed. The track “Sopran Horn” is obviously shifted one sample too much to the right, which I have not done. After shifting “Sopran Horn” one sample to the left I will find the yellow bar prompt even after zoom out.
More investigations to reproduce and describe this behavior (remark: the “Sopran Horn” is shifted one sample to the left in the corrected position as described in the paragraph above) :
I do a cut on “Solo 1” at the yellow bar prompt (ctrl + I):
The “Solo 1” cut is obviously one sample shifted to the right. From now on you will no longer see the yellow bar prompt at this time stamp at track “Solo 2”.
I am now doing the same cut at the yellow bar prompt, but from the right side marking like this:
There is a difference at the cut time stamp between left side selection cut and right side selection cut. And the difference is one sample.
So I notice, there is a problem with left side selection and a cut (ctrl + I )
But the mystery continues with another method of cutting:
Now I use the rounded corner of a track for adjusting the length. When I do this at “Solo 1” with the left side corner, the yellow bar prompt continues to works perfect at track “Solo 2”:
Mostly it works fine with the yellow Boundary Snap Guide appearing when I hover my cursor of the 1:15 mark on the any of the waveforms in all four tracks.
I think that what is happening is that when you hover the cursor over the target area for clip-shrinking/expanding (or in 3.4.0 time stretching with Alt modifier) then the Boundary Snap Guide does not appear. The target area is roughly the top one third of the track height. You should notice that when you hover your cursor there at the clip boundary it changes to a a square bracket with left/right arrow-heads.
When you move it down the cursor will change back to the I-beam selection cursor and THEN the yellow Boundary Snap Guide will appear.
The problem is eaxcerbated for very shallow/collapsed (not tall) tracks, as the target area for the I-beam selection cursor appears to get smaller at the expense of the square-brackets target area. And I note that in your use-cases many of the tracks are not very tall.
I suspect that this is a “design feature” rather than a bug - but I am not sure that Muse are aware of this wrinkle. I am a bit otherwise occupied for the next few days but I’ll try to find some time to raise an issue on GitHub for this to bring it to Muse’s attention.
I also note that when the square-brackets cursor is active you cannot click the left mouse button to change the cursor position - you can only do that when the I-beam selection cursor is active.
Muse deliberately made the square brackets cursor target area larger than just the height of the Clip-handle drag-bar - but note that this is NOT the case for the hand icon that you get in the drag-bar for moving a clip. That changes to the I-beam as soon as tou transition the cursor into the wavefotm area - so it does lack consistency in that regard.
Peter
P.S. so the brief answer to your original question is “mystery” rather than “failure”
Thanks for the docu-link. Everything understood. No extraordinariness.
“Mostly it works …”
I agree and I’m happy that it works mostly great.
“I think that what is happening …”
That’s not my problem. I already had notice of this behavior of the cursor hover.
But back to the problem:
You show a screenshot with simple produced audio. With such a project you will never see the “mystery” I described. I did the same before writing this topic. Unfortunately without success to reproduce this “mystery”. And even in my recorded projects I can’t reproduce this “mystery”. But sometimes in a project it happens and than I can reproduce it with that project. So we are talking on a sporicidal mystery and I know: they are satanic.
I did not yet find a way to reproduce it.
But if it helps, I may share my project with you for investigation. The aup3-file has a size of 129 MB. I just opened this project again to see if its still available and it is. For sharing I would like to do it on a private server.
“P.S. so the brief …”
So my P.S. I would prefer to write in the other way round than yours
Developers (and QA folk) often refuer to such issues as “moonphase issues” as the behavior varies withe the phases of the moon - and yes the are often very g=hard to tack down.
@henrymy I have sent you a couple of private messages on this Forum with my email address to facilitate your proposed file sharing.
ok. The bug description from Dec, 17 sounds really like my description. But the following discussion at GitHub was only from a zoom out perspective. My feeling says, you have to discuss this mystery in a deepest zoom in picture as I have shown it in my 2nd picture from Sep 25.
The mystery happens because the cut of a clip sometimes happens EXACT 1 sample too early or too late. Only the developer of the yellow vertical snap line should be able to explain the mystery. I do not (not yet) understand the mechanism in detail.
But I will provide a file for further investigation.
