Ok, I spent some time today playing with fluid.buftransients~ and bouncing individual samples and looking/hearing the results.
Again, not sure if this is expected behavior, but here’s some (seeming) funny business.
Ok, so blocksize directly relates to the length of the transient I’ll get. That makes sense, I can wrap my head around that.
This is ca. 88 samples (which I’m not sure how it relates to the settings).
Bump it up a bit to get a bit longer:
Now we’re getting somewhere. How about one sample longer:
…and peekaboo at the end of the file.
Ok, I’ll try making it a touch bigger:
…and the main transient disappears, replaced with the ending peekaboo bit.
I get this a lot, where one sample in either direction for the params completely nukes the output in a way that, to me at least, doesn’t seem to make sense with what the params are meant to be doing.
I’ve also tried loads of params and combinations to see what determines the “space” between the two clumps that show up, as they are persistent among a bunch of tests. I can get the ending one to move forward by a sample or two and then the front bit disappears.
In practice, I can just tune the settings so I get a starting click and then manually trim all the files after that, but seems like a clunky workaround for someone that I would presume is doable via parameter tweaking.