Opened 20 months ago

Last modified 20 months ago

#67181 assigned defect

solfege: Alternative for qtplay

Reported by: ryandesign (Ryan Carsten Schmidt) Owned by:
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: kwolcott
Port: solfege

Description

The solfege port currently declares a runtime dependency on qtplay but that software relies on deprecated OS frameworks and cannot be built on current macOS versions. Is an alternative available? For example, could /usr/bin/afplay work?

Kenneth originally reported this on the mailing list: https://lists.macports.org/pipermail/macports-users/2023-March/051979.html

Change History (2)

comment:1 Changed 20 months ago by ryandesign (Ryan Carsten Schmidt)

Owner: allencmcbride@… deleted

Allen indicated by email that he can no longer maintain this port.

comment:2 Changed 20 months ago by ryandesign (Ryan Carsten Schmidt)

The upstream solfege project doesn't use qtplay, but it does need some program to play audio files, and it has a configuration file where you specify which program to use for different types of files. The solfege port contains a patch that modifies the config file to use qtplay for all the file types that it can.

/usr/bin/afplay exists on Mac OS X 10.5 and later, based on what I could find, so we could have the solfege port use that instead of qtplay on 10.5 and later, except that the port currently configures solfege to use qtplay for MIDI files and afplay doesn't support MIDI files. I don't know how important it is that solfege be able to play MIDI files. If it is, we need another solution for that. FluidSynth is in MacPorts and seems to be able to play a sample MIDI file but even with the -q flag it prints useless output to the terminal that might be annoying. Timidity is another option that might be suitable (it's what the config file was set up for before we patched it) but it's not in MacPorts yet; see #51842.

Note: See TracTickets for help on using tickets.