Snap copied objects to grid using beat difference between objects

[kongehund]

Type

Game behaviour

Bug description

Currently, copying and pasting/cloning objects in the editor seems to paste them according to the time difference between each object and the position where you paste. In songs with variable BPM, this means that all objects except the first will not be snapped to the grid.

I suggest to use the grid difference instead of time difference, such that each object is placed on the grid corresponding to the same rhythm as the original, regardless of BPM changes.

I suppose this can be done by i.e. counting how many beats are between an object and the first object, and then calculating what time values that corresponds to. If I recall correctly, @OliBomby has already implemented the desired logic in Mapping Tools's ´Pattern Gallery´ section.

I don't think there is any scenario where pasting by time difference is preferred over beat difference.

Screenshots or videos

2024-12-25.18-39-12.mp4

Version

2024.1208.0-lazer

Logs

compressed-logs.zip

[bdach]

Not sure I agree with doing this unconditionally. I'd say doing this should be under a toggle or modifier.

Counterexample as to why doing this unconditionally may be wrong: Say you want to copy a 1/4-snapped pattern when 1/2 snap is active - your pattern will get stretched to 2x the duration, while that may not have been the intention.

[kongehund]

The logic I propose does not depend on the current active snap. Instead, if a pattern is 1/4 snapped, it will always be 1/4 snapped when you paste, regardless of the active grid. (It is BPM dependent - the amount of milliseconds for a 1/4 spacing depends only on BPM)

Because of this, the functionality of pasting would always work the exact same as it always has on single-bpm songs - as such, the only difference this makes is fixing the bug of pasting unsnapped in multi-bpm songs.

[OliBomby]

I guess bdach's point stands for a theoretical map that uses 1x BPM for normal parts and 2x BPM for fast parts. Because the BPMs are a factor of 2 away from eachother they kinda work like a single BPM and you'd expect it to not stretch patterns on copy paste? I can't think of any maps that do this though.

Pattern Gallery has toggles for all these pasting features but they are mostly useful when copying patterns from one mapset to another. I think in the case of copying within the same beatmap it is safe to scale with BPM unconditionally. Not to mention slider durations already unconditionally scale with the BPM.

[bdach]

I guess bdach's point stands for a theoretical map that uses 1x BPM for normal parts and 2x BPM for fast parts

catch might do something like this if they get their allowance in RC to double bpm to effectively double tick rate. But I guess it's niche.

Scaling with bpm makes a bit more sense to apply unconditionally, I tend to agree.

[kongehund]

We could also consider adding additional logic that detects if bpm is within some tolerance of a 2x or 0.5x multiple of the bpm from where it was pasted, and do special paste in this case.

[peppy]

I'd see this being something you manually fix, personally.

[OliBomby]

Can you see how fixing this manually can get tedious, especially if there is a way to automatically fix it.

[peppy]

I'd see it being a different tool – rather than just the standard "paste" as implied in this discussion – if this is to be used often enough to be tedious. Something like "Paste to new rhythm" as a separate menu option, at very least. Or maybe just a post-paste adjustment that can be applied to any selection.

[kongehund]

I don't fully understand the benefit of this feature being a different tool, such as a menu option. This would mean that Ctrl+V can generally not be used to paste in variable-bpm songs, because the pasted objects will almost always require manual fixing. Do you have any specific concerns or problems in mind regarding having this as standard "paste"?

[peppy]

Having objects paste to a different BPM feels really odd to me. Paste usually pastes verbatim, without arbitrarily "fixing" what you're pasting.