Something that has struck me, across many of the patches I’ve made (recent, old) is that one can often use most of the objects internal @deststartframe and @numframes to “skip” a fluid.bufcompose~ step.
When I was working out the ‘onset descriptors’ stuff, I went really overboard in terms of optimizing to avoid using fluid.bufcompose~ altogether, thinking that was (partially) responsible for the much slower performance I was getting. (The new amazing @blocking mode changes this!)
But in more recent patches, I’ve gone more verbose/linear with it, with clearer “steps” to the process, which is easier to follow and read, but perhaps at the cost of a small amount of computation.
So I’m wondering how people have been handling this?
I suppose it can end up like other code optimization stuff, where at some point you begin to sacrifice legibility for efficiency so it’s likely a balance between the two. Also not sure how “expensive” fluid.bufcompose~ is, other than potentially spiking the scheduler while it mucks about in buffer land.