2 ms·

There were a bunch of minor versions between 3.0 and 4.0 made up of fundamental refactor work to establish separation of concerns. As I understand it from the c

There were a bunch of minor versions between 3.0 and 4.0 made up of fundamental refactor work to establish separation of concerns. As I understand it from the call graphs he shared, the problem was that the UI was reaching deep into the audio code directly instead of using a clear API boundary to separate concerns and route commands and change state. So fundamentally while the UI worked, it also was deeply entwined with the audio engine and changing any of the audio back-end basically broke things downstream in unexpected places and couldn't be swapped without deep UI work anyway. So, if you're going to have to rewrite your UI layer to disentangle it from your back-end anyway why not also bring it up to speed? Let me repeat that to be clearer: The UI had to be changed internally in fundamental ways to do any work on the audio back-end and they chose to also uplift the design and UX while making it easier to replace the audio engine in a future commit.

boomlinde 29d ago
> So, if you're going to have to rewrite your UI layer to disentangle it from your back-end anyway why not also bring it up to speed? So, if you're going to have to rewrite your back-end to disentangle it from your UI layer anyway why not also bring it up to speed?
- Sammi 29d ago
  Because they have 10 people working on it and they can't boil the ocean with that kinds of resources. If you try to do all the things at once, then you get nothing actually to the finish line. You'll be getting what you want in the next point release.
  - boomlinde 29d ago
    So, as I said, a matter of priorities.
- TehCorwiz 29d ago
  I don't think you understand the problem they were facing. If they rewrite the backend it would also REQUIRE rewriting the frontend because of how entangled they were. Whereas rewriting the frontend did not require changing the backend as dramatically. So their choices were: 1. Rewrite the whole thing, all at once, ship nothing for a long time. 2. Rewrite the frontend, ship changes incrementally, then move onto the backend once it's been excised from the tangled mess.

boomlinde 29d ago

> So, if you're going to have to rewrite your UI layer to disentangle it from your back-end anyway why not also bring it up to speed? So, if you're going to have to rewrite your back-end to disentangle it from your UI layer anyway why not also bring it up to speed?

Sammi 29d ago
Because they have 10 people working on it and they can't boil the ocean with that kinds of resources. If you try to do all the things at once, then you get nothing actually to the finish line. You'll be getting what you want in the next point release.
- boomlinde 29d ago
  So, as I said, a matter of priorities.
TehCorwiz 29d ago
I don't think you understand the problem they were facing. If they rewrite the backend it would also REQUIRE rewriting the frontend because of how entangled they were. Whereas rewriting the frontend did not require changing the backend as dramatically. So their choices were: 1. Rewrite the whole thing, all at once, ship nothing for a long time. 2. Rewrite the frontend, ship changes incrementally, then move onto the backend once it's been excised from the tangled mess.