Now, I understood the ‘feature creep’ concern of this back then, but now in coming across a problem in which this would be an ideal solution, I was reminded of this.
Granted, @tremblap’s suggestion of “just use HIRT” still holds true, but it seems to me that this would add a lot of functionality and utility to the native toolbox without needing to go elsewhere. (i.e. a lot of what
fluid.bufcompose~ can do in general, can happen elsewhere, but having a native solution makes many things much easier. So the integration and ease of use are factors worth considering here).
Now, this can totally get problematic in terms of what kinds of fades, and all sorts of stuff. So I think just capping it at linear fades and then pointing elsewhere if you want something more complicated would be the way to go.
Just spitballing here, but perhaps a different take on that would be the ability to set a
@gain attribute as well as some kind of flag for multiplying (rather than just summing) bits of buffer together. So you can then use
fluid.bufcompose~ to apply a window (of any type) by
fluid.bufcompose~-ing them in place. This could also make for other interesting additions (cough multiplications) to the object.