toNearestTact() with offset when moving tco

[zonkmachine]

A tco that has been moved off-beat with <Left Click> + <Ctrl> will
snap to nearest full tact on the next move action. Remember the offset
and add this on an ordinary move with snap action.

• Dragging multiple TCO with mixed offsets has erratic behaviour
• Dragging multiple TCO lags a bit at fast mouse action and zoom < ~200%

Fixes #2300

[tresf]

For multiple TCOs being dragged, this makes perfect sense. For individual, I feel that the snap behavior should remain. Losing snap behavior seems like a regression from current functionality.

The bug mentioned in #2300 seems to be primarily focused on dragging a group of TCOs.

[gi0e5b06]

@zonkmachine Good. Approved.
@tresf Offset is user data. It should be kept.

[tresf]

@tresf Offset is user data. It should be kept.

@gi0e5b06 in a grid system, you don't break default snap points unless you have a modifier key.

[zonkmachine]

Dragging multiple TCO with mixed offsets has erratic behaviour with this PR.

[zonkmachine]

I'm trying snapping out of offset with shift modifier.

[Spekular]

@tresf the way it is now, even clicking an audio clip will snap it to grid. Even if snapping is the default action this shouldn't happen. However, I'd prefer that snapping kept offsets. This is how it works in piano roll and makes most sense to me. Clips also keep their offsets when ctrl+dragged to duplicate. If you want something snapped to bar you can always add a new clip and load the sample again, or use click+control+drag to realign it. Or maybe there should be mod+click to snap to bar, like a "quantize" feature.

…

On Dec 8, 2017 07:55, "Oskar Wallgren" ***@***.***> wrote: I'm trying snapping out of offset with shift modifier. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#4043 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIgVmvfdaH6dR3wpqYFFLpWQeeJC7hGVks5s-N1VgaJpZM4Q5_WF> .

[tresf]

Although I agree with trying to stay consistent, I don't think it's fair to begin to compare a misplaced single note with a misplaced TCO. Notes are drawn by single-clicking them. TCOs can be created by various ways. Furthermore a misaligned TCO can be detrimental to the sound of a song if even off by a hair when dealing with syncopation whereas a single note being off is often fine.

TCOs are not easy to delete either. They require a middle-mouse button which a trackpad doesn't offer. The only "consistent" behavior argument that I think is close to that of the piano roll is a BBEditor TCO (since it contains nothing except perhaps a custom color) and even then, they don't seem to remember color properly unless copied/pasted.

Another problem, which may be argued as as separate bug, but must be considered when talking about stable-1.2 (since that's the branch this is against) is that if one is attempting to use the COPY modifier but presses it too late, a non-snapped drag is initialized and a portion is misaligned. Copying/pasting the entire area is not a solution and asking someone to remember yet another shortcut is bad UX.

Again, if you look at the bug this is meant to address, the OP said nothing about single TCOs. The video illustrates multiples.

[tresf]

even clicking an audio clip will snap it to grid.

That's simply a bug. Clicking it shouldn't snap it, moving it should.

[tresf]

Clips also keep their offsets when ctrl+dragged to duplicate.

Right, making it even harder to revert an offset'd TCO.

[tresf]

That said, if we do make this the new default behavior, I would be ok with Drag, Ctrl and release of Ctrl re-releasing the TCO from offset and back to snapping. That would provide the same shortcut to get out of the conundrum that put you there to begin with.

[husamalhomsi]

I think it's hard to misplace a TCO. Resetting offset manually is as difficult as creating it manually.
I would expect individual TCOs to behave like multiple TCOs.

Probably not for this PR, but I suggest that, for any TCOs, the user should be able to drag them to hit the beginning of the track to reset their offset.

[zonkmachine]

even clicking an audio clip will snap it to grid.

I don't see this.

[gi0e5b06]

Probably not for this PR, but I suggest that, for any TCOs, the user should be able to drag them to hit the beginning of the track to reset their offset.

Not really practical (if your track is long) or logical. I suggest instead a single dialog (or window) to edit all the properties of a TCO (like color, name, offset, startFrame, endFrame, etc) but also any specific property.
A good component to edit times and durations with the three used time units (m:s:ms, bbt, frames) would be needed. Something like in the main toolbar but editable and with frame support.

[Spekular]

@zonkmachine I just tested again, RC4 on Windows 10 64-bit. The way I can reproduce it is to zoom in and move a sample track to a "weird" offset that isn't possible at lower zooms, then zoom out and click.

[zonkmachine]

^OK, got it.

[zonkmachine]

Yeah, this turned out a bit too complex. I managed to fix the action for multiple tco's but at the expense of lagging action at fast mouse movement. Especially at zoom < ~200% .

[tresf]

I've been working more and more with misaligned sample tracks and I have to agree that the offsets have great value when moving/cloning. Getting that sample track aligned just right and then moving it really kills productivity.

That said, if I could resize from left, it would probably be less of an issue.

[BaraMGB]

That said, if I could resize from left, it would probably be less of an issue.

That feature is only in master.

What if we snap both? A whole bar the right and the left side of TCOs toNearestTact()? We could make that snap a little bit more smoother. At the moment it snapped in every case. It should snap like a little magnet.

[tresf]

I think drag and copy operations should always maintain offset. To quote @gi0e5b06, the offsets are user data that should be kept. The magnetic behavior is great but I feel is separate issue and will introduce some other nuances.

My major concern is the inability to re-snap. Perhaps a right->click, align to grid.

[BaraMGB]

I think drag and copy operations should always maintain offset. To quote @gi0e5b06, the offsets are user data that should be kept.

I don't know a DAW that behave in that way. If the user want maintain the offset they could align the right edge of there TCO with the grid.

[tresf]

I've posted this to #support on Discord as I don't use other DAWs to be able able to speak to that, but when composing, it's fairly common to drag several items around and copy several items. The inability to maintain offset is crippling to the production process.

[zonkmachine]

Closing. See #4246 and #4262