This was reported internally in
https://discord.com/channels/90072389919997952/1259818301517725707/1343470899357024286.
The issue described was that sample specifications on control points in
stable disappeared after the beatmap was updated from lazer.
The reason why the sample specifications were getting dropped is that
they got lost in the logic that attempts to translate per-hitobject
samples that lazer has back into stable "green line" type control
points. That process only attempted to preserve volume and custom sample
bank, but did not keep the standard bank - likely because it's kind of
superfluous information *for correct sample playback of the objects*, as
the samples get encoded again for each object individually. However
dropping this information makes for a subpar editing experience.
The choice of which sample to pick the bank from is sort of arbitrary
and I'm not sure if there's a correct one to pick. Intuitively picking
the normal sample's bank (if there is one) seems most correct.
The logic in `LegacyBeatmapEncoder` that was supposed to handle
the lazer-exclusive feature of supporting multiple slider segment types
in a single slider was interfering rather badly with the Bezier
converter. Generally it was a bit difficult to follow, too.
The nice thing about `BezierConverter` is that it is *guaranteed* to
only output Bezier control points. In light of this, the same double-up-
-the-control-point logic that was supposed to make multiple slider
segment types backwards-compatible with stable can be placed in
the Bezier conversion logic, and be *much* more understandable, too.
Having these be separate implementations sounded awesome at the time,
but it only ever led to confusion. There's no practical difference if,
for example, catch sees hitobjects with `IHasPosition` instead of
`IHasXPosition`.
Closes https://github.com/ppy/osu/issues/28587.
As outlined in the issue thread, the tail volume wasn't saving because
it wasn't actually attached to a hitobject properly, and as such the
`LegacyBeatmapEncoder` logic, which is based on hitobjects, did not
pick them up on save.
To fix that, switch to using `NodeSamples` for objects that are
`IHasRepeats`. That has one added complication in that having it work
properly requires changes to the decode side too. That is because the
intent is to allow the user to change the sample settings for each node
(which are specified via `NodeSamples`), as well as "the rest of the
object", which generally means ticks or auxiliary samples like
`sliderslide` (which are specified by `Samples`).
However, up until now, `Samples` always queried the control point
which was _active at the end time of the slider_. This obviously can't
work anymore when converting `NodeSamples` to legacy control points,
because the last node's sample is _also_ at the end time of the slider.
To bypass that, add extra sample points after each node (just out of
reach of the 5ms leniency), which are supposed to control volume of
ticks and/or slides.
Upon testing, this *sort of* has the intended effect in stable, with
the exception of `sliderslide`, which seems to either respect or _not_
respect the relevant volume spec dependent on... not sure what, and not
sure I want to be debugging that. It might be frame alignment, or it
might be the phase of the moon.
