- But they didn't instead jumped on the industry trend of developing and launching their own plug-in platform. Now they are a software house and a sample library developer.
In some sense, they're a software company first, sample company second: if the software doesn't work, the quality of the samples is irrelevant.
Due to the nature of our industry they have to develop and support this software on multiple computer platforms (PC and Mac), operation system versions, plug-in versions (AU, VST etc.), DAWs and DAW versions. In every combination possible. That is a large testing surface.
It shouldn't be that bad in practice: the point of the VST and AU specs is to allow plugin developers to ignore specific DAWs, and there are frameworks that wrap up these details along with various other quirks. As long as the developer sticks to the framework's rules, they should be able to lean fairly heavily on the framework's own testing for the combinatorial stuff. This only works, though, if the plugin is regularly updated and released with the latest frameworks, since that's what will (hopefully!) ensure it stays compatible with the latest DAWs and OSes. If your build, test and deployment process is slow and cumbersome, that won't happen. I wondered if that was the issue re: MacOS Ventura compatibility. Ventura was released on Oct 2022, but SA still won't support plugins on that version.
If they are a wise software development house then they will have a single code base for all of their plug-ins. From what I've seen I'm not sure this is the case. I suspect they have multiple versions of their plug-in for each library
Definitely looks like the code was forked per-product, but what's certain is that updated builds of each product are released so rarely that they might as well be separate code-bases.
EW have the right idea if you are producing your own plug-in - have a single version that all of your libraries use.
Unfortunately, I think SA have painted themselves into a corner. Unless you start by ensuring all your products use the same parameters, controls, mappings, etc (and gracefully ignore those that don't apply) then you can never unify those plugins without breaking existing projects. They've been very casual about that this week, but that *should* be unacceptable to them. Assuming they come round to this idea, they'd essentially have to start again: release a new multi-product plugin with unified mappings for their whole catalogue, then start migrating products into it: that'd let users update their projects as/when they want a new feature, but without any uncommanded breaking updates.
I don't know first-hand, but sounds like SA did have standardised mappings across their Kontakt products?
They probably are using a lot on automated unit testing of their code, which is certainly a good thing, but given the size of their testing surface they may be relying on it too much at the expense of hands-on functional QA. This means that usability bugs (such as this CC mapping issue) are more likely.
This sounds optimistic to me. The most rudimentary smoke test I can think of for an audio plugin is to load it into an AU/VST test harness and make sure the info it gives to the host hasn't changed unexpectedly. The latest release would not have passed that test, and nor would the release that broke preset recall in 2021... and this is before we do anything crazy like testing inputs and outputs! The CC mapping issue is also eminently automatable: request "Mix 1" parameter value, send new value on MIDI CC#21, request "Mix 1" again and check it has new value. Done.
Of course the more products they launch the harder this all gets, and future revenue needed to support the size of this growing business means that they have to develop new libraries. So I wonder how much pressure the sales and marketing teams are putting on development to get stuff out by a certain date, and I wonder how much the dev teams are struggling to do this at the right quality with the constraints of recruitment, training, tech-debt, testing surfaces and multiple codebases plaguing them.
I'm turning the speculation knob up to 11, but I think the way you phrased this says a lot: "...pressure the sales and marketing teams are putting on development..." as opposed to senior management being the single source of pressure on -- or, ideally, a discussion of reasons with -- teams that are behind schedule. In many companies that have started their own software development, CEOs/Boards seem to just "let it happen", rather than paying attention to it as a critical part of their business. (Until it goes wrong, anyway, whereupon they may just go unproductively bonkers.) It can be miserable for the tech people, who generally like solving problems but can't get the direction, attention and resources they need just to avoid incidents.
[With apologies, Wayne, where I've said stuff you certainly already know: I just wanted to allow others to get the full stultifying experience of my frustrated ramblings
]