Sorry for making this late suggestion, but since we're changing names anyway... how about moving the "Asteroid complex" functions into a submodule, like asteroid.asteroid_complex? If I understand correctly most/all of these functions only work on Asteroid-style complex numbers by default.

No problem at all.

most/all of these functions only work on Asteroid-style complex numbers

This is correct. Three exceptions: compute_delta, concat_deltas and ebased_vad
What do you suggest exactly? What would we do with those three exceptions?
Would complex_nn stay untouched?

I don't know where these would fit. Are those "transforms"? I guess yes, but many thing are "transforms", so I really don't know how to classify those, sorry!

We could move the rest to asteroid.asteroid_complex and add a note to the top of the module that this is only one of the three complex representations (as in complex_nn). And complex_nn stays the same.

Agree that "transforms" is not informative.
Several person already asked if we can outsource the code for asteroid filterbanks outside of asteroid and I wonder today if this wouldn't be a good opportunity. What your take on this?

The only functions on which the filterbank submodule depend are script_if_tracing and mixture_consistency which are unlikely to change so I'd be ok to copy them there as well.. Not the best design but I guess it's ok.

The advantages of this:

• More people would use it (torch-audiomentations and pyannote-audio for example).
• More people might contribute to it? Not sure.

And, the API is stable IMO so we don't expect to struggle to keep things compatible.

Mabe @hbredin would be happy about that?

Happy about having a standalone asteroid.filterbanks  package? I certainly would 💯!

Well this PR escalated quickly 😄

@mpariente I think what you suggest is reasonable (including the tiny amount of copy pasta).

Well this PR escalated quickly 😄

I think it's because if we'd move things to asteroid.asteroid_complex, making a new package out of those things would be a pain..