Merge between upstream and Tenacity's fork

[generic-pers0n]

Hello! I'm the maintainer for Tenacity, a free and open audio editor forked from Audacity.

Aside from being the maintainer of Tenacity, I also happen to help maintain other forks of important libraries Tenacity uses, namely libmad, libid3tag, and PortSMF. Many packagers, including those for Debian, Fedora, and plenty of others, have adopted our forks, and in the case of the first two libraries, they consider us the new upstream.

A while ago, I happened to notice this repository, and with the last commit being from 2 weeks ago (at the time of writing this issue), I consider this repository to be active. Therefore, I consider this the official upstream of PortSMF. As such, I am interested in upstreaming changes from our fork into this repo and effectively merging the two together because I think everyone can benefit from the changes contributed in this repo and the changes contributed in our repo. Additionally, development resources could be concentrated in a singular location.

Some of the changes our fork has includes the following:

• Source tree reorganization (library source files are now in a src/ subdirectory)
• Doxygen support.
• CMake is only supported (I'm fine with preserving other build systems, I just can't maintain them).
• Various code cleanups (you'd have to see our fork's commit history.
• Add version information to the library.

EDIT: It turns out there's some more changes to share:

• Support for CTest
• GitHub Actions workflows

I also have an issue opened in our repo regarding more refactoring tasks here: https://codeberg.org/tenacityteam/portsmf/issues/13. We can discuss those, but that would be for another time.

Finally, I'm not sure about what the long-term goals of the project may be. Currently, I don't see any tags or releases, and I don't know if there will be any planned for the future, so I'm a little curious as to what might be in store for the future of PortSMF.

Overall, I think merging our fork with this repo here would be a good idea, as everyone would benefit from the changes made in both repos. Even without a merge though, I think working together will benefit everyone, and I hope to be submitting some PRs soon!

[rbdannenberg]

Hi generic, do you have a real name? I'm curious how closely Tenacity tracks Audacity these days. I don't hear from Audacity and scores/midi/events are obviously not a priority, so I'm happy to hear recently that portsmf is in LMMS as well as Tenacity. Also interested to hear if there's any exchange between Tenacity and LMMS. Yes, I'd be interested in merging repos, although a little apprehensive that a merge could be a lot of work. My main interest in portsmf is keeping the tool allegroconvert operational -- it's a useful (to me) tool for manipulating MIDI files in ways that are difficult in DAWs. Otherwise I have no plans, and mostly I'm using a reimplementation in another language, so portsmf is kind of in maintenance mode and occasional added features to allegroconvert.

[generic-pers0n]

Hi generic, do you have a real name?

Hello! Indeed I do! You can call me Avery :D

I'm curious how closely Tenacity tracks Audacity these days. I don't hear from Audacity and scores/midi/events are obviously not a priority, so I'm happy to hear recently that portsmf is in LMMS as well as Tenacity.

At the current moment, I'm rebasing Tenacity off the latest stable version of Audacity. You can see https://codeberg.org/tenacityteam/tenacity/pulls/527 for more details. We'll keep rebasing Tenacity off the latest version of Audacity 3.x until Audacity 4 is stable.

Also interested to hear if there's any exchange between Tenacity and LMMS.

There actually has been quite a bit of discussion recently, most of it stemming from #5. In our fork, we require C++11, and (related to #5) the LMMS devs would like to raise this to C++17 at some point. It is our intent that we keep this minimum requirement and potentially raise it in the near future, in addition to some other potentially breaking changes. The motivation for making these changes it to help modernize and revamp the library to make it cleaner and

We are actually both interested in making quite a bit of breaking changes to help modernize the library. We have determined that the major users are pretty much Tenacity and LMMS aside from Audacity. I also suspect that Audacity will likely proceed with something from MuseScore should they choose to proceed with better MIDI support. Since I've also mentioned the desire for breaking changes in PortSMF, and they are in favor of them too, I think this is something we are both willing to take up with.

Yes, I'd be interested in merging repos, although a little apprehensive that a merge could be a lot of work.

No worries! I can help take care of PortSMF before, during, and after the merge as I'm willing to put in the effort for maintaining PortSMF. Since I maintained our fork of PortSMF alongside Tenacity, libid3tag, and libmad, with other contributors making contributions to all these projects as well, I think I am more than capable of handling the work.

My main interest in portsmf is keeping the tool allegroconvert operational -- it's a useful (to me) tool for manipulating MIDI files in ways that are difficult in DAWs. Otherwise I have no plans, and mostly I'm using a reimplementation in another language, so portsmf is kind of in maintenance mode and occasional added features to allegroconvert.

Since your wish is to keep allegroconvert operational, I can fullfil that! I'll guarantee that allegroconvert will remain operational despite any problems, and if there's a bug, you can open an issue on it and we'll investigate it.

It's possible we can put allegroconvert into its own repo to make thing easier (easier for maintenance, easier for building). That's not my main focus right now, but regardless, you have my word that alleogroconvert will remain operational, maintained, and receive new features too. Furthermore, since Tenacity's fork has GitHub Actions, we'll add that here too and expand that to allegroconvert to ensure everything builds. We can also require that tests pass in CI also. This should provide a good line of defense against breakage.

Finally, I'm going to CC @rubiefawn, @tresf, and perhaps @messmerd in case they want to add anything here. (These three are the ones I spoke to on LMMS's Discord server). I think we share some common goals, and we may be willing to take PortSMF out of maintenance mode and revamp it for the modern world. At the very least, however, I'm willing to do that, and I'm willing to work with LMMS devs to make that happen.

