[vlc-devel] [RFC] Requesting backport of audiotoolbox_midi to VLC 3.0

[David Fuhrmann]

Hello Marvin, Hello all,

> Am 04.12.2017 um 19:36 schrieb Marvin Scholz <epirat07 at gmail.com>:
> 
> Good evening fellow VLC devs,
> 
> I wanted to request an exception to the code freeze of 3.0 for the backport
> of the recently added audiotoolbox_midi decoder module for macOS (and iOS).

As already noted, 2.2 on macOS currently does not have midi support, and fluidlight was added to 3.0 to support midi files again, some months ago already. (AFAIK, midi playback was supported on macOS already before, in 1.x versions).

Question for me is, if the new module has enough benefits to replace the fluidlight implementation on such a rather short notice before 3.0 release.

Therefore, some questions regarding the new module:
- Is the module well tested on all supported platforms already (including iOS / tvOS), to avoid regressions, compared to fluidlight?
- Is the module on par quality and feature wise, with the fluidsynth module?
- Out of interest: Do you know how good the quality of the built in default soundfont is? As audio quality heavily depends on the sound font for midi files, I’m especially curious.

> This only affects macOS (and iOS), so the impact of backporting this should
> be quite small and it allows us to drop the FluidLite library for midi decoding,
> on macOS.

I would say the change is not that small, if it affects macOS, iOS and tvOS altogether. Therefore I find it important to thorougly test on the other platforms as well.

> The AudioToolbox midi decoder has the benefit that it can work without the user
> specifying any SoundFont, as it will use a default soundbank that is shipped with
> macOS.

This is probably particularly interesting on iOS, as its is harder to load a specific font file there.

In general, I’m not sure back port of this new module is acceptable currently, in respect to our release plans. I think goal is to do more and faster releases, also major ones. But in the past, major releases were often delayed already because of late / intrusive „late“ changes, afaik. So in general I believe we should strive for a mode where we do faster and more releases, and then the time would be smaller as well until new modules like this hits a release.

BR. David