Working towards pyclarity 1.0

[groadabike]

Pyclarity has been coded in a bottom-up fashion driven by the challenges and their recipes. I.e., we define the recipe for challenge baselines and then we implement what we need in the library. Over time, some code started to overlap (re-implementation) or is necessarily recipe-dependant and very unlikely to be used in future challenges: reusable code and recipe-specific code is not always cleanly separated.

We now need to take a step back and reimplement some parts of the library in a more structured way.
The following list is not complete

• Common variable names
  • Sample rate.
  • in and out file/signals names
• Intrusive Metrics - All intrusive metrics take a reference and a processed signal as inputs. They could implement from an abstract class.
  • HAAQI Add precomputations to HAAQI #363
  • HASPI
  • HASQI
  • MBSTOI
• Ear Model
  • From HAAQI Add precomputations to HAAQI #363
  • From MSBG
• Audiograms - this exists as an audiogram class but is not being used consistently in the code base #277
• Recipes - We could create an abstract class with common methods (e.g., iterate over scenes) and others that must be implemented (enhancement of one scene).
  • Result File Class
  • .....