Page 2 of 3

Re: Have the latest releases of GZDoom affected Timidity++?

PostPosted: Sun Jan 14, 2018 5:51 pm
by Chris
Graf Zahl wrote:Maybe someone should take the time and reapply the ZDoom specific changes to this more recent code base.

What changes does ZDoom actually need to apply to Timidity++? As far as I could tell, in the past (way in the past) it wanted some kind of built-in kill switch, an object in the Timidity++ process that ZDoom could peak at and map into its own process where it could then signal to tell Timidity++ to quit. However I don't think it uses that anymore since non-ancient Windows versions have more appropriate ways to remotely kill the process.

I think it also wanted some kind of volume control too in the cases where Timidity++ is outputting the audio on its own, but that's not relevant anymore either since the output is piped back to ZDoom to stream through the sound system.

I'd actually be a bit surprised if the kind of inter-process memory prodding ZDoom used to do with Timidity++ actually even still works, though even if it does it's not likely the right thing to do.

Re: Have the latest releases of GZDoom affected Timidity++?

PostPosted: Sun Jan 14, 2018 7:09 pm
by ksio89
Graf Zahl wrote:Here's just a warning: The Windows MIDI player is considered deprecated. It may just disappear so you'd no longer be able to use a system driver for MIDI playback. It may not be obvious but that thing is actually a problem that may have to be removed eventually.

And if Timidity++ wasn't such a gigantic clusterfuck of badly written code I might have included it into GZDoom by now. This stuff is the epitome of using pure C in a context where OOP may be advised and overdepends on global variables to make the code completely useless.


But what does VirtualMIDISynth have to do with Windows MIDI player? I just can't see how CoolSoft's MIDI drivers depends on Windows sytem MIDI drivers. It has it own drivers and I have to choose my own soundfont, the same one used with TiMIDIty++. CoolSoft has also released a MIDIMapper drivers for Windows 8/10, but I don't know what it's supposed to do.

Re: Have the latest releases of GZDoom affected Timidity++?

PostPosted: Mon Jan 15, 2018 4:09 pm
by Graf Zahl
Chris wrote:I'd actually be a bit surprised if the kind of inter-process memory prodding ZDoom used to do with Timidity++ actually even still works, though even if it does it's not likely the right thing to do.



It never did any 'prodding'. What it did was to create an event that could be accessed from both processes. But it does indeed no longer work and support for it has long been removed from ZDoom several years ago.
This isn't the main issue. What necessitates the special compile is that the Timidity developers forgot to set stdout to binary mode when piping back the wave data to the calling process.

Re: Have the latest releases of GZDoom affected Timidity++?

PostPosted: Mon Jan 15, 2018 4:10 pm
by Graf Zahl
ksio89 wrote:
Graf Zahl wrote:Here's just a warning: The Windows MIDI player is considered deprecated. It may just disappear so you'd no longer be able to use a system driver for MIDI playback. It may not be obvious but that thing is actually a problem that may have to be removed eventually.

And if Timidity++ wasn't such a gigantic clusterfuck of badly written code I might have included it into GZDoom by now. This stuff is the epitome of using pure C in a context where OOP may be advised and overdepends on global variables to make the code completely useless.


But what does VirtualMIDISynth have to do with Windows MIDI player?


It uses the same Windows system API - and that API is actually part of the problem with native MIDI playback because it looks like it got hopelessly stuck in the distant past.

Re: Have the latest releases of GZDoom affected Timidity++?

PostPosted: Tue Jan 16, 2018 3:34 am
by Cacodemon345
The MIDIMapper was removed in Windows 8 and higher.

Re: Have the latest releases of GZDoom affected Timidity++?

PostPosted: Tue Jan 16, 2018 10:02 am
by Chris
Graf Zahl wrote:What necessitates the special compile is that the Timidity developers forgot to set stdout to binary mode when piping back the wave data to the calling process.

I see. I guess there isn't a way to make the process spawn with stdout in binary mode? What about using a named pipe? e.g.
Code: Select allExpand view
ReadWavePipe = CreateNamedPipe("\\.\pipe\zdoom_timidity.raw", PIPE_ACCESS_INBOUND, PIPE_TYPE_BYTE | PIPE_NOWAIT, ...);

