NEW: audio/timgm6mb && convert consumers to timgm6mb

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

NEW: audio/timgm6mb && convert consumers to timgm6mb

Brian Callahan-3
Hi ports --

I would like to spin off the GUS patchset we awkwardly bolt onto the
timidity package into its own package. This is because sdl-mixer and
sdl2-mixer both have their own internal timidity, and currently timidity
is not set as an RDEP for either, meaning that both sdl-mixer and
sdl2-mixer effectively have no out-of-the-box midi support, even though
they could if only we supplied a default patchset as an RDEP. I don't
see a reason to include some useless (and old...) binaries to gain that
support. Additionally, I have another port ready to go (audio/wildmidi)
that also needs a patchset. Seeing as wildmidi is itself a midi player,
it seems strange to have to install a different midi player to get
wildmidi to work out-of-the-box.

I did have to tweak a pair of consumers, games/corsixth and
games/openxcom. Both use one of the sdl-mixer ports for midi audio,
meaning that a useless timidity binary has to be installed just to get
audio. This changes things so that sound works as expected, no extra
binaries need to be installed. I'll note there is precedent here with
sf2 files, audio/generaluser-gs-soundfont being one such example. The
timgm6mb port includes the GUS patchset and the sf2 file the patchset
was generated from.

tl;dr
1. spin off the TimGM6mb GUS patchset that we awkwardly bolt onto the
timidity package into its own package
2. update all consumers to use this new package

OK?

~Brian


timgm6mb.tgz (2K) Download Attachment
timgm6mb.diff (12K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NEW: audio/timgm6mb && convert consumers to timgm6mb

Stuart Henderson
On 2018/01/12 15:47, Brian Callahan wrote:

> Hi ports --
>
> I would like to spin off the GUS patchset we awkwardly bolt onto the
> timidity package into its own package. This is because sdl-mixer and
> sdl2-mixer both have their own internal timidity, and currently timidity is
> not set as an RDEP for either, meaning that both sdl-mixer and sdl2-mixer
> effectively have no out-of-the-box midi support, even though they could if
> only we supplied a default patchset as an RDEP. I don't see a reason to
> include some useless (and old...) binaries to gain that support.
> Additionally, I have another port ready to go (audio/wildmidi) that also
> needs a patchset. Seeing as wildmidi is itself a midi player, it seems
> strange to have to install a different midi player to get wildmidi to work
> out-of-the-box.
>
> I did have to tweak a pair of consumers, games/corsixth and games/openxcom.
> Both use one of the sdl-mixer ports for midi audio, meaning that a useless
> timidity binary has to be installed just to get audio. This changes things
> so that sound works as expected, no extra binaries need to be installed.
> I'll note there is precedent here with sf2 files,
> audio/generaluser-gs-soundfont being one such example. The timgm6mb port
> includes the GUS patchset and the sf2 file the patchset was generated from.
>
> tl;dr
> 1. spin off the TimGM6mb GUS patchset that we awkwardly bolt onto the
> timidity package into its own package
> 2. update all consumers to use this new package
>
> OK?
>
> ~Brian
>

I agree with splitting it.

You have this in timgm6mb:

share/examples/timidity/
share/examples/timidity/timidity.cfg
@sample ${SYSCONFDIR}/timidity.cfg

This conflicts with the existing timidity package so an @conflict
would need to be registered. However it seems a bit odd to
bundle timidity.cfg in timgm6mb rather than timidity in the
first place ..

It might make more sense to have timidity depend on timgm6mb and
include the cfg in timidity's package instead?

Reply | Threaded
Open this post in threaded view
|

Re: NEW: audio/timgm6mb && convert consumers to timgm6mb

Brian Callahan-3

On 01/12/18 16:20, Stuart Henderson wrote:

> On 2018/01/12 15:47, Brian Callahan wrote:
>> Hi ports --
>>
>> I would like to spin off the GUS patchset we awkwardly bolt onto the
>> timidity package into its own package. This is because sdl-mixer and
>> sdl2-mixer both have their own internal timidity, and currently timidity is
>> not set as an RDEP for either, meaning that both sdl-mixer and sdl2-mixer
>> effectively have no out-of-the-box midi support, even though they could if
>> only we supplied a default patchset as an RDEP. I don't see a reason to
>> include some useless (and old...) binaries to gain that support.
>> Additionally, I have another port ready to go (audio/wildmidi) that also
>> needs a patchset. Seeing as wildmidi is itself a midi player, it seems
>> strange to have to install a different midi player to get wildmidi to work
>> out-of-the-box.
>>
>> I did have to tweak a pair of consumers, games/corsixth and games/openxcom.
>> Both use one of the sdl-mixer ports for midi audio, meaning that a useless
>> timidity binary has to be installed just to get audio. This changes things
>> so that sound works as expected, no extra binaries need to be installed.
>> I'll note there is precedent here with sf2 files,
>> audio/generaluser-gs-soundfont being one such example. The timgm6mb port
>> includes the GUS patchset and the sf2 file the patchset was generated from.
>>
>> tl;dr
>> 1. spin off the TimGM6mb GUS patchset that we awkwardly bolt onto the
>> timidity package into its own package
>> 2. update all consumers to use this new package
>>
>> OK?
>>
>> ~Brian
>>
> I agree with splitting it.
>
> You have this in timgm6mb:
>
> share/examples/timidity/
> share/examples/timidity/timidity.cfg
> @sample ${SYSCONFDIR}/timidity.cfg
>
> This conflicts with the existing timidity package so an @conflict
> would need to be registered. However it seems a bit odd to
> bundle timidity.cfg in timgm6mb rather than timidity in the
> first place ..
>
> It might make more sense to have timidity depend on timgm6mb and
> include the cfg in timidity's package instead?
>
Ah, I missed part of the explanation, and I sent the wrong tarball :(
Attached is a tarball that moves the timidity.cfg to
share/examples/TimGM6mb to avoid the conflict.
Now, to your point:
sdl-mixer and sdl2-mixer *also* depend on a /etc/timidity.cfg to be
present, as will wildmidi. So we would then have to put an
RDEP=audio/timidity for all the consumers: devel/sdl-mixer,
devel/sdl2-mixer, games/corsixth, games/openxcom, and (eventually)
audio/wildmidi, which defeats the purpose of splitting in the first
place (as all the consumers will get the timidity binary, which is one
of the things I'm trying to avoid).

~Brian


timgm6mb.tgz (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NEW: audio/timgm6mb && convert consumers to timgm6mb

Landry Breuil-5
In reply to this post by Brian Callahan-3
On Fri, Jan 12, 2018 at 03:47:08PM -0500, Brian Callahan wrote:

> Hi ports --
>
> I would like to spin off the GUS patchset we awkwardly bolt onto the
> timidity package into its own package. This is because sdl-mixer and
> sdl2-mixer both have their own internal timidity, and currently timidity is
> not set as an RDEP for either, meaning that both sdl-mixer and sdl2-mixer
> effectively have no out-of-the-box midi support, even though they could if
> only we supplied a default patchset as an RDEP. I don't see a reason to
> include some useless (and old...) binaries to gain that support.
> Additionally, I have another port ready to go (audio/wildmidi) that also
> needs a patchset. Seeing as wildmidi is itself a midi player, it seems
> strange to have to install a different midi player to get wildmidi to work
> out-of-the-box.
>
> I did have to tweak a pair of consumers, games/corsixth and games/openxcom.
> Both use one of the sdl-mixer ports for midi audio, meaning that a useless
> timidity binary has to be installed just to get audio. This changes things
> so that sound works as expected, no extra binaries need to be installed.
> I'll note there is precedent here with sf2 files,
> audio/generaluser-gs-soundfont being one such example. The timgm6mb port
> includes the GUS patchset and the sf2 file the patchset was generated from.
>
> tl;dr
> 1. spin off the TimGM6mb GUS patchset that we awkwardly bolt onto the
> timidity package into its own package
> 2. update all consumers to use this new package

I didn't understand all of it, but the idea seems to make sense to me. I
think you might need some @conflict with timidity maybe, as the
timidity.cfg example config file is sampled at the same place ? Seems
like a grey area... do conflicts happen with samples ? have you tested
the upgrade path ?

Landry