Frequency Bands can be defined in terms of band edges

[kkappler]

This should be done before either #47 or #67. It is the general use case and needs to be made to work with emtf band setup configuration (the current default). Infact, we should also fix issue #134 first as well.

Once that is running, want to allow user to simply request a number of bands per decade or bands per octave as a default, normally done in log-space, i.e. band edges form a geometric series.
e.g. band_edges: 1-2, 2-4, 4-8, 8-16, ...

[kkappler]

Band edges would normally be created with some knowledge of:

1. Data sample rate (at each decimation) 1/dt
2. Time series window length (at each decimation) N
   which means that we know df = 1 / (N*dt) after STFT, 0..df..f_Nyq = f_sps/2

Band edge selection should be done via a UI that shows the user where the FCs are located on the frequency axis, and allows binning with a selection tool, or according to a standard (log-spaced) method of generating a frequency axis. Note that such methods often yield some empty bands at lower frequencies due to the initial slow growth of the geometric series of band edges and the sparseness of the FCs. How to handle this not 100% clear yet.

We will not allow the DC component into the analysis. Setting the lower bound of the interval to 0 should be treated as setting it to be df/2.

In any case, assuming you had a set of reasonable band edges that you pass in, would we want to "tidy them up" to use df/2 edges? I think yes, provided we were not going to change decimation factor (which would change sample_rate, and thus df), or window length, which would change N and thus df.

This suggests a flow:

1. First choose # of decimation levels and decimation factors
2. Then choose window length,
3. Then specify bands

Next step

• print the band edges that are assigned from the EMTF band setup file
• try putting those into the config

It turns out that while trying to do this, we are going to have to support more kwargs in config creator. This means it is a good idea to review the two methods of ConfigCreator:

1. create_from_kernel_dataset
2. create_run_processing_object

At a minimum, these methods could be consolidated by making them both instances of a common _create method, but after studying the code, a better solution is:

• deprecate create_run_processing_object method of ConfigCreator in favour of create_from_kernel_dataset
• deprecate create_run_processing_object in ipynbs as well (docs/examples/operate_aurora.ipynb, docs/examples/config_example.ipynb:31, tutorials/processing_configuration.ipynb

OK. After much tidying, am able to pass the band edges into ConfigCreator in the correct place.

Here is the rub:
The user can pass any band edges they want, but I would prefer to keep the canonical edges, which are basically the edges associated with the df/2 band edges, as described in frequency_band.py. So I can either

A. Force the user to use canonical edges, and thus alter the edges they provide
B. Give the user what they asked for.

This makes me want to define a parameter band_edge_definition = ["exact", "canonical"]

Note that in either case, I need to identify the in-band fc harmonic indices within each user-defined-band, whether they map to the canonical band or not. Knowledge of the fc harmonic indices depends on knowing sample_rate and samples_per_window.

OK, basic functionality has been shown. Things to do:

• Instead of using manual text dumps of band definitions, access them programatically in test_define_frequency_bands.py

Also, the emtf_band_setup file is independent of the frequency values, although the frequencies are well defined in Processing class. If I define the frequencies at each decimation level at the start of the config creation, then the frequency bounds can be added to Bands object.

• Add frequency information to Bands object when using emtf band setup
• clean up deprecated methods
• Add a placeholder in config to tell how bands were specified (emtf_file or band edges)
• Add a placeholder for the emtf band_setup file path, or at least it's contents when it is the band definition
• Tidy up deprecated functions

[kkappler]

This is looking pretty good. Bands can be set from either an emtf band_setup_file or via a dictionary of band edges.

In future we may want to address the addition of a band_edge_definition = ["exact", "canonical"] in the config. I put a note in issue #47 about this