fix: Filters are not public
Description
All filters live inside the src folder, meaning they are considered "internal implementation libraries that should only be imported and used by the package itself" (according to the dart docs). This means the linter complains if you try to access them (linter rule implementation_imports), which is annoying when writing typed getters etc. Is there a reason why the filters are not public?
Sorry, I didn't understand this. You can set or get parameter values with something like:
SoLoud.instance.filters.pitchShiftFilter.shift.value = 1.5;
but you do not need to import 'pitchshift_filter.dart'.
Everything you need is in SoLoud.instance.filters.pitchShiftFilter
Yes, sorry about my unclear description 😁 I happened upon a situation where I want to provide convenience methods to access filters for specific sounds, the simplest example being simply out of convenience; not wanting to write source.filters.pitchShiftFilter(handle: handle) every time.
In my actual use case I have implemented my own class that wraps around one or multiple AudioSources, to provide a consistent interface for using filters when playing just one sound and when playing multiple sounds simultaneously using a group handle. When using a filter on the group handle, we have to apply that filter to each audio source in the group, and the wrapper class takes care of this. So basically I'm creating getters that use the types of the filters.
Maybe that explanation didn't help clear things up at all... but basically I'm just wondering if there is a specific reason the filters are not public? They are after all exposed by a public API (the SoLoud singleton), so it feels strange for them not to be public too?
All filter sources are intended to read/write/check their parameters and to manage the filter when it is global or assigned to a single AudioSource. So they stick to their source or globally.
I think you did the right thing by making your custom class to manage multiple AudioSources. Inside that class you can be helped using the FilterType enum, which is exposed, to track which filters should be activated.
Maybe we could think of a way to handle filters for groups, but we might run into some difficulties as the filters for individual sounds must be assigned before playing them.
I will think about this.