I agree with Jon and I think folks who are talking about tech debts in
Reaper should elaborate with examples about these tech debts. Can we be
more precise and list them down? I see it spread out over this long email
thread!!
On Sun, Sep 9, 2018 at 6:29 AM Elliott Sims wrote:
> A big one to add
A big one to add to your list there, IMO as a user:
* API for determining detailed repair state (and history?). Essentially,
something beyond just "Is some sort of repair running?" so that tools like
Reaper can parallelize better.
On Sun, Sep 9, 2018 at 8:30 AM, Stefan Podkowinski wrote:
> Does
Does it have to be a single project with functionality provided by
multiple plugins? Designing a plugin API at this point seems to be a bit
early and comes with additional complexity around managing plugins in
general.
I was more thinking into the direction of: "what can we do to enable
people to
It's interesting to me that someone would consider features of Reaper as
"technical debt"... an odd way to word it. When we had proposed donating
Reaper to the project, I had made the assumption people would realize the
benefit of folding in a successful project. A working codebase with a
large u
