I'm a bit uncomfortable with this as is. Upstream is shipping a tarball. The release is 1.0.15 from upstream. It has a configure script but that script does not generate a library (shared or static).

The code does not promote bundling for the purpose of local modifications: 1) it seems like the C++ code would lend itself to inheritance if overriding was necessary 2) the license explicitly says "Any person wishing to distribute modifications to the Software is requested to send the modifications to the original developer so that they can be incorporated into the canonical version."

I think we may just have a case where upstream hasn't gone through the extra step of creating a shared or static library with their configure scripts rather than an upstream that intentionally wants people to fork off the library code and do with it what they please.

Some followup questions:

• Has anyone talked to the rtmidi upstream directly?
• What are the changes between rtmidi upstream and the bundled versions that the app ships?

• Has anyone talked to the rtmidi upstream directly?
  Upstream reply full text:

For the moment, RtMidi is primarily intended as a "copylib" (if I understand the term correctly). Currently, RtMidi provides support for both the Jack MIDI and ALSA MIDI APIs but there is no way to compile both concurrently. I could "fix" this, as I did in RtAudio, but no one has requested it to date. So, if it was compiled dynamically, one would have to choose either the ALSA or JACK API support. I think it best to leave that decision up to the application developers.

• What are the changes between rtmidi upstream and the bundled versions that the app ships?
  For vmpk, no change between the bunddled RtMidi and the corresponding verison of upstream release.

The correct fix is to have upstream enable concurrent support for both JACK and ALSA. In the interim, it should be possible to package rtmidi and have it generate two libraries, one for ALSA and one for JACK. I'll work on building that today.

Okay, here is an rtmidi library package:

http://spot.fedoraproject.org/rtmidi-1.0.15-1.fc15.src.rpm

CMake gives me migraines, so I'd prefer to have cheeselee (or someone else) figure out how to strip out the bundled copy from vmpk and use the system library (either the ALSA one or the JACK one).

(Also note that if upstream merges the interfaces so that they can be enabled simultaneously, it will simplify the rtmidi package quite a bit.)

Thanks! That sounds great. I will look into it as soon as possible.

The correct URL: http://spot.fedorapeople.org/rtmidi-1.0.15-1.fc15.src.rpm

Okay, here is a vmpk package using the shared rtmidi object:

http://cheeselee.fedorapeople.org/vmpk-0.4.0-2.1.fc15.src.rpm

Then would you submit the rtmidi for review or pass your work to me?

If you're willing to maintain rtmidi, that would be ideal (I have too many Fedora packages already). I'd be willing to assist as needed with upkeep.

I sent your work upstream and wait for reply.

Finally, a review request for rtmidi: https://bugzilla.redhat.com/show_bug.cgi?id=744492

And upstream should make a consistent new release soon.

So this issue should have been resolved.

Is there an open bug on pianobooster to lose the bundled copy of rtmidi?

OK, I have just reported one:

https://bugzilla.redhat.com/show_bug.cgi?id=745679

Closing this out.

VMPK 0.5.0 includes a heavily patched RtMIDI library with API changes for the support of multiple backends in a single compilation. VMPK 0.5.0 won't compile with original RtMIDI, 1.0.15 or 2.0.1. Or we have to patch VMPK to regress the new feature in 0.5.0.

Were the changes proposed to RtMIDI upstream as the license requests?

RtMidi 2.0.x takes a different approach to support multiple backends in a single compilation.
VMPK author seems really annoyed by the upstream approach and so prefers maintaining a fork.

Opinion from VMPK author: https://sourceforge.net/tracker/?func=detail&atid=1100310&aid=3597097&group_id=236429

RtMidi author may not manage to satisfy VMPK request in time. He said in a mail to me:

... I don't have time to attempt to keep everyone happy (nor, honestly, do I care). If they like the code, they are free to use it. Otherwise, they can look for other options.

Please update this ticket regarding its continued relevance, providing any information requested. If this is not done within the next two weeks, this ticket may be closed due to inactivity. Thank you!

Latest VMPK (0.5.1) is still bundling the patched RtMIDI. And RtMIDI upstream has no new action.

So this ticket is still valid. Otherwise VMPK on Fedora will continue to stick to the 0.4.0 version.

And, nearly two years later, it looks like FPC never considered this. Unfortunately now we're in the position that we can't really address it without knowing the current situation. Still, I'll move if to the meeting agenda and perhaps we can at least get a feel for how the committee feels. If you have any updates to provide which you think would help us to make a decision, feel free to add them at any time.

I am sorry I did not update this issue too. Latest VMPK (0.6.0) no longer uses RtMidi. So I draw back this exception request.