timeshift clip changes size?

RE: XP - V2.1.1.0 - w/installer
Thought I’d report a problem I’m having since I can’t find an answer. I split a section of a track with the clip boundaries tool then move it with the timeshift tool to a blank adjoining track. Then if I try to move it back into the hole it just made without doing anything else, only one yellow line will match up and the clip has become too large to fit into the hole. Even if I highlight the hole and note the size of it and the clip, they both show the same size. Is this a bug or am I missing something?

I also notice that the visual (and thus reactive) sizes and cursor locations will change when zooming in & out causing some real problems with track syncing later after editing since things then need to get moved around to fit properly.

Thanks for any help,

Thanks, Ken.

I assume the apparent “larger size” of the split clip when dragged into another track and hence the oddness in boundary snap guide behaviour when dragging the clip in the new track is because a split always has white space between the two clips. You can see that space if you were to zoom in at either split line before dragging the clip to a new track.

I have no problem moving the clip back into its original track on Windows 7, as long as I can see one of the boundary snap guides. It may help to hold CTRL when vertical dragging, which prevents the clip moving laterally.

Can you please explain the steps to reproduce that in more detail? Do you mean that you can’t see the boundary snap guide if you are zoomed in to the middle of a clip?


Hi Gale,
Little hard to explain but doing the same edit as above, split/new, zoom way in, try to realign, you see the results. Knowing now what you’ve told me will help but I was doing lots of editing zoomed out and after zooming in later, realized I was pasting parts in all the wrong places. :open_mouth:

In pic #4 the selected area from the split/new should have simply moved straight down to match the clip? At least now I know to readjust the size of the selected area of the clip inward before refitting it back into the opening above.

The other pics show the limits on movement of a clip with the timeshift tool when highly zoomed. One end is going to overlap unless I trim it down or make the opening larger.

It may just be me, win XP and an old laptop with poor graphics? Is there any tips on setting up graphics cards for this program? I have a Nividia from 2006 and it has a ton of settings.


I agree it can “for some reason” be hard “sometimes” to drag the clip back again into its original track. It “seems” more difficult now to do this in 2.1.2-alpha than 2.1.1.

If you CTRL-drag and the clip won’t go back, you only need a single Edit > Undo Time Shift to put the clip back.

There is white space between clips to represent the “width” of a sample period. The selection extends before the start/past the end of a clip that has been split to represent the sphere of influence of the sample. This is correct in principle (and not an issue with your graphics card) but the clip “should” move back to the original track if it was not moved laterally.

We have been discussing representations of sample widths and where the sample is positioned in the selection recently, so we will look at bugs and difficulties that arise from these.

I do notice (in 2.1.2-alpha) that if I disable the on-by-default Tracks Preference “Enable dragging left and right selection edges”, then if the selection to be split was created with that preference disabled, it is much easier to CTRL-drag the clip back to its original track.

Does that help? If “Enable dragging left and right selection edges” is off then you must use Selection toolbar or keyboard shortcuts if you want to modify the boundaries of an existing selection.


This looks like a “bug”. I’ve not yet found 100% repeatable steps to reproduce, but it is quite easily repeatable if the selection is dragged before splitting. (tested on Linux with Audacity 2.1.2 rc1)

CTRL-drag is a good tip but the problem with undo is that then any editing on the clip gets undone as well. I usually work on copies of clips so I don’t mess up the main track. If the times between clips and openings could be counted on, that would be the biggest help.

An undo history if possible that could have events individually selected would be a great feature. (Don’t get me wrong, the fact that we have unlimited undos already is outstanding!) :sunglasses:

At the moment I think you can count on the selection moving to the correct place if you CTRL-drag. You should not be needing to truncate clips to move them back into the track they came from.

Non-destructive undo is a major new feature, desirable as it may be.

Yes, I’ve started gathering evidence.

In 2.1.2rc1 on Windows, disabling “Enable dragging left and right selection edges” makes a real difference. If I generate a tone, drag a selection, then Edit > Clip Boundaries > Split New and try to CTRL-drag the clip in the new track back to the old, it 100% will not go back unless that preference was disabled before I created the selection.

In 2.1.1, the clip won’t go back irrespective of that preference. It “could” also be that it depends exactly where the pointer is when you drag. We’ve had that before. But zooming in and haphazardly pointing over or between a sample makes no difference there.