[generic-pers0n]

I should also mention that LMMS is currently upstreaming their PortSMF changes into our fork, and while I'm in the process of reviewing it commit-by-commit, I think I will accept these changes, so their changes will be carried over as well. I made the offer for them to upstream their changes into their fork, and they decided to take advantage of it.

EDIT: Here's a link to the PR they made: https://codeberg.org/tenacityteam/portsmf/pulls/15
EDIT 2: The PR has been merged.

[rbdannenberg]

Thanks, Avery. (Aside: the use of anonymizing names always seemed like a bad idea that works against social responsibility, and now that the US has fallen to fascists, I'm even more sensitive to it. My PhD thesis was partly about personal computer resource-sharing and strategies to keep it safe. I never imagined all the implications for social networks, https, etc., but identification is central to trust. But enough of that.) I've been thinking about the repo and changes. I was resistant to using later C++ features because they are not supported by default in off-the-shelf IDEs and make it difficult for random users to use the code, and installation/configuration difficulties have gotten to be huge problems. It amazes me that anyone things C++ can survive by becoming even harder to use. But anyway, I then realized I'm not using my C++ implementation of Allegro and PortSMF in any other projects, so it's more important to support Tenacity and LMMS as much as possible. I'm also thinking that maybe it's best to hand off PortSMF to Tenacity and/or LMMS -- I don't think multiple versions and repos is helpful. I will leave it to you to propose what outcome you'd like to see. Meanwhile, if you have a version you think is usable I think I'm ready to look at changes just as a sanity check and hand it off (or maybe you'd like to build allegroconvert and see if it works, and I could perhaps offer some input/output files based on typical use cases for testing).

[generic-pers0n]

But anyway, I then realized I'm not using my C++ implementation of Allegro and PortSMF in any other projects, so it's more important to support Tenacity and LMMS as much as possible. I'm also thinking that maybe it's best to hand off PortSMF to Tenacity and/or LMMS -- I don't think multiple versions and repos is helpful. I will leave it to you to propose what outcome you'd like to see.

Great news to hear! In that case I have a proposal for how we should proceed.

My Proposal

A new Home for PortSMF

First off, I believe we should create a new organization, either on GitHub or Codeberg (I'll leave it up to the LMMS devs to leave their preference so we can decide). This organization will be responsible for PortSMF development going foward. This way, it makes PortSMF's home a little more formal.

For membership of the organization, see the section More on Ownership below.

Splitting allegroconvert from PortSMF

I feel that it is more appropriate that we split allegroconvert from the main PortSMF repo. This will allow us to keep separate histories of the projects going forward and allow for easier development of the two in parallel.

More on Ownership

As I proposed earlier, we should create a new organization. This organization should contain developers from both Tenacity and LMMS as we both have common goals with the library. I also think you should be included in the organization as well so you can work on allegroconvert as much as your heart desires.

The New Codebase

I think this is the largest elephant in the room, perhaps. We have already begun the process of upstreaming LMMS's downstream PortSMF to our fork, and so I feel it would be best to use our fork as the new codebase going forward. However, I'd also like to evaluate this repo here and merge any changes in this repo back to our fork.

Eventually, we'll make a new release, version 240. I'll then start to go around to various projects to get more green on this matrix:

---

Meanwhile, if you have a version you think is usable I think I'm ready to look at changes just as a sanity check and hand it off (or maybe you'd like to build allegroconvert and see if it works, and I could perhaps offer some input/output files based on typical use cases for testing).

I'll let you know when we have a usable version. What we can do is integrate our changes first under Tenacity's fork, tag a release in Git (maybe a beta release), modify allegroconvert to build against our version, and then you can provide us with some test files.

I think it would be beneficial to test allegroconvert in two stages: one against our planned compatibility shim (i.e., unmodified) and the other against our new APIs. We can also do the same with Tenacity too, but having another program to test is always better than one less.

[tresf]

I noticed that this page still exists: https://portmedia.sourceforge.net/. Is this project still affiliated with PortMedia? If so, is there any coordination that should be done there? Quoting the old SF page:

PortMedia was created to develop and share cross-platform, open-source I/O libraries for digital media including MIDI, video, and audio. Only a few things were released under the PortMedia umbrella. These are now hosted by the github.com/Portmidi/ project, where you can find the lastest versions of PortMidi, portsmf (Standard MIDI File support and more), and see github.com/rbdannenberg/scorealign for MIDI and/or Audio score alignment.

[rbdannenberg]

The work on sourceforge has been moved to github. I'll see if I can mark that page and project as "historical archival material" with a redirect to current pages. Also planning to reply to your proposal - I'm juggling too many students and projects, but haven't forgotten.

[rbdannenberg]

I updated the page on sourceforge to redirect people to more current sites.

Creating a new organization seems heavy-weight for a small library, but maybe it makes it simpler to to manage. I have no objections. Also, I guess what we're really talking about is you create an organization, clone the code and update it, and I put forwarding links from my repo to the new one (or just take down my repo). I'm OK to put allegroconvert into a separate repo, although I think a command line tool to exercise the library is a nice way to facilitate simple tests, especially because allegroconvert's main function is converting standard midi files to (somewhat) human readable and editable text files, which is really helpful to track down hidden mysteries in MIDI files. But I'll leave that to you.

By the way, there's another "user" of portsmf which is my scorealign repo. (Scorealign was originally created to transfer our research in MIDI-to-audio and audio-to-audio alignment into Audacity. It was a big addition including a lot of note track editing to manually tweak tempo and alignment with other tracks, and it never made it into Audacity.) Although scorealign is 10x faster at least than a lot of research code that was out there in MatLab, I don't think it ever got much use. I just mention it as another test for any API changes or language version issues.

Bottom line: I'm in favor, so let's proceed and I'll be happy if this code gets continuing care.

[tresf]

Creating a new organization seems heavy-weight for a small library, but maybe it makes it simpler to to manage. I have no objections

Just chiming in on this point a bit...

If you plan on co-maintaining it, it's fairly common to do this (even for small libraries like this one) and once the new fork is created, with your permission, GitHub can mark the new project as upstream. Last I did this, a GitHub support request was needed for the switch to occur. If the worry is that a dedicated project is overkill, it may make sense for it to move to Tenacity instead with you added as a maintainer over there if that makes more sense, but I don't want to be too prescriptive here.

Often when projects do this it's because the original author is no longer available. GitHub won't change upstream without the author's permission, so this puts portsmf at an advantage in this regard (since you're still here to approve this, if you wish). Furthermore, these transitions often come with a huge backlog of PRs and bug reports further complicating this transition. This project doesn't have a ton of complexity to move over, which isn't common but is very convenient in the scope of a switch.

Ultimately, moving it to an organization is your call. The same can be achieved by granting access to <this> repo. There are some projects that do this.

Note, in some cases, the fork is never "approved" by upstream but it effectively becomes upstream because that's where devs go for updates. This happened to me over at https://github.com/java-native/jssc/, but it's always ideal to have the hierarchy obvious to a casual onlooker.

[rbdannenberg]

That makes sense - it's fine to create a new project and I can mark it as upstream. (It would make more sense to me to simply delete my portsmf repo -- this idea of upstream/downstream and even the graph structure in git is way too complicated for casual use (IMO). (But maybe leaving it as a signpost pointing to the "main" repo would be helpful.) I could also grant access to my repo instead, but I'm be happier to have it in another account where other owners could be designated.

[tresf]

this idea of upstream/downstream and even the graph structure in git is way too complicated for casual use (IMO).

Agreed.

But maybe leaving it as a signpost pointing to the "main" repo would be helpful.

Furthermore, the signpost would also serve as a non-breaking change to any scripts, submodules or hyperlinks pointing here. GitHub allows archiving the project and it will display a very clear warning at the top of the page for those browsing.

[generic-pers0n]

The most I can say right now (due to time constraints) is this: I will proceed with creating a new organization, perhaps called portsmf, provided I have enough time. I will let everyone know when the organization is created here.

[generic-pers0n]

Ok. Since I now have more time on my hands, I have proceeded to create a new organization on GitHub inviting @rbdannenberg, @tresf, @rubiefawn, and @messmerd. From there, we can decide owners and other organizational details.

Sadly, I forgot what I originally wanted to say about the organization, but I'm thinking everything is finally coming together! 😄

[generic-pers0n]

And with that, the new PortSMF repo is now up! You can find it here: https://github.com/portsmf/portsmf. I've also adjusted the organizational roles so further progress can be made by anyone else too.

The repo comes from Tenacity's fork, but that can be changed as necessary. Maybe soon we can finally get started on some stuff, but until then, the organization is now setup!

Eventually, we can get allegroconvert into its own repo. For now, this should be a good start.