make tuning frequency customizable in midi_to_hz() function

Description

Make midi_to_hz() accept a custom tuning frequency. Currently, 440.0 is hard coded.

I think it would be nice to have midi_to_hz() accept a different tuning frequency. That way, it would be easy to generate frequencies for notes following that tuning, etc.

I.e., turn midi_to_hz(notes) to midi_to_hz(notes, A4=440.0).

And change:

return 440.0 * (2.0 ** ((np.asanyarray(notes) - 69.0)/12.0))

to:

return A4 * (2.0 ** ((np.asanyarray(notes) - 69.0)/12.0)).

(I am not sure whether librosa has “agreed upon” a note naming convention for tuning. Is C4 the middle C (261 Hz in equal temperament) in librosa? I think so.)

Code here: https://librosa.github.io/librosa/_modules/librosa/core/time_frequency.html#midi_to_hz

The change would add the the functionality of choosing tuning frequency to other functions that depend on midi_to_hz() as well, such as note_to_hz(): https://librosa.github.io/librosa/_modules/librosa/core/time_frequency.html#note_to_hz

I can write a PR if this seems helpful.

Thanks and BR!

[bmcfee]

Thanks @jlw365 !

* Do you want to wait on adding a `units` parameter of sorts in additional methods as discussed [here](https://github.com/librosa/librosa/issues/977#issuecomment-525722692) then?

Yeah, let’s hold off on that one, since it might require a good amount of integration and auditing to make sure it’s consistently implemented across the package. I think for now, manually converting ref to tuning is totally fine. Anyone that wants to use ref pitches instead can afford the extra line of code to convert. 😁

* Confirming that these would be added to the core [time_frequency module](https://librosa.github.io/librosa/_modules/librosa/core/time_frequency.html), with unit tests in the respective location, and not in general [utils](https://librosa.github.io/librosa/util.html)?

Yup, these would fit in with all the other unit conversions.

* Thoughts on naming them `ref_pitch_to_tuning` and `tuning_to_ref_pitch`?

How about A4_to_tuning (and vice versa)? ref_pitch is a bit wordy, and might not be precise enough for readers to directly grok from skimming the documentation. A440_to_tuning would be good because A440 is more descriptive than “reference pitch”, but bad because if the input was actually 440, we wouldn’t be calling the function at all. A4_to_tuning allows for any frequency corresponding to A4, but I think most readers looking for this kind of function would immediately understand what it is.

I’m open to other suggestions though! Maybe we can go with this, and punt further discussion to code review?

[juliawilkins]

Hi @bmcfee, would be happy to take this issue on. Just wanted to confirm a few things based on the above discussion:

• For this initial PR, based on your recent comment, sounds like you’d like to start by adding the two ref-pitch to tuning conversion util methods described above. Do you want to wait on adding a units parameter of sorts in additional methods as discussed here then?
• Confirming that these would be added to the core time_frequency module, with unit tests in the respective location, and not in general utils?
• Thoughts on naming them ref_pitch_to_tuning and tuning_to_ref_pitch?

Thanks!