Added Delay Augmentation, tested on per_batch and per_example

[Pliploop]

Hi there,

I used this repo in a project of mine and ended up implementing my own custom delay augmentation using your boilerplate. I figured it would be useful for others so I'm contributing it here. Let me know if you want any changes made - I cooked it up rather fast but did test it pretty extensively on per-batch and per-example use cases. I don't think per-channel is a relevant use-case for delay, but could implement it if needed.

[iver56]

Thanks for the PR! I'll have a look later. In the meantime, could you please add a unit test or two?

[Pliploop]

Hi again @iver56 , sorry for the Delay ( :D ) In answering:

Tests have been added, and I changed to uniform sampling for some parameters.

Let me know if anything else is needed.

[iver56]

Thanks, I will have another look at it next week, probably on monday 👍

[iver56]

Thanks for your efforts thus far. I have reviewed the PR and noted some change requests:

• Set requires_sample_rate = True instead of False
• Remove explicit "if not sample_rate" check in __init__, and use the sample_rate check in BaseWaveformTransform, which kicks in when you set requires_sample_rate = True
• Allow passing sample_rate in either __init__ or in forward (i.e. when calling the transform), like what is possible in some other transforms in torch-audiomentations. I think this means you have to move some light calculations that are based on sample_rate from __init__ to randomize_parameters. Check other classes in torch-audiomentations for inspiration.
• Resolve the git conflict
• In order to align with the API style of the rest of the project, please change the style in which value ranges are passed. E.g. input min_volume_factor and max_volume_factor instead of volume_factor and volume_factor_range
• Adjust the default parameters. Have a slightly wider range of repeats, attenuation, volume factor and delay. Also, I generally find the effect to be too subtle by default, so it would be cool if you could tune the defaults to allow for a more "extreme" result too.
• format code with black

When it comes to the randomization of the delay time, I'm not sure if picking it linearly is best. Maybe exponential makes sense too in some cases? We could definitely use linear, but the possibility of exponential was a thought that struck me as I was going through the code. I'm open to input here. If you think linear is apt, let's roll with it for now.