search

Mindwerks / wildmidi

WildMIDI is a simple software midi player which has a core softsynth library that can be used with other applications.
https://github.com/Mindwerks/wildmidi
Other
201 stars 41 forks source link

Player enhancements #223

Closed winterheart closed 6 months ago

winterheart commented 3 years ago

Huge refactor for wildmidi player intended to enable more than one playback outputs. Now player supports -P option which controls actual output (default value depends on platform capabilities, but OpenAL output is preferred when available). Each output can be enabled or disabled on configuration and compile time. Currently there 9 outputs:

Player now can be easily extended for additional outputs and ported to another platforms, since there modular "framework" has been implemented.

open_*_output functions now accept path as output where to save file or send stream to sound device and can be defined by -o <out> option. This parameter currently required by wave, alsa, oss outputs.

Additional fixes to build system

Besides changes related to player, there also some fixes in CMake build system. Now CMake can properly generate project for multiconfiguration systems like VS MSBuild. If such system is detected, you can build any of supported build types with cmake --build <dir> --config <build_type>.

Additionally Github Actions now stores build artifacts available on Actions page (like here https://github.com/winterheart/wildmidi/actions/runs/376312898).

raziel- commented 3 years ago

Awesome

psi29a commented 3 years ago

Very cool, thoughts @sezero ?

sezero commented 3 years ago

Very cool, thoughts @sezero ?

I don't know. One thing that comes to my mind is why make OpenAL the default?? Don't like that one for sure. (OpenAL output was added with the sole purpose of supporting macOS the easy way. It isn't available everywhere by default.) As for the rest, needs review and testing.

sezero commented 3 years ago

Well, I locally did wget https://github.com/Mindwerks/wildmidi/pull/223.patch && git am 223.patch and then did mkdir b && cd b && cmake -DCMAKE_BUILD_TYPE=Release -DWANT_STATIC=1 ..:

-- The C compiler identification is GNU 4.4.7
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Build Type: Release
-- Performing Test HAVE_VISIBILITY_DEFAULT
-- Performing Test HAVE_VISIBILITY_DEFAULT - Success
-- Performing Test HAVE_VISIBILITY_HIDDEN
-- Performing Test HAVE_VISIBILITY_HIDDEN - Success
-- Performing Test HAVE___BUILTIN_EXPECT
-- Performing Test HAVE___BUILTIN_EXPECT - Success
-- Performing Test HAVE_C_INLINE
-- Performing Test HAVE_C_INLINE - Success
-- Performing Test HAVE_C___INLINE__
-- Performing Test HAVE_C___INLINE__ - Success
-- Performing Test HAVE_C___INLINE
-- Performing Test HAVE_C___INLINE - Success
-- Performing Test HAVE_NO_UNDEFINED
-- Performing Test HAVE_NO_UNDEFINED - Success
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for inttypes.h
-- Looking for inttypes.h - found
-- Check if the system is big endian
-- Searching 16 bit integer
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of unsigned short
-- Check size of unsigned short - done
-- Using unsigned short
-- Check if the system is big endian - little endian
-- M_LIBRARY: /usr/lib/libm.so
-- Configuring done
-- Generating done

The resulting config.h has this:

/* Define our audio drivers */
/* #undef HAVE_LINUX_SOUNDCARD_H */
/* #undef HAVE_SYS_SOUNDCARD_H */
/* #undef HAVE_MACHINE_SOUNDCARD_H */
/* #undef HAVE_SOUNDCARD_H */

#define AUDIODRV_NONE 1
#define AUDIODRV_WAVE 1
#define AUDIODRV_ALSA 0
#define AUDIODRV_OSS 0
#define AUDIODRV_OPENAL 0
#define AUDIODRV_AHI 0
#define AUDIODRV_WIN32_MM 0
#define AUDIODRV_OS2DART 0
#define AUDIODRV_DOSSB 0

Obviously not acceptable as is.

Haven't done any further testing, nor have I compared the moved code to the original ones.

winterheart commented 3 years ago

@sezero main idea is give to user choice what he like to enable. If user desired to enable OpenAL, ALSA and OSS, new functionality gives him that opportunity. If he decided to disable all - he'll get what he want to: only very basic functionality with one 'true' output which will work on all platforms - wave.

Build system changed for that, so you can enable or disable any variation of outputs that theoretically support target platform. So, for Linux system build options will be cmake -DCMAKE_BUILD_TYPE=Release -DWANT_STATIC=1 -DWANT_ALSA=ON -DWANT_OSS=ON -DWANT_OPENAL=ON .. (if you want all of them - and this is sane configuration, you can choose any supported playback with -P <playback_output> option).

OpenAL chosen as default output with one reason - it runs practically everywhere. If you have OpenAL support on target, you'll don't have to think about platform-specific output and build environment. So this ease to port player/library into new platform. Like I sad, if you have POSIX system with available OpenAL on it, you'll be OK, nothing to do for porting wildmidi player. But still old behavior still available - disable OpenAL and enable one of native output, and you'll receive same functionality as from current master. Player autodetect next available output and will use it for playback.

winterheart commented 3 years ago

ping?

psi29a commented 6 months ago

@winterheart if you're still around, would be nice to rebase this.

I think the main point of contention was the 'default'. We can still have that discussion if you want.

Keep in mind that openal is deprecated on macos and will eventually be removed. So we'll defo need a replacement, though that is likely not for this PR.

sezero commented 6 months ago

I rebased this myself now (and fixed a few things myself too.) Hopefully not missed anything..

sezero commented 6 months ago

Keep in mind that openal is deprecated on macos and will eventually be removed. So we'll defo need a replacement,

I think we can port coreaudio module of xmp project for it: https://github.com/libxmp/xmp-cli/blob/master/src/sound_coreaudio.c

sezero commented 6 months ago

Keep in mind that openal is deprecated on macos and will eventually be removed. So we'll defo need a replacement,

I think we can port coreaudio module of xmp project for it: https://github.com/libxmp/xmp-cli/blob/master/src/sound_coreaudio.c

Dropped OpenAL support and added CoreAudio support as of 2838805b Note that cmake still needs -DWANT_COREAUDIO=ON switch to enable the backend. Please test.

winterheart commented 6 months ago

Why dropping OpenAL? In macOS it's deprecated only on SDK level, but still can be used via brew. And why dropping OpenAL on Linux/BSD?

sezero commented 6 months ago

Why dropping OpenAL? In macOS it's deprecated only on SDK level, but still can be used via brew. And why dropping OpenAL on Linux/BSD?

Native support for them should be superior, e.g. having ALSA on Linux drops any necessity for openal on Linux. FreeBSD is covered by OSS. For OpenBSD we can easily add sndio, etc. Any extra dependency is a hassle, IMO (but that's just me.)

sezero commented 6 months ago

@psi29a: What do you think? Should we keep openal?

psi29a commented 6 months ago

openal is still used; openmw is still debating adding midi support and looked at wildmidi as well. As the project makes use of openal-soft; it would be a pity to drop stupport.

I only wanted to make a sane default; so for example auto which would test and select in a priority list. Obviously not for this PR; but that was my idea.

sezero commented 6 months ago

OK, will rearrange things and will keep openal -- don't know how to handle its priority though..

sezero commented 6 months ago

OK, will rearrange things and will keep openal -- don't know how to handle its priority though..

OK, rearranged things and kept openal. Then moved openal output support after the native backends in the list.

Comments?

psi29a commented 6 months ago

I have none; this looks great. Glad to see this project keeping the dream alive. :)

sezero commented 6 months ago

I have none; this looks great. Glad to see this project keeping the dream alive. :)

I have yet to clean things up:

sezero commented 6 months ago

I think I'm mostly done with this. @psi29a, @winterheart: Take a look (and test if possible) one last time.

I still want to add a native backend for netbsd, but that can be done after this gets in.

psi29a commented 6 months ago

Yeah, native backends needed for:

We can put that on our issue tracker

sezero commented 6 months ago

Yeah, native backends needed for:

macos

That's already done: coreaudio is added in this P/R

netbsd

Working on it, can possibly do it today

more...

For e.g. ?

psi29a commented 6 months ago

Oh wow, reads notes

psi29a commented 6 months ago

That means we can make use of github actions to make macos builds as well... perhaps in another PR?

We can have a rule to make release builds when tagged.

sezero commented 6 months ago

That means we can make use of github actions to make macos builds as well... perhaps in another PR?

Current github actions generates artifacts, thanks to @winterheart Don't know specifically about macos, though

We can have a rule to make release builds when tagged.

For another PR.

Merging this now.

sezero commented 6 months ago

@psi29a, @winterheart: With alsa or oss configured, --device=default or --device=/dev/dsp works, but -d default or -d /dev/dsp does not: Fails with ./wildmidi: invalid option -- 'd'

It used to work before (e.g. in 0.4.5) -- what am I doing wrong? (It's probably something obvious, but I can't see it for now..)

sezero commented 6 months ago

@psi29a, @winterheart: With alsa or oss configured, --device=default or --device=/dev/dsp works, but -d default or -d /dev/dsp does not: Fails with ./wildmidi: invalid option -- 'd'

It used to work before (e.g. in 0.4.5) -- what am I doing wrong? (It's probably something obvious, but I can't see it for now..)

Created this as a new ticket https://github.com/Mindwerks/wildmidi/issues/250 so that it doesn't get lost. Please respond / discuss at there.

psi29a commented 6 months ago

Ah, was going to validate on my mac, but alright. If I come up with anything, will create an issue for it. Cheers everyone!

sezero commented 6 months ago

Ah, was going to validate on my mac, but alright. If I come up with anything, will create an issue for it.

Yes please

sezero commented 6 months ago

Just added a native netbsd backend to master

sezero commented 6 months ago

Ah, was going to validate on my mac, but alright. If I come up with anything, will create an issue for it.

Yes please

And also check the newly added sndio (on openbsd) and netbsd backends if you are able.