-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose audio mixers to mods #16771
base: master
Are you sure you want to change the base?
Expose audio mixers to mods #16771
Conversation
osu.Game/Overlays/MusicController.cs
Outdated
foreach (var mod in mods.Value.OfType<IApplicableToTrackMixer>()) | ||
mod.ApplyToTrackMixer(audioManager.TrackMixer); | ||
foreach (var mod in mods.Value.OfType<IApplicableToSampleMixer>()) | ||
mod.ApplyToSampleMixer(audioManager.SampleMixer); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Should IApplicableToTrack provide the mixer instead of a separate interface?
@frenzibyte originally proposed to include the mixer in IApplicableToTrack.ApplyToTrack, but there are many cases where a mixer isn't available (e.g. when using this interface to calculate new track rate in diff calc), so I decided to split this into a new interface.
I still don't really see the reason behind these existing, you can add the mixer but as an optional parameter for such cases:
public void ApplyToTrack(ITrack track, IAudioMixer mixer = null);
And avoid all the extra additions of IApplicableToTrackMixer
/IApplicableToSampleMixer
/IApplicableToMixers
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why would the mixer be nullable in the above proposal? What would a mod implementation do if it is supplied a null mixer while it wants to apply effects, just give up?
I would even go a step further and propose that maybe ITrack
should itself provide a reference to the mixer, rendering all of this unnecessary. But I don't feel confident on that proposal, so I'd advise not to take it too seriously.
In fact note that IAudioChannel
already exposes mixers (albeit only internally to the frammework).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why would the mixer be nullable in the above proposal? What would a mod implementation do if it is supplied a null mixer while it wants to apply effects, just give up?
It's nullable because it's irrelevant in cases like diffcalc. And, correct, I don't see that being a problem, we could not make it an optional parameter if your concern is about it being forgotten in future usages?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I dunno. I think diffcalc doing stuff on tracks in general is kinda dodgy already, and it's currently worked around by passing a virtual track. I'd rather follow that lead and pass a dummy mixer or something, but the perfect scenario would be to decouple diffcalc from audio stuff.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having a VirtualAudioMixer
sounds workable, sure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Created a framework PR for that: ppy/osu-framework#5013
This reverts commit 016e0c3.
All test failures originates from this assertion, which prevents mixers from clearing effects on their own. In practice, `AudioFilter` already gracefully handles such cases in `updateFilter`, so I don't think this assertion is necessary.
Re: #16740 (reply in thread)
The new
IApplicableToTrackMixer
interface mainly provides a way for mods to apply audio filters in song select. During gameplay, this interface is a shortcut to the already possible way of adding a drawable viaIApplicableToDrawableRuleset
, then getting theAudioManager.TrackMixer
via DI.This PR is a pre-requisite to changing muted mod to use a low-pass filter only, instead of adjusting track volume.
This is a relatively simple diff, but there are some points I'm not super sure about:
Should
IApplicableToTrack
provide the mixer instead of a separate interface?@frenzibyte originally proposed to include the mixer in
IApplicableToTrack.ApplyToTrack
, but there are many cases where a mixer isn't available (e.g. when using this interface to calculate new track rate in diff calc), so I decided to split this into a new interface.Should
IApplicableToSampleMixer
exist?Yes for symmetry, but muted mod probably won't be needing this since it requires separate control of hit samples and metronome samples. Feel free to revert 016e0c3 if this is deemed redundant.
Should local mixers be provided to
ApplyTo*Mixer
instead?I don't think any local mixers exist yet. Just providing the global mixers should be the simplest working implementation IMO.
For reference, this is how the muted mod could look like using this interface:
diff