Hanna Chmeruk

> Ideally, all of that would be tucked away in the base classes. I do not know the codebase well enough to oversee all implications. Not sure what the current...

I added TimeData as a data type for the parameter `signal`, so the `time_crop` function has had some changes, and there are also some significant changes in `test_dsp.py` . Therefore,...

> Thanks for implementing the changes. In terms of the actual code, this looks ready to me. > > I have two general design thoughts though: > > 1. Intuitively,...

> Your are right in that it's pretty late for structure changes like this, though the thought only came to me now that I saw the different examples in practice......

_PyfarBase is the abstract parent class for _Audio, Coordinates (Orientations, etc.). _NumpyLike, _PyfarArithmetics, _PyfarComplex are mixin classes. Proposal regarding dependencies: class _Audio(_PyfarBase, _NumpyLike, _PyfarArithmetics, _PyfarComplex): ... class _Coordinates(_PyfarBase, _NumpyLike, _PyfarArithmetics):...

> Thanks finalizing this! > > * Please check the reason for the failing tests, I think this may have to do with obsolete test filtes. > > * I...

Thank you for noticing! Unfortunately, during implementation, I didn't realise that the number of exact frequencies for the same range should match the number of nominal frequencies. The problem is...

> the methods should not depend on each other, due to maintinaing issues. this can be also achived to always allow +/- 1% derivation for the frequency range. eg. `frequency_range...

Of course, we will only implement this for octave-band and one-third-octave-band, but there are still almost endless possibilities for what frequency ranges users can enter. And I agree that `frequency_range=(12.6,...

In the weekly meeting, we decided to use the calculation of the nominal frequencies as a mask so that the exact frequencies do not exceed the range and also definitely...