Closed Be-ing closed 3 years ago
WX sucks, Qt has some licensing problems, people aren't fans of GTK. Nothing's perfect. Can someone more familiar with the codebase let us know how closely coupled the core recording engine and the interface layer are? Because it might be worthwhile tearing a page from neovim's book and separating the core and UI layer, which would have some serious advantages if porting to a new interface toolkit came up in the future, a downstream wanted a more native experience, or we wanted to link against something like flutter and put a pleasant multi track recorder on mobile phones, which would be pretty useful for me because I currently use the camera app on mine to record most of my audio.
wxWidgets is fairly tightly coupled into the codebase. Most Tenacity source files have includes and references to wxWidgets APIs. Reworking the whole thing to split it into two like Neovim did would be a huge effort in its own. Neovim had the benefit of the GUI being an ugly add-on to the thing, whereas Tenacity was built around the GUI.
That sounds pretty yuck, and kind of rules out an immediate Qt port. However, I think rearchitecting the software to excise that kind of vintage nastiness over time would be a good plan. Is there anything else in there that's grot? It was started back when undocumented plugin APIs were still in fashion.
edit: yep, in addition to standard audio plugins there is indeed an undocumented module API https://wiki.audacityteam.org/wiki/Modular_Architecture_Initiative
Is there anything else in there that's grot?
We keep discovering more and more. https://github.com/audacity/audacity/issues/840 https://github.com/audacity/audacity/issues/871 https://github.com/tenacityteam/tenacity/pull/228#discussion_r668367887
I've seen PaUtil_GetTime missing crashes on some of my computers so some of that mess is already falling apart downstream. Re-read your posts in this thread. It's like all of the tooling is busted and I don't know how anyone thought that's how you vendor in dependencies. Mad respect for your work so far.
(edit: the crashes were in builds of upstream Audacity)
Are you intending to continue developing new features on this fork or just make rebranded builds without tracking? This code base is in awful shape, for example consider: https://github.com/audacity/audacity/issues/840 https://github.com/audacity/audacity/issues/871 https://github.com/audacity/audacity/issues/625
It would take a lot of work to make it maintainable long term. The linked issues above are likely just the tip of the iceberg considering the attitudes of the old developers required to create those situations in the first place.