// then launch timidity...
timidity.exe -o \\.\pipe\zdoom_timidity.raw <other flags...>

Re: Have the latest releases of GZDoom affected Timidity++?

PostPosted: Tue Jan 16, 2018 11:11 am
by Rachael
Keep in mind that it is, and always has been possible to spawn multiple GZDoom processes. If you're going to do a named pipe you better attach a process ID or something to it, too, in order to force it to be unique.

Re: Have the latest releases of GZDoom affected Timidity++?

PostPosted: Tue Jan 16, 2018 11:36 am
by Graf Zahl
The distinction between binary and text mode is made inside the CRT. I do not know the specifics that decide which is being set.

Re: Have the latest releases of GZDoom affected Timidity++?

PostPosted: Thu Jan 18, 2018 11:50 am
by Jerry.C
Yay, Timidity++.

My main gripe with this program has been forever that it was designed to do everything regarding MIDI, yet no decent documentation exists, and trying to recompile it always ends up in a mess because nobody got the slightest clue what parts need to be combined to get what you want.

For example, apparently there is code in there that would allow streaming MIDI events through a pipe - if someone got it to work first. This doesn't seem to be part of any preexisting configuration aside from the autotools config so we are out of luck again. The included MSVC projects are perfectly useless, meaning that it is close to impossible to get it set up to a state where it at least works and someone can continue developing from that point onwards. If that obstacle could be overcome it should be perfectly doable to plug the synth into GZDoom as a library which would nullify most of the issues the current setup causes.

Re: Have the latest releases of GZDoom affected Timidity++?

PostPosted: Thu Jan 18, 2018 3:57 pm
by Graf Zahl
Jerry.C wrote:Yay, Timidity++.

My main gripe with this program has been forever that it was designed to do everything regarding MIDI, yet no decent documentation exists, and trying to recompile it always ends up in a mess because nobody got the slightest clue what parts need to be combined to get what you want.


Welcome to the club. I really don't know how many times I have tried to make some sense of this code but there's so little information and the code nearly impenetrable that it's probably hopeless.

Re: Have the latest releases of GZDoom affected Timidity++?

PostPosted: Fri Jan 19, 2018 1:08 am
by Cacodemon345
There is no real chance to plug Timidity++ into GZDoom without it's developers cleaning up the mess. My advice would be to use FluidSynth, but it is also a mess of badly-written code that will make it crash with some soundfonts.

Re: Have the latest releases of GZDoom affected Timidity++?

PostPosted: Fri Jan 19, 2018 1:22 am
by _mental_
If you found the issue then report it to developers. For FluidSynth I got a response in a few hours and reported crash was fixed in a day or so.

Re: Have the latest releases of GZDoom affected Timidity++?

PostPosted: Fri Jan 19, 2018 1:23 am
by Cacodemon345
Fluidsynth is less error-resistant.

Re: Have the latest releases of GZDoom affected Timidity++?

PostPosted: Wed Feb 21, 2018 2:48 pm
by Graf Zahl
I may just post it here instead of starting a new thread about it.

The external solution to use Timidity++ is no longer needed and supported, I spent the last few weeks adjusting the Timidity++ source to be usable as an internal Midi synth, that can be driven by GZDoom itself, just like all the other options. I think this will solve all the problems people have been experiencing in the past.

I plan to do a few changes to the sound font setup now that there is a real chance to unify the handling across the different synths because the Timidity++ executable with its almost insane conventions is no longer a factor.

Re: Have the latest releases of GZDoom affected Timidity++?

PostPosted: Thu Feb 22, 2018 2:36 am
by Kotti
Cool!

This is a really nice surprise. Timidity++ has always been the odd thing out here with its clumsy setup. Good to see that it now has become a first class option for MIDI music playback.

One question: Seeing that both the GUS and WildMidi options are merely inferior variations of this, will they stay or be removed? And what about FluidSynth? It's different enough to not throw it in the same basket but on the other hand it is different in not particularly good ways, of the available MIDI synths it is by far the worst sounding, often even being outclassed by OPL.