Created attachment 220977 [details] audio_portmidi.shar This is a port of PortMIDI version 217, a computer library for real time input and output of MIDI data. It is using the sndio library for a portable implementation, and this port is derived from Raphael Graf's patches for a sndio backend on the OpenBSD audio/portmidi port, enhanced to detect a variable number of MIDI (umidi) devices: http://openbsd-archive.7691.n7.nabble.com/audio-portmidi-input-td363848.html https://marc.info/?l=openbsd-ports&m=155221816900336&w=2 Although I have not been able to test this library directly besides successful compilation on multiple FreeBSD 12.0 and 12.1 RELEASE systems, I have applied a modified version of this port to work with audio/pd's in tree version of PortMIDI (this is going to be submitted shortly, as well, though at present, it does not depend on this port at present), and I have used that extensively with numerous MIDI input devices (see below; input only tested so far, since I haven't implemented MIDI output support in audio/pd yet). As noted above, I've tested PortMIDI on FreeBSD with the following MIDI devices: * Roger Linn LinnStrument * Hornberg Research hb1 breath controller * Keith McMillen Instruments SoftStep 2 foot controller * Keith McMillen Instruments QuNeo * Roland GR-55 Guitar Synthesizer (MIDI output only on foot pedal, USB MIDI output requires a special driver) * Evolution U-Control UC-33e * Behringer FCB1010 Foot Controller * Yamaha PSR-280 keyboard My apologies for sitting on this new port since July, I just haven't had enough opportunity to test it until recently...
How does this sndio backend compare to using the BSD reimplementation of alsalib to use PortMidi's ALSA backend? I understand not all BSDs have a reimplementation of alsalib, so IIUC sndio is more portable. On systems where both is available, are there practical benefits to one or the other?
(In reply to Be from comment #1) I wasn't aware of an ALSA backend to PortMidi, which I will investigate. I personally like sndio as a library, as it is extremely BSD friendly, both in terms of licensing as well as code examples that already worked. I was able to get this ported very quickly, which made me like it right away, but it still may be worth trying the ALSA backend since that is likely more widely supported. I agree that embedding sndio inside of PortMIDI is odd, and there is a lot of duplicate functionality between both libraries, so given ALSA's wider use base, that may have some advantages. I need to do a more detailed comparison between the two libraries to see if there are any performance issues. Ultimately, as long as it performs well, I just want to be able to use MIDI devices on FreeBSD, and don't care how it is accomplished.
Some quick notes (by no means a full review) PORTVERSION --> DISTVERSION https://docs.freebsd.org/en/books/porters-handbook/book/#makefile-naming MASTER_SITES should use macro https://docs.freebsd.org/en/books/porters-handbook/book/#makefile-distfiles --> 5.4.2.1 DISTNAME should use DISTVERSION USES= should be sorted in alphabetical order CFLAGS and LDFLAGS should be replaced by USES= localbase https://docs.freebsd.org/en/books/porters-handbook/uses/#uses-localbase Is MAKE_JOBS_UNSAFE really needed? CMAKE_ARGS+= --> CMAKE_ARGS= Why is "NO_TEST= Yes" this needed? While I don't think there's a strict rule it would be nice avoid hosting source files in tree and preferably have changes upstreamed (files/pm_sndio/pmsndio.c and files/pm_sndio/pmsndio.h) audio/portmidi/files/patch-pm__common_CMakeLists.txt and audio/portmidi/files/patch-pm__dylib_CMakeLists.txt seems to touch unrelated sections (APPLE)? Are portlint and/or portfmt happy? Thanks for your contribution Best regards, Daniel
(In reply to Daniel Engberg from comment #3) I wrote this port last summer, and submitted it near the end of last year, but I just noticed that the maintainers of PortMIDI also submitted a port of audio/portmidi in July which was accepted into the ports tree, so this submission from last year is no longer relevant. While I have no problem with fixing those issues (it passed portlint easily, but I agree it could be better in a number of areas), upstream has already provided a working version. I have no problem with just using their submission since they are more well versed in the library, although in my view sndio has better licensing and the fact that on FreeBSD it has no other dependencies, whereas ALSA has a lot of dependencies. That being said, it doesn't really matter to me as long as it works. I'm happy to have people dedicated to making sure that PortMIDI works well on FreeBSD! This PR can be closed in that case.
There is still one issue preventing FreeBSD from using the https://github.com/mixxxdj/portmidi repo unmodified with the ALSA backend. PortMidi uses a deprecated glibc function (ftime). This should probably be replaced with the standard POSIX clock_gettime. If you want to make a pull request implementing that and test it on FreeBSD, I would be happy to test it for regressions on Linux.
Dear FreeBSD ports committers, Why wasn't I notified of the need for a port of audio/portmidi? My completed port has been sitting in bugzilla since late last year, untouched for over 7 months, now pushing 8. If a ports committer checked for new or open PRs, or committed it way earlier (as early as late last year), it may have saved people some time and effort. If there was something wrong with it, I would have tried my best to address any issues or shortcomings, with no upstream active at the time that I ported it. I saw no activity or interest to get it committed, and while I applaud this urgency to port niche but important libraries, I am pretty demotivated by the way this went down and feel like I'm wasting my time. I don't fault anyone for this happening, as the circumstances doesn't look like there were ill intentions on anyone's part, but as it stands, I wasted a ton of time porting it, only to have my work completely thrown away, or even given any credit or recognition at all for a fairly difficult port as if my PR never existed (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252186, and a cursory search for "portmidi" reveals two PRs that I have authored). This scenario could have been avoided completely if my PR were handled earlier by committers, or if someone told me something that needed to be fixed if it wasn't up to standard. I understand that committers are tremendously overburdened, but I have a lot of ports almost ready to go, just sitting here bitrotting, many like portmidi since last year, and I don't ever want to put in a lot of time and energy again to just have my work never used and ignored. That's incredibly discouraging. I applaud the new upstream of portmidi, who are taking a proactive approach and are committed to supporting multiple platforms properly, and look forward to working with them on getting some version of that work incorporated at a later date. I'm thrilled to see these ports happening, but I didn't expect to this situation unfold in this particular way.
(In reply to Timothy Beyer from comment #6) Hi Timothy, maybe it was my fault because I didn't check if someone submitted a portmidi/PR for add it. Feel free to poke me if you want I review your new/pending ports. Anyway it could be a great chance for work together with Be
(In reply to Jose Alonso Cardenas Marquez from comment #7) Hi Jose, No worries. I don't hold you, or any committer responsible individually, and I may have overreacted in either case. Honestly, even if I were a committer, I wouldn't have expected to see a PR for audio/portmidi given that it a is niche library. I mostly meant that when these PRs don't get handled for months, the odds of accidental duplication of work increase. Although it was highly improbable, unfortunately, that was the case of audio/portmidi. I suppose it being a library as opposed to a standalone program increased the odds as well. I hope that in the future, people are made aware if there is already code written in existing PRs, such that even if committers are unable to handle a PR until considerably later, code can be reused more effectively. I was a bit too harsh in my criticism earlier, my apologies. Tim
I guess we can close this PR now, thanks for your initial submission Inital version added to tree is 235.0 in commmit 4efef974205a73ebe689bd11db595e7ef3f23437