Yes, obviously every good library code needs testing, and autotests is a great answer to check regressions continuously (provided the tests cover enough corner cases of the library). There is a problem here: nearly every usage of the library involves adding the ROMs, except some pieces of support code. Indeed, we may create a ton of semi-useless tests, e.g. with CUnit and claim we have tests, but I doubt it is a good answer. Perhaps, some parts of the core functionality can be successfully tested with "mock ROMs", however creating these isn't straightforward. Hence, no autotests for mt32emu so far, I'm quite satisfied with end-to-end testing I have now. From start, we planned to use mt32emu-smf2wav to produce a set of waveforms from reference MIDI files and compare them with the reference samples.

But I see no problem with the brew crew insisting on autotests for every formula. AFAIK, they are fine with supporting custom taps, so we might create one on our own. It would contain not only the library but perhaps, mt32emu-smf2wav and mt32emu-qt casks, wdyt?

Yeah, as I wrote, I needed a bit to "get it".

Yes, it's probably easy enough to get a tap for all three going.

https://github.com/Homebrew/homebrew-core/pul … mment-982501133 <- finally it got accepted into brew. But only when the pull request was done by insiders. The same people that told me that a mere version test is not sufficient just added it with exactly that.
So while I understood the reasoning earlier this year and accepted this decision as justified, I'm now a bit grumpy that they accepted it now that someone decided that they need munt after all 😀

Yes, this is how it always works in our world, sadly.

Still, adding a bit of autotests is a good idea, and I hope I'll be able to find time for that next year 😀

yeah, in the long run this would be nice to have 😀

(still feel very grumpy about this brew devs behavior, even though the end result should justify the means)