Experimenting with the Audio Transport stuff again after seeing a friend’s gig that made heavy use of it and am finding that when interpolation is at either extreme, the audio null summing. Or rather, having interpolation at either extreme does not present unprocessed audio.
If you only play in one stream of audio then the input is the same as the output, regardless of where the interpolation value is at.
Is this meant to be the case and/or a limitation of the algorithm?
It’s obviously possible to just crossfade to clean at the extremes, but it can create a bit of phasing/funny-business when moving to the edges like that.
My guess is that interpolation being at either extremes makes it so the object still computes the optimal transport plan for each FFT frame in the morph rather than just resynthesizing the input. Maybe this adds some error?
Indeed, this was a ‘test’ - we implemented that 4 years ago and it is the first time someone flags it
Seriously, in this case, it made no sense to null-sum - it is super experimental and work so hard under the hood. using this at 0 or 100% is not really efficient. also, using it at 99.9 gives good results, so the liminal space became an overcomplicated question.
if you need a bypass, I recommend poly~ and killing the voice if 0 or 100, your CPU will thank you.
As it is, it works pretty poorly with time-sensitive material (i.e. drum/percussive hits) as it just smears into FFT mush, so will see if there’s some use case(s) where it works/sounds good for the kind of thing I have in mind and go from there.
If that works, I’ll explore properly bypassing audio when at the extremes.
I presume I could add in the client at hard bypass - the algo does it deep now as an optimisation (computes the whole stft and magnitude and if either is 0 it doesn’t assign)… so we could check at client level if you are 0 or 100 and then bypass there. if you think that is logical, put a gh feature request.
now before you do so, let’s think about what null-summing is. it is a sum of the outputs that nulls to the input. in this case, there is only one output. so we could argue for ever if that is the right concept there…
What is that pop-corn meme again? I could tag here a few people with strong opinions and sit and watch
I’ll pop a github issue in for this. I think that would be ideal, that at either 0/100 it does the same thing and doesn’t do anything. “null summing” is not the ideal term here as it’s not that, but more that at either extreme (of interpolation), nothing is done to the signal (other than delay it).
Heh, in a perfect world this would bypass to zero-delay as well, but that obviously becomes really really messy. Hence just keeping delay consistent (like your example above).
