Build with libstdc++ statically linked?

[mazmazz]

Hi, have you had success building with -static-libstdc++ or -Bstatic -lstdc++?

I'm trying to eliminate both the GCC and libstdc++ dependencies. I can successfully eliminate the GCC dependency with -static-libgcc, but my efforts to eliminate libstdc++ have failed.

I'm using on Windows: i686 mingw-w64 sjlj, GCC 5.4.0 from SourceForge. I also have FluidSynth and Timidity enabled, among others.

On another note, your official builds have both dependencies. SDL2_mixer has neither dependency.

[Wohlstand]

Hi! Mainly I compiling the thing with -static-libstdc++, but I didn't tried the -Bstatic -lstdc++. The C++ STL linking is needed because of some C++-coded dependent libraries are linked to SDL Mixer X itself:

• libModPlug
• libADLMIDI
• libOPNMIDI
• libGME

All others are pure-C libraries and not needs for C++ runtime.

My official Windows builds are contain no FluidSynth enabled, but Timidity only.

P.S. For now the build on MinGW-w64 at me is broken because of update of libModPlug where is the bug that prevents me to compile it correctly.

[Wohlstand]

About of FluidSynth, I gonna to provide some sort of FluidLite and own MIDI sequencer (that I have recently built for my libADLMIDI and libOPNMIDI) to let it easier to build (the full-featured FluidSynth is hard to bulid on Windows due DirectX dependency I wanna to avoid, as it also does build of built-in MIDI player that does using of audio output, but I don't wanna build that: only the synthesizer itself with no audio output support).

[mazmazz]

Thanks for the info; it seems I will have to accept the libstdc++, which is fine.

I enabled FluidSynth because I wanted to load SF2 sound fonts. It's easier to configure than Timidity, but yes, it's hard to build! It would be nice if your own solution could read SF2.

If you may be curious, here's what I'm using Mixer X for :)

[Wohlstand]

Timidity that is used here doesn't supports SoundFonts: it's not a Timidity++, it's an original Timidity that was modded by SDL folks (also by me in some parts). The Timidity++ is the extended variant of Timidity, and it's in use at GZDoom. :fox_face: :wink:

Also, about the video: I don't recommend you to use OPNMIDI in single-chip mode (until you'll be sure your MIDI music is fit in 6 voices polyphony, include drums), as each OPN chip has too small polyphony (6 channels), therefore it does support the ability of multi-chip (run concurrent chip emulators to extend polyphony). It's not regular MIDI synthesizer, and it does the automatical arpeggio when polyphony limit was excited (It "compresses" chords into single channels and does loop between it's notes until necessary amount of channels will be available soon). To reduce CPU load you would use MAME emulator which is balanced choice (gives well-accurate YM2612 emulation and loyal CPU use, it usually works in OPNMIDI by default). The Nuked OPN2 is very accurate chip simulator, but it eats a lot of CPU, therefore it's not recommend to use more than 3 concurrent chips of it. The GENS emulator is fastest, but it's very inaccurate and faulty (in some cases may produce distorted or even damabed sound).

EDIT: Okay, after re-listening, I can hear, it's the choppy playback, possibly, caused by CPU overload. Did you changed the chip emulator or count of chips at OPNMIDI?

EDIT2: Anyway yeah, the real-time MIDI device switch is the one of key features of SDL Mixer X fork :fox_face: :smiley:

[Wohlstand]

I'll close this issue as the question was solved. Any further comments are allowed here.

[mazmazz]

That makes sense, our game already uses a lot of CPU. I had not configured OPNMIDI beyond cmake's defaults. Do I set the number of chips and emulator only at build time, or can I change that on runtime?

[Wohlstand]

The default config of OPNMIDI is MAME and 4 chips. Mixer has set of public functions you can use to manipulate setup of OPNMIDI, and even load custom sound bank files (WOPN format). The 4 chips is the default config of OPNMIDI at Mixer here. If your MIDI files aren't exceeding 12 voices polyphony, you're can set even 2 chips for economy. Also, alternative way to control OPNMIDI - path arguments, I made them to give an ability play each MIDI file with different synt, bank, or setup, individually (Mainly intended to use with ADLMIDI and OPNMIDI). I have the article that describes how to use them (for the case when you are using file paths; but for memory or RWops I have special function that accepts arguments string separately).

[Wohlstand]

Also, you're can provide to user an ability to setup ADLMIDI / OPNMIDI synths to let use choose necessary setup. Also, some neat xxxMIDI's functions aren't bound into Mixer (like, ability to toggle full-panning mode which a new feature), then I'll add them soon.