After creating a thread asking about how to best implement fades in a JIT/HPSS context I was reminded of @tutschku’s old request for implementing fades in fluid.bufcompose~.
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.
OR
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.
fades are definitely up on my 3rd list of new features for tb1. When the code is out, someone might even propose a pull-request with that new attribute on.
1 Like
Yes, it’s been on the enhancement list since March, but not as a high priority. I’m quite into the idea of a more general set of multiplicative options (so that one could, e.g., apply modulators to buffers) but – as ever – am loathe to do it in a way that adds much extra complexity to the interface (especially given the emerging theme that interfaces are already too complex!)
One future possibility is that we have separate messages / functions for adding / multiplying, plus some basic support for handling fades via parameters. Sooner or later though we start to encroach on the kind of comprehensive buffer processing territory that @danieleghisi is developing with Ears (which already has a buffer expr type object, for instance).
Definitely slippery slope that.
Vanilla fades (with fade types as rainbow sprinkles) adds a lot of utility to the existing workflows, so my vote would be on something more like that.
The functions/modulators are super interesting and useful to, but kind of extend beyond the scope (seemingly to me) of the overall project.
1 Like
Here is a small shell script using ffmpeg I usually use to concatenate audiofiles:
echo "">temp.txt
for i in *.aif; do
echo "file $i"
echo "file $i">>temp.txt
done
ffmpeg -f concat -safe 0 -i temp.txt -c copy output.aif
rm temp.txt
2 Likes