-
Notifications
You must be signed in to change notification settings - Fork 423
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
Replace audio effect BindableList
by Add/Remove methods
#6310
Conversation
BindableList
by Add/Remove methods
// If the effect types don't match, the old effect has to be removed altogether. Otherwise, the new parameters can be applied onto the existing handle. | ||
if (oldEffect.Effect.FXType != newEffect.Effect.FXType) | ||
removeEffect(oldEffect); |
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 does the new code not attempt to handle UpdateEffect()
calls that change the effect type entirely in the same way? Does it not need to? Was this tested to work in such a scenario? (I only checked docs, but I can't see any mention of whether this is going to work or not).
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.
It doesn't support changing the FX type anymore. You can't even do that because UpdateEffect()
uses an IEffectParameters
reference.
In my first commit, the one that had a wrapping AudioEffect
class, the implementation also threw an exception if that was attempted, so I'm very much of the mindset that this shouldn't be a thing and may only be supported by the user doing this themselves.
Fwiw, changing the FX type is a "non-atomic" operation anyway - it needs to remove the previous filter and add the new one which means there's a small amount of time during which sound could be playing with no filter attached. As well, doing this means that priority gets kind of funky.
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.
I'm OK with this.
The
BindableList
adds complexity when you want to update the filter that I don't think is justified.We've also recently disabled effect re-prioritisation due to it causing segfaults, so I don't foresee ever really needing that ability either, at least not in a way that it's a common operation. Therefore I think it's best to just move to a simpler state of being.
osu!-side diff (note that I've also removed the invalidation because I don't think it's necessary):