Hacker News Reader

Comment by TehCorwiz | Hacker News Reader

If you watch the admittedly long video from Tantacrul about what it took to get from 3.0 to 4.0 he talks about that. They had a lot of tech debt that made it impossible to update the audio engine. He talked about the new engine being the roadmap for 4.1.

View on HN

I saw the Tantacrul video back when it was released. I think that's when I went ahead and bought myself a personal Reaper license. My thought then was: wtf are their priorities like if they'll focus on a complete overhaul of the admittedly basic but functional interface over broken recording and playback of audio?

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.

> 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?

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.

So, as I said, a matter of priorities.

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.

I think you may be underestimating how crucial a good User Interface is for widespread adoption of a product..

I think you may be underestimating how important playing back and recording audio is for an application built for that purpose.

This was already a widely adopted piece of software. It was my go-to for light audio work like trimming a sample, for being free and easy to use for exactly that.

Reply on news.ycombinator.com