Compile latency woes
Captain's Log: Stardate 77725
I'm very happy to have finished the large refactoring of the data model implementation today. Now that it's done, it seems ridiculous that I didn't do it earlier. It was a lot of work, but not as much as I expected. But things are much simpler and clearer, code sharing is done via simple templates instead of insane macros, and I also found and fixed a few bugs as a result of moving things around. One thing I noticed is that I don't have good fuzz tests for the copy + paste implementation -- a bug surfaced that would have easily been caught by one. So that's something I've added to the todo list.
The really nice outcome though is that now it's fairly obvious how to approach the MIDI parameter routing in a clean way. I still have a few decisions to make around how that's going to work, but the design is way less complicated now.
The only thing that I did not manage to resolve is an issue around compile time. There's a central header "model.h" that gets used in a zillion places, because it's the main API for the data model. Changing model.h causes a zillion files to be recompiled. That's fairly OK, because it doesn't change all that much. But the problem is that it includes headers for all of the entity types (body, sensor, exciter, modulator, link, etc). So any change to ANY of those headers results in a big recompilation.
I tried to fix this with the "pimpl" strategy today, and it's definitely doable insofar as the model code is concerned, and would help a lot. But I ran into problems with the {fmt} library. It seems quite difficult to write custom {fmt} formatters that depend only on incomplete types. In one bug thread on the {fmt} site, someone asked about this and the reply was "c++20 modules will fix it." Which is true, modules will be awesome. But AFAICT they're not /really/ supported on Mac yet so that's a no-go. I might just punt on this issue for now.