Persist CQT device

[ben-hayes]

Closes #17

Opted to remove the device parameter from DataProcessor constructor and let device management take place through nn.Module. Sampling rate can now be passed in constructor, and an initial set of CQT kernels are computed. These are updated, with device persisting, whenever sampling rate is changed.

[aRI0U]

Yeah that's cool, apart from this sampling_rate as arg thingy I like your solution

[aRI0U]

If it can be done differently, I'd prefer not having to specify a sampling_rate (thus calling _init_cqt_layer) in the __init__ to keep it as lazy as possible. Is this add-on necessary for solving the device issue?

[ben-hayes]

The problem with lazy init is that after construction, neither DataProcessor nor its submodules have any buffers or nn.Parameters registered, so any calls to .to(), .to_empty(), .cpu(), .cuda(), .xpu(), .ipu(), or .apply() will not automatically apply to CQT kernels constructed later. As far as I can see, you have the following choices:

1. Override all these methods to update self.device. The main downside here is that you will take on the maintenance cost of staying up to date with any future API changes to nn.Module
2. Override .apply() and store all function pointers on the instance, then apply them in sequence to every new CQT instance that is constructed. Depending on what is passed to apply, this could be quite brittle. e.g. applying any function that relies on external state.
3. Create a dummy buffer on DataProcessor, and use this to track device changes. This is a bit hacky, but it will let you keep lazy initialisation.
4. Specify sample rate on construction, immediately registering CQT kernel buffers on the module. IMO this is most idiomatic solution, but of course it comes at the expense of lazy initialisation.

To me, it's not totally clear what is gained by lazy initialisation of the CQT, so 4 makes most sense. But if lazy init is essential then 3 is probably the solution that is least likely to require further maintenance.

[aRI0U]

I'll probably go for solution 3, I want my code to be as lazy as me