Implementing hitsound custom samplesets in Lazer

[kstefanowicz]

Currently in Lazer, new timing points get created with the legacy attribute sampleIndex set to 0. This causes custom hitsounds to not persist to the map. (See #29028)

sampleIndex is the .osu file representation of the Custom Sampleset menu in Stable:

The existing legacy decoder/encoder does support this attribute when importing beatmaps made in Stable, and creates those timing points with the legacy attribute set via the Suffix member of HitSampleInfo. This allows legacy maps' custom hitsounds to function properly.

For implementing this attribute in Lazer, I see three options:

• Replicate Stable implementation, and add the attribute as a property of timing points
• Replicate Lazer's slider speed and hitsound nodes, and add the attribute as an additional option in SamplePointPiece
• Have Lazer create all timing points with sampleIndex of 1, and don't bother with values above that

Personally, I like the third option. From what I know the primary use case of the custom samplesets in Stable was to get more than 12 custom hitsounds into a map. With Lazer's implementation of custom sample bank names, that's no longer an issue, and I don't know how many mappers would miss the functionality outside of that use case.

[cl8n]

samples, banks, and behavior of custom sample indexes are as much a skinning feature as a mapping one, and I think that consideration is kind of missing from your open PRs regarding forcing sampleIndex=1 (#29311) and saving custom bank names (#29566).

in stable (and lazer gameplay afaik):

• S plays the skin's soft-<type>.wav
• S:C1 plays the map's soft-<type>.wav, with fallback to the skin's soft-<type>.wav
• S:C2 and onward play the map's soft-<type><index>.wav, with fallback to the skin's soft-<type>.wav

I agree with what you've implied about the first case being unnecessary. if the mapper wants to strictly use the skin's samples, then they can pick S:C1 and just not include the respective files in their map. so I think for non-legacy maps removing "sample index 0" and defaulting (not forcing) sample index to 1 would be a fine simplification of this system.

I don't agree with your further changes as-is that rely on custom bank names though. currently a <custom-bank>-<type>.wav sample has no clear fallback bank to use for skin lookups, and it's probably not going to sound good if you force that fallback bank to be any particular default. additionally, there's no way to get this to function in stable without changes due to the new custom filenames just not being supported there.

my suggestions for how to implement this feature instead: (crossed out 2 and 3 because olibomby's suggestion is overall better imo)

1. the stable-ish way: remove "custom banks" and keep the concept of sample indexes alive, but move their editor functionality to individual samples rather than timing points where possible, like how SV changes did it.

2. if custom banks are nice to have in the editor: do the above but then also implement some kind of aliasing system so that you can refer to N:C2 as a more meaningful My Custom Bank. the filename would still be normal-<type>2.wav, though

3. if custom banks are considered much better overall and making some changes to stable is acceptable:

   • give custom banks the additional option of which default bank they fallback to
   • save fallback banks in the custom bank section of legacy format you've already created in Save custom sound banks to beatmap #29566
   • implement appropriate fallback behavior in both lazer and stable (map's <custom-bank>-<type>.wav --> skin's <fallback-bank>-<type>.wav)

[OliBomby]

If we're going into changing how banks work, I have a fourth suggestion for how to implement custom hitsounds:

4. Let each sample define fallback bank and hitsound for skin's hitsound when custom disabled. Then add an optional custom hitsound filename property that if defined (and beatmap customs enabled) looks for the filename in the beatmap skin for a custom sample sound.
   I feel ilke this would be the simplest implementation of custom hisounds and it matches how I implemented it in my Hitsound Studio tool.

[cl8n]

that sounds cool too for a lot of cases, but I can't tell if it would entirely replace the need for either custom samplesets or custom banks. for example I might have a whole section of a map where I want to use my N:C2 (...or custom bank, if it gets implemented like that) hitsounds and it seems inconvenient if I have to select custom hitsound files for that whole section instead of just adding clap or whistle or finish like usual. I also feel like this would complicate hitnormal, since that is assumed to always play for the given sampleset.

I guess it all depends on how this feature is presented, maybe you have more clever ideas in mind to avoid these UX problems

[OliBomby]

Yeah it does pose some UX problems for the case where you use custom hitsounds but not that much that you're changing custom bank every object. The implementation in stable seems especially optimised for this specific use case.
I'm not sure what you mean with that it complicates the hitnormal, it would work just like the other samples.

I think all you need to solve the UX is additional tools to quickly assign the custom samples, both while mapping and in post to make bulk changes.
A good addition would be to automatically assign a default custom hitsound filename whenever you add a hitsound, so add drum-hitwhistle as the custom filename when you add a drum-hitwhistle etc. Also add an index number so you can have multiple presets. This will only affect placement of hitsounds and it will be fully customizable afterwards.
I dislike how non-descript the filenames are in stable (soft-hitclap2.wav doesn't tell you what sound it is), so it would be nice to also have a menu to customize these defaults. Basically a mapping where you can tell it to assign for example bass snare.wav instead of soft-hitclap2. This will make the filenames more descriptive and eliminates the need to duplicate sample files between custom sample sets.

[cl8n]

that does sound like a good direction then. compared to stable it seems more useful and less convoluted if presented right. I suppose it can also be legacy-exportable if that process does some extra work to map everything back into custom samplesets and rename/copy files accordingly, so probably no need to update stable

I updated my post with my new opinion about these options -- yours is definitely best, but I still think 1 would be a valid choice right now if the goal is to quickly and more easily get this feature in parity with stable.

[kstefanowicz]

This is how I imagine the UX (pardon the MS Paint):

Each "▶" would play the current-assigned hitsound for that combination. Each "+" would open a pop-up to select an existing audio file added to the map or drag in a new audio file.

Assuming custom sound banks are a thing, users would click the "+" at the bottom of the first column to add a new custom bank.

This UX doesn't address the fallback options though, I don't know what the cleanest way to present that would be.

I dislike how non-descript the filenames are in stable (soft-hitclap2.wav doesn't tell you what sound it is)

To my knowledge the game chooses a hitsound based entirely on the filename. To have the filename be separate, I guess it would need to either copy the file and rename it to fit, or change how audio files are chosen?