Idea: Functional programming instead of lookup table

[Mrugalla]

I wanna know your opinion on the following idea:

What if instead of filling a table of 128 frequencies, the MTS-ESP master requires the developer to implement two std::function<double(double)> where one of them converts pitch to freq and the other one freq to pitch. the downside of this approach would be that it would perform slightly worse, because it's std::function and it always has to calculate things instead of just reading from a table. (people could still just use an array and just reference it in their functions or use an approximation function, tho so it's fine) but the good thing about it is, that there could be non-integer in- and outputs of those functions and they would all be absolutely correct without any need for interpolation, which is really useful. we could be like "what's at pitch 12.5?" or "which pitch is at 420hz?" directly.

[Xenakios]

I can see a couple of problems with this :

• std::function is a C++ class, but MTS-ESP needs to be able to interoperate with plain C. This could be worked around by using C function pointers, though, I guess, if it wasn't for :
• MTS-ESP needs to be able to work across process boundaries (shared memory) and I can imagine it would be difficult (even impossible?) to implement any kind of straight forward callback function system in that scenario. The existing table based solution seems like the sensible thing to do.

[olicash]

Agree with the thoughts above, this would indeed make IPC more complicated. I wouldn't want to impose the use of std::function in the process thread, function pointers would be preferable. I'm also not sure how this guarantees there will be no need for interpolation. Take our free MTS-ESP Mini plug-in, which can parse a TUN or Scala file and populate an array from it. If you query with a floating point value, the plug-in would still have to perform interpolation to calculate the return value.

[Mrugalla]

if the tuning system was defined by a function we could also look for values in between the notes of the tuning system without having to interpolate and "guess" the value. it's just much cleaner. like when the tuning system is defined by the typical 2^((n-69)/12)*440 term, and we are looking for the frequency at the pitch 2.43467, we could go into it with n==2 and n==3 and then interpolate between those in various ways, but we could also just directly plug the number into the term and get the exact frequency that represents that pitch. if there are tuning systems where that wouldn't work or make sense, they could still internally use a frequency table and just reference it in their functions