Reduce dependency on padding

Many of our functions use padding to simplify vectorization of certain operations, eg:

https://github.com/librosa/librosa/blob/aec87d801144168d95142386a3efd200cb3dde76/librosa/util/utils.py#L943-L946

in util.localmax exists solely to make edge cases easy to handle in vectorized code.

This is good because the code is concise, readable, and fast. But it’s also bad because it invokes a full O(n) memory copy for what is literally an edge case.

We should conduct a thorough audit of the library for this kind of thing – I don’t think there is very much of it – and replace pads with more careful code that can operate in place if possiible. Odds are good that this will require some numbafication if we have to replace vector ops with loops.

[bmcfee]

Adding this to the 0.10 docket - I expect what we’ll end up with is:

• stft/istft via #1514
• localmax/localmin via the above

The rest of the identified pad usages seem either low-priority (few code paths touch them) or not worth the added code complexity to optimize.

Local min and max are higher priority because they get used as utility functions, eg within (p)yin and beat tracking. The optimization is easy to do and the payoff is substantial.

[bmcfee]

After a bit of reflection, I think we should remove this from the 0.9.2 milestone.

Getting STFT and friends #871 covered will pick up the vast majority of performance gains here, and the rest would make the code more complex than I’m really comfortable with. (Though TBH, not very many of these are easy modifications anyway.)

Thinking longer term, I think what would be most helpful here is an abstracted “padded array” class that divides up an ndarray into its padded regions and original region, similar to how a dask array divides up into chunks, where the original region is copy-by-reference. I don’t think this functionality belongs in librosa, but if it made its way into numpy (or a lightweight standalone package that we could depend on), that would be the best option all around IMO.