Re: [Rosegarden-devel] So long and thanks for all the FOSS
On 2022-11-29 07:33:53 Richard Bown wrote: > So this will still get upstream changes to merge? Yes, it's my intention to merge upstream commits from master as time and motivation permit. (See the "no warranty" disclaimers in the "COPYING" license file.) Or at least until the code divergence makes doing so impossible. And of course I won't be merging any conflicting designs/implementations of the same feature (e.g. looping). Right now I'm waiting to see how 22.12 shakes out, as the MIDI file merge patches seem to address longstanding, non-critical issues. On 2022-11-30 03:54:14 Ted Felix wrote: > I'm planning on having a look in January after the 22.12 release > and the holidays. It's 21,000 lines of changes, though, so it's > going to take years for me to review and test all of it. Until that > process begins, I can't provide useful or helpful feedback. Thanks, Ted. If and whenever you get to it, I'd be very interested in your feedback, regardless whether you merge any of the code or not. As I've said many time before, I completely respect that Rosegarden is yours to steer in whatever direction you see fit. Just for the record, I will note that I didn't dump 21K+ lines of code on you all at once -- that figure represents the cumulative count of pending merge requests I've been submitting since March of this year (https://sourceforge.net/p/rosegarden/git/merge-requests/). And as for "years ... to review and test", that's all the more reason for the fork to exist as an alternate/experimental release. Maybe if it gets some use and testing (and fixes!) that will aid your eventual review of it. On 2022-11-30 12:09:32 Philip Leishman wrote: > That sound good. But 21k lines makes things difficult. > ... > It seems that Mark put all his changes in one branch. I think this is > part of the problem. As an example see feature request 508 for the > marker ruler - I think these are valuable changes which should be > merged into rosegarden but the feature is combined with a lot of > code in the matrix editor which may (or may not) be good! Two points: First, the branch's history and the merge requests are somewhat linear, although not completely so (fixes/changes to earlier commits appear in later ones). So it would be at least theoretically possible to review and merge them one at a time without tackling the entire 21K LOC at once. Note also that the branch's commit messages contain very complete documentation about what is included in each one. Second, Ted -- if not actually encouraging me -- seemed to be OK with the single/cumulative branch: On 2022-04-07 12:52:07 Ted Felix wrote: > And that's fine. Since you are working this way, you should > probably drop the multiple branches and merge requests and just > work in a "mark" branch. I can follow along with that and bring > it over into the official rosegarden repo to make it easier > for everyone to test as well. > The bug/feature request numbers in the commit messages tell > the whole story. A single branch seems like it's more your style, so > that should be more productive for you. It's up to you. I can > handle whatever is thrown at me git-wise. (https://sourceforge.net/p/rosegarden/mailman/message/37636847/) Maybe he's changed his mind. Possibly because he didn't anticipate me taking things this far. ;) Regardless, I can't break out the individual features/merges into independent, standalone commits. For a long time I tried to make as few changes to the codebase (my original plan was to touch nothing outside of the src/gui/matrix/editor directory) as I could while implementing the features. Eventually that became impossible -- there's just too much in the core code that needs refactoring/redesign (I'm being critical, sorry) for which I've made minor/incremental fixes. Each new commit built on the previous one(s) because creating (and testing) an MxN matrix of commits -- features rows vs internal utilities columns -- was out of the question. Again, my expectation was that each merge request would be evaluated/accepted/rejected/modified before the next one, which in turn would factor in the outcome of the previous. On 2022-11-30 12:09:32 Philip Leishman wrote: > Rosegarden has a large user base so taking in new code is always > difficult - checking that the user is not going to get surprised by > something. This post is getting too long (as is usual with me) and I'm now going slightly off-topic, but I dispute both points. First, the "large user base" (my criterion is serious users, those who spend multiple hours per week using the software), but more importantly that a large percentage if not the majority of them will always categorically reject any changes whatsoever to the UI or the workflows, regardless if those changes are improvements. I'm willing to defend these statements to anyone who's interested, but since that's probably nobody and it doesn't matter anyway -- there's "real" R
Re: [Rosegarden-devel] So long and thanks for all the FOSS
Hi there again!
Thank you very much for the several answers I got. I see clearer now and
understand the proceedings better.
Greetings,
Michael
==
Gesendet: Mittwoch, 30. November 2022 um 13:09 Uhr
Von: "Philip Leishman"
An: rosegarden-devel@lists.sourceforge.net
Betreff: Re: [Rosegarden-devel] So long and thanks for all the FOSS
That sound good. But 21k lines makes things difficult.
Rosegarden has a large user base so taking in new code is always
difficult - checking that the user is not going to get surprised by
something. So merging 21k lines of code is pretty much impossible.
It seems that Mark put all his changes in one branch. I think this is
part of the problem. As an example see feature request 508 for the
marker ruler - I think these are valuable changes which should be merged
into rosegarden but the feature is combined with a lot of code in the
matrix editor which may (or may not) be good!
I hoped Mark would make a fresh branch from master and put the marker
ruler code in there.
Merging isolated changes from different branches makes things a lot easier.
Philip
On 11/30/22 04:53, Ted Felix wrote:
> I'm planning on having a look in January after the 22.12 release and
> the holidays. It's 21,000 lines of changes, though, so it's going to
> take years for me to review and test all of it. Until that process
> begins, I can't provide useful or helpful feedback.
>
> I'm focused on testing the 22.12 release right now.
>
> Ted.
>
> On 11/28/22 1:59 AM, MST wrote:
>> Hi there!
>> Just out of curiosity, why doesn't here any discussion or reaction
>> take place. Apparently mark got frustrated being given no feedback on
>> his contributions. Can anybody enlighten me please?
>> Greetings,
>> Michael
>> *Gesendet:* Mittwoch, 16. November 2022 um 10:31 Uhr
>> *Von:* "mark_at_yahoo via Rosegarden-devel"
>>
>> *An:* rosegarden-devel@lists.sourceforge.net
>> *Betreff:* [Rosegarden-devel] So long and thanks for all the FOSS
>> This post is intended as a courtesy notification to any who may be
>> interested. If not or nobody, I apologize for the waste of time and
>> bandwidth.
>>
>> I have released an independent fork of Rosegarden at
>> https://github.com/thanks4opensource/rosegarden-fork/
>> <https://github.com/thanks4opensource/rosegarden-fork/[https://github.com/thanks4opensource/rosegarden-fork/]>.
>> This is
>> compliant
>> with Rosegarden's license ("COPYING").
>>
>> Note that forking the project was not my first (or Nth) preference. I
>> believe that forks are in general bad for open source software as they
>> increase the FUD factor put forth by proprietary/closed-source vendors.
>> ("You use Rosegarden? Which version? See, that's why you don't want to
>> get locked into open source software!")
>>
>> The fork is also bad for me personally. When I first considered working
>> on the Rosegarden sources I was elated to find that the project was
>> actively being maintained and developed. (Also surprised, given the
>> prevalence of open source "abandonware", and then even more so when I
>> learned how far back Rosegarden's history goes.) My hope, and frankly
>> expectation, was that my contributions -- initially small, but which
>> grew in size and scope -- would be incorporated into the codebase,
>> hopefully with collaborative back-and-forth improvements. And that
>> eventually, as the release schedule progressed and distributions picked
>> up the latest version, I could delete my own development branches and
>> simply use distro binaries.
>>
>> But it has become increasingly clear that my merge requests aren't going
>> to be accepted into the Rosegarden mainstream, at least not in any
>> timely fashion and probably not ever. I have invested far too much time
>> and effort (currently 20x my original estimate) (and Rosegarden is very
>> much a sideline to my main open source work) to relegate it solely to my
>> own private use. I believe the fixes and new features I've added
>> represent worthwhile improvements that others could benefit from. Time
>> may or may not tell.
>>
>> On an even more personal note, in retrospect I regret having chosen this
>> development path. I had thought I could "hack in" two minor changes: The
>> one bug and one feature I originally posted about, i.e. MIDI input
>> playing the current editor's active segment's instrument, and key-aware
>> matrix editor highlighting. But at each step in a long chain of
>> deve
Re: [Rosegarden-devel] So long and thanks for all the FOSS
That sound good. But 21k lines makes things difficult.
Rosegarden has a large user base so taking in new code is always
difficult - checking that the user is not going to get surprised by
something. So merging 21k lines of code is pretty much impossible.
It seems that Mark put all his changes in one branch. I think this is
part of the problem. As an example see feature request 508 for the
marker ruler - I think these are valuable changes which should be merged
into rosegarden but the feature is combined with a lot of code in the
matrix editor which may (or may not) be good!
I hoped Mark would make a fresh branch from master and put the marker
ruler code in there.
Merging isolated changes from different branches makes things a lot easier.
Philip
On 11/30/22 04:53, Ted Felix wrote:
I'm planning on having a look in January after the 22.12 release and
the holidays. It's 21,000 lines of changes, though, so it's going to
take years for me to review and test all of it. Until that process
begins, I can't provide useful or helpful feedback.
I'm focused on testing the 22.12 release right now.
Ted.
On 11/28/22 1:59 AM, MST wrote:
Hi there!
Just out of curiosity, why doesn't here any discussion or reaction
take place. Apparently mark got frustrated being given no feedback on
his contributions. Can anybody enlighten me please?
Greetings,
Michael
*Gesendet:* Mittwoch, 16. November 2022 um 10:31 Uhr
*Von:* "mark_at_yahoo via Rosegarden-devel"
*An:* rosegarden-devel@lists.sourceforge.net
*Betreff:* [Rosegarden-devel] So long and thanks for all the FOSS
This post is intended as a courtesy notification to any who may be
interested. If not or nobody, I apologize for the waste of time and
bandwidth.
I have released an independent fork of Rosegarden at
https://github.com/thanks4opensource/rosegarden-fork/
<https://github.com/thanks4opensource/rosegarden-fork/>. This is
compliant
with Rosegarden's license ("COPYING").
Note that forking the project was not my first (or Nth) preference. I
believe that forks are in general bad for open source software as they
increase the FUD factor put forth by proprietary/closed-source vendors.
("You use Rosegarden? Which version? See, that's why you don't want to
get locked into open source software!")
The fork is also bad for me personally. When I first considered working
on the Rosegarden sources I was elated to find that the project was
actively being maintained and developed. (Also surprised, given the
prevalence of open source "abandonware", and then even more so when I
learned how far back Rosegarden's history goes.) My hope, and frankly
expectation, was that my contributions -- initially small, but which
grew in size and scope -- would be incorporated into the codebase,
hopefully with collaborative back-and-forth improvements. And that
eventually, as the release schedule progressed and distributions picked
up the latest version, I could delete my own development branches and
simply use distro binaries.
But it has become increasingly clear that my merge requests aren't going
to be accepted into the Rosegarden mainstream, at least not in any
timely fashion and probably not ever. I have invested far too much time
and effort (currently 20x my original estimate) (and Rosegarden is very
much a sideline to my main open source work) to relegate it solely to my
own private use. I believe the fixes and new features I've added
represent worthwhile improvements that others could benefit from. Time
may or may not tell.
On an even more personal note, in retrospect I regret having chosen this
development path. I had thought I could "hack in" two minor changes: The
one bug and one feature I originally posted about, i.e. MIDI input
playing the current editor's active segment's instrument, and key-aware
matrix editor highlighting. But at each step in a long chain of
development I ran into further missing features that I needed for my own
Rosegarden use, and even more so internal architectural failings and
omissions that made implementing anything far more difficult than it
should have been.
I also realized in retrospect that I could have implemented a
matrix-editor-only application from scratch in far less time. As I once
posted to a bug report, I had previously written a primitive non-GUI
application with the basic algorithms and an ALSA MIDI back end. I
wouldn't have ended up with the myriad of other capabilities Rosegarden
provides, including the much more difficult to implement notation
editor, but as I personally only use notation for communicating with
tradition-bound friends, and could have always exported MIDI to
Rosegarden (or Musescore) for producing offline output, that wouldn't
have presented an insurmountable problem. "Live and learn", as the
saying goes. Or maybe more appropriately given Rosegarden's original
develo
Re: [Rosegarden-devel] So long and thanks for all the FOSS
I'm planning on having a look in January after the 22.12 release and
the holidays. It's 21,000 lines of changes, though, so it's going to
take years for me to review and test all of it. Until that process
begins, I can't provide useful or helpful feedback.
I'm focused on testing the 22.12 release right now.
Ted.
On 11/28/22 1:59 AM, MST wrote:
Hi there!
Just out of curiosity, why doesn't here any discussion or reaction take
place. Apparently mark got frustrated being given no feedback on his
contributions. Can anybody enlighten me please?
Greetings,
Michael
*Gesendet:* Mittwoch, 16. November 2022 um 10:31 Uhr
*Von:* "mark_at_yahoo via Rosegarden-devel"
*An:* rosegarden-devel@lists.sourceforge.net
*Betreff:* [Rosegarden-devel] So long and thanks for all the FOSS
This post is intended as a courtesy notification to any who may be
interested. If not or nobody, I apologize for the waste of time and
bandwidth.
I have released an independent fork of Rosegarden at
https://github.com/thanks4opensource/rosegarden-fork/
<https://github.com/thanks4opensource/rosegarden-fork/>. This is compliant
with Rosegarden's license ("COPYING").
Note that forking the project was not my first (or Nth) preference. I
believe that forks are in general bad for open source software as they
increase the FUD factor put forth by proprietary/closed-source vendors.
("You use Rosegarden? Which version? See, that's why you don't want to
get locked into open source software!")
The fork is also bad for me personally. When I first considered working
on the Rosegarden sources I was elated to find that the project was
actively being maintained and developed. (Also surprised, given the
prevalence of open source "abandonware", and then even more so when I
learned how far back Rosegarden's history goes.) My hope, and frankly
expectation, was that my contributions -- initially small, but which
grew in size and scope -- would be incorporated into the codebase,
hopefully with collaborative back-and-forth improvements. And that
eventually, as the release schedule progressed and distributions picked
up the latest version, I could delete my own development branches and
simply use distro binaries.
But it has become increasingly clear that my merge requests aren't going
to be accepted into the Rosegarden mainstream, at least not in any
timely fashion and probably not ever. I have invested far too much time
and effort (currently 20x my original estimate) (and Rosegarden is very
much a sideline to my main open source work) to relegate it solely to my
own private use. I believe the fixes and new features I've added
represent worthwhile improvements that others could benefit from. Time
may or may not tell.
On an even more personal note, in retrospect I regret having chosen this
development path. I had thought I could "hack in" two minor changes: The
one bug and one feature I originally posted about, i.e. MIDI input
playing the current editor's active segment's instrument, and key-aware
matrix editor highlighting. But at each step in a long chain of
development I ran into further missing features that I needed for my own
Rosegarden use, and even more so internal architectural failings and
omissions that made implementing anything far more difficult than it
should have been.
I also realized in retrospect that I could have implemented a
matrix-editor-only application from scratch in far less time. As I once
posted to a bug report, I had previously written a primitive non-GUI
application with the basic algorithms and an ALSA MIDI back end. I
wouldn't have ended up with the myriad of other capabilities Rosegarden
provides, including the much more difficult to implement notation
editor, but as I personally only use notation for communicating with
tradition-bound friends, and could have always exported MIDI to
Rosegarden (or Musescore) for producing offline output, that wouldn't
have presented an insurmountable problem. "Live and learn", as the
saying goes. Or maybe more appropriately given Rosegarden's original
developers, "In for a penny, in for a pound".
I hope this explains my motivations for forking Rosegarden (again, if
anyone is interested in them). As of now the fork still isolates its new
code in the separate thanks4opensrc_devel branch (with the exception of
a modified README.md file in master that clearly indicates the repo is a
non-official fork) although that may change in the future. I have one
more major feature planned, plus a raft of smaller ones, but currently
hope to slow my development on the project in order to return to the
other work mentioned above. I'm describing the branch structure on the
off-chance that there's any future interest in looking at parts of the
fork for potential inclusion in the official repository, either as code
or merely as ide
Re: [Rosegarden-devel] So long and thanks for all the FOSS
Looks like this fork is still downstream of the 'master' github repo from
ted. So this will still get upstream changes to merge? If so then that's
good. I've also forked Ted's repo to work on mac and windows ports (a bit,
occasionally) and not have it all gumming up the main github repo. Perhaps
one day I'll get something working which can be PR'd back to 'main' but
then perhaps not..
While any project would rather not see forks, it's also a sign of health in
some ways. I would prefer if we could 'all work together' of course but I
also get that if PRs are floating about and don't get merged or rejected or
even considered then it gets frustrating pretty quickly!
So I can see both sides and, for one, would like to congratulate all of
those who still do the good work on Rosegarden. Very proud that it still
continues to thrive.
Best,
Richard
On Mon, 28 Nov 2022 at 08:12, MST wrote:
> Hi there!
>
> Just out of curiosity, why doesn't here any discussion or reaction take
> place. Apparently mark got frustrated being given no feedback on his
> contributions. Can anybody enlighten me please?
>
> Greetings,
> Michael
>
>
> *Gesendet:* Mittwoch, 16. November 2022 um 10:31 Uhr
> *Von:* "mark_at_yahoo via Rosegarden-devel" <
> rosegarden-devel@lists.sourceforge.net>
> *An:* rosegarden-devel@lists.sourceforge.net
> *Betreff:* [Rosegarden-devel] So long and thanks for all the FOSS
> This post is intended as a courtesy notification to any who may be
> interested. If not or nobody, I apologize for the waste of time and
> bandwidth.
>
> I have released an independent fork of Rosegarden at
> https://github.com/thanks4opensource/rosegarden-fork/. This is compliant
> with Rosegarden's license ("COPYING").
>
> Note that forking the project was not my first (or Nth) preference. I
> believe that forks are in general bad for open source software as they
> increase the FUD factor put forth by proprietary/closed-source vendors.
> ("You use Rosegarden? Which version? See, that's why you don't want to
> get locked into open source software!")
>
> The fork is also bad for me personally. When I first considered working
> on the Rosegarden sources I was elated to find that the project was
> actively being maintained and developed. (Also surprised, given the
> prevalence of open source "abandonware", and then even more so when I
> learned how far back Rosegarden's history goes.) My hope, and frankly
> expectation, was that my contributions -- initially small, but which
> grew in size and scope -- would be incorporated into the codebase,
> hopefully with collaborative back-and-forth improvements. And that
> eventually, as the release schedule progressed and distributions picked
> up the latest version, I could delete my own development branches and
> simply use distro binaries.
>
> But it has become increasingly clear that my merge requests aren't going
> to be accepted into the Rosegarden mainstream, at least not in any
> timely fashion and probably not ever. I have invested far too much time
> and effort (currently 20x my original estimate) (and Rosegarden is very
> much a sideline to my main open source work) to relegate it solely to my
> own private use. I believe the fixes and new features I've added
> represent worthwhile improvements that others could benefit from. Time
> may or may not tell.
>
> On an even more personal note, in retrospect I regret having chosen this
> development path. I had thought I could "hack in" two minor changes: The
> one bug and one feature I originally posted about, i.e. MIDI input
> playing the current editor's active segment's instrument, and key-aware
> matrix editor highlighting. But at each step in a long chain of
> development I ran into further missing features that I needed for my own
> Rosegarden use, and even more so internal architectural failings and
> omissions that made implementing anything far more difficult than it
> should have been.
>
> I also realized in retrospect that I could have implemented a
> matrix-editor-only application from scratch in far less time. As I once
> posted to a bug report, I had previously written a primitive non-GUI
> application with the basic algorithms and an ALSA MIDI back end. I
> wouldn't have ended up with the myriad of other capabilities Rosegarden
> provides, including the much more difficult to implement notation
> editor, but as I personally only use notation for communicating with
> tradition-bound friends, and could have always exported MIDI to
> Rosegarden (or Musescore) for producing offline output, that wouldn't
> have presented an insurmountable pr
Re: [Rosegarden-devel] So long and thanks for all the FOSS
Hi there!
Just out of curiosity, why doesn't here any discussion or reaction take place. Apparently mark got frustrated being given no feedback on his contributions. Can anybody enlighten me please?
Greetings,
Michael
Gesendet: Mittwoch, 16. November 2022 um 10:31 Uhr
Von: "mark_at_yahoo via Rosegarden-devel"
An: rosegarden-devel@lists.sourceforge.net
Betreff: [Rosegarden-devel] So long and thanks for all the FOSS
This post is intended as a courtesy notification to any who may be
interested. If not or nobody, I apologize for the waste of time and
bandwidth.
I have released an independent fork of Rosegarden at
https://github.com/thanks4opensource/rosegarden-fork/. This is compliant
with Rosegarden's license ("COPYING").
Note that forking the project was not my first (or Nth) preference. I
believe that forks are in general bad for open source software as they
increase the FUD factor put forth by proprietary/closed-source vendors.
("You use Rosegarden? Which version? See, that's why you don't want to
get locked into open source software!")
The fork is also bad for me personally. When I first considered working
on the Rosegarden sources I was elated to find that the project was
actively being maintained and developed. (Also surprised, given the
prevalence of open source "abandonware", and then even more so when I
learned how far back Rosegarden's history goes.) My hope, and frankly
expectation, was that my contributions -- initially small, but which
grew in size and scope -- would be incorporated into the codebase,
hopefully with collaborative back-and-forth improvements. And that
eventually, as the release schedule progressed and distributions picked
up the latest version, I could delete my own development branches and
simply use distro binaries.
But it has become increasingly clear that my merge requests aren't going
to be accepted into the Rosegarden mainstream, at least not in any
timely fashion and probably not ever. I have invested far too much time
and effort (currently 20x my original estimate) (and Rosegarden is very
much a sideline to my main open source work) to relegate it solely to my
own private use. I believe the fixes and new features I've added
represent worthwhile improvements that others could benefit from. Time
may or may not tell.
On an even more personal note, in retrospect I regret having chosen this
development path. I had thought I could "hack in" two minor changes: The
one bug and one feature I originally posted about, i.e. MIDI input
playing the current editor's active segment's instrument, and key-aware
matrix editor highlighting. But at each step in a long chain of
development I ran into further missing features that I needed for my own
Rosegarden use, and even more so internal architectural failings and
omissions that made implementing anything far more difficult than it
should have been.
I also realized in retrospect that I could have implemented a
matrix-editor-only application from scratch in far less time. As I once
posted to a bug report, I had previously written a primitive non-GUI
application with the basic algorithms and an ALSA MIDI back end. I
wouldn't have ended up with the myriad of other capabilities Rosegarden
provides, including the much more difficult to implement notation
editor, but as I personally only use notation for communicating with
tradition-bound friends, and could have always exported MIDI to
Rosegarden (or Musescore) for producing offline output, that wouldn't
have presented an insurmountable problem. "Live and learn", as the
saying goes. Or maybe more appropriately given Rosegarden's original
developers, "In for a penny, in for a pound".
I hope this explains my motivations for forking Rosegarden (again, if
anyone is interested in them). As of now the fork still isolates its new
code in the separate thanks4opensrc_devel branch (with the exception of
a modified README.md file in master that clearly indicates the repo is a
non-official fork) although that may change in the future. I have one
more major feature planned, plus a raft of smaller ones, but currently
hope to slow my development on the project in order to return to the
other work mentioned above. I'm describing the branch structure on the
off-chance that there's any future interest in looking at parts of the
fork for potential inclusion in the official repository, either as code
or merely as ideas for independent/separate implementation. But note
that the branches have already diverged significantly (my last merge
with master [833ea5] was very difficult) and will likely continue to do
so. Of course my recommendation is that the forked branch be merged
wholly, as-is (git-merge "theirs), but I don't anticipate that happening. ;)
Finally, and as publicly stated in the fork's README.md, please accept
my appreciati
[Rosegarden-devel] So long and thanks for all the FOSS
This post is intended as a courtesy notification to any who may be
interested. If not or nobody, I apologize for the waste of time and
bandwidth.
I have released an independent fork of Rosegarden at
https://github.com/thanks4opensource/rosegarden-fork/. This is compliant
with Rosegarden's license ("COPYING").
Note that forking the project was not my first (or Nth) preference. I
believe that forks are in general bad for open source software as they
increase the FUD factor put forth by proprietary/closed-source vendors.
("You use Rosegarden? Which version? See, that's why you don't want to
get locked into open source software!")
The fork is also bad for me personally. When I first considered working
on the Rosegarden sources I was elated to find that the project was
actively being maintained and developed. (Also surprised, given the
prevalence of open source "abandonware", and then even more so when I
learned how far back Rosegarden's history goes.) My hope, and frankly
expectation, was that my contributions -- initially small, but which
grew in size and scope -- would be incorporated into the codebase,
hopefully with collaborative back-and-forth improvements. And that
eventually, as the release schedule progressed and distributions picked
up the latest version, I could delete my own development branches and
simply use distro binaries.
But it has become increasingly clear that my merge requests aren't going
to be accepted into the Rosegarden mainstream, at least not in any
timely fashion and probably not ever. I have invested far too much time
and effort (currently 20x my original estimate) (and Rosegarden is very
much a sideline to my main open source work) to relegate it solely to my
own private use. I believe the fixes and new features I've added
represent worthwhile improvements that others could benefit from. Time
may or may not tell.
On an even more personal note, in retrospect I regret having chosen this
development path. I had thought I could "hack in" two minor changes: The
one bug and one feature I originally posted about, i.e. MIDI input
playing the current editor's active segment's instrument, and key-aware
matrix editor highlighting. But at each step in a long chain of
development I ran into further missing features that I needed for my own
Rosegarden use, and even more so internal architectural failings and
omissions that made implementing anything far more difficult than it
should have been.
I also realized in retrospect that I could have implemented a
matrix-editor-only application from scratch in far less time. As I once
posted to a bug report, I had previously written a primitive non-GUI
application with the basic algorithms and an ALSA MIDI back end. I
wouldn't have ended up with the myriad of other capabilities Rosegarden
provides, including the much more difficult to implement notation
editor, but as I personally only use notation for communicating with
tradition-bound friends, and could have always exported MIDI to
Rosegarden (or Musescore) for producing offline output, that wouldn't
have presented an insurmountable problem. "Live and learn", as the
saying goes. Or maybe more appropriately given Rosegarden's original
developers, "In for a penny, in for a pound".
I hope this explains my motivations for forking Rosegarden (again, if
anyone is interested in them). As of now the fork still isolates its new
code in the separate thanks4opensrc_devel branch (with the exception of
a modified README.md file in master that clearly indicates the repo is a
non-official fork) although that may change in the future. I have one
more major feature planned, plus a raft of smaller ones, but currently
hope to slow my development on the project in order to return to the
other work mentioned above. I'm describing the branch structure on the
off-chance that there's any future interest in looking at parts of the
fork for potential inclusion in the official repository, either as code
or merely as ideas for independent/separate implementation. But note
that the branches have already diverged significantly (my last merge
with master [833ea5] was very difficult) and will likely continue to do
so. Of course my recommendation is that the forked branch be merged
wholly, as-is (git-merge "theirs), but I don't anticipate that happening. ;)
Finally, and as publicly stated in the fork's README.md, please accept
my appreciation for Rosegarden and acknowledgement of the man-decades of
work that have gone into it. As much as I think there are significant
architectural issues (not surprising considering the long development
history) and that a deep refactoring/re-implementation (far beyond the
recent "lint"/const-correctness merges, as valid as those are) should be
undertaken (not something I'm likely to undertake on my own) I still
believe the basic code design is sound and that the program's features
and workflows are exceptional. My best wi
