> what you think about using an external tool for compiling the const tables, > like Python. [...] The tool will be searched by cmake with REQUIRED option
I don't want to compel people to require yet another build dependency. While we have very good reasons to make glib a dependency, making e.g. python a dependency seems questionable as the current runtime solution works flawlessly for 99% of all users. Carlo initially brought this idea up, in order to allow fluidsynth to run on very ressource limited hardware. I still support this and tried to find a solution that allows potentially more users to benefit from this... it turned out a little more complicated than I thought. Personally I prefer the current C90 compliant solution that relies on the preprocessor (#423). The only significant drawback of this approach I see is that it does not allow to make *all* lookup tables "constexpr". Namely all tables that use pow(). As for pow() one needs a recursion, which the preprocessor is lacking. If this is a problem (dont know, pls. tell me), I would vote for falling back to Marcus proposal and VC those autogenerated files generated by an external (upstream exclusive) tool. Yes one shouldn't do that, but watching the prior github discussion, we don't have any better alternatives currently; and yes, the lookup tables are (partly) given by the sf2 spec and very unlikely to ever receive a different implementation (i.e. values). In this case I'd vote for using Carlo's C tool... not python. Tom _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
