Have the latest releases of GZDoom affected Timidity++?

Discuss anything ZDoom-related that doesn't fall into one of the other categories.

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

Postby Chris » Sun Jan 14, 2018 5:51 pm

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.
User avatar
Chris
 
Joined: 17 Jul 2003

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

Postby ksio89 » Sun Jan 14, 2018 7:09 pm

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.
ksio89
 
Joined: 03 Jan 2018
Discord: ksio89

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

Postby Graf Zahl » Mon Jan 15, 2018 4:09 pm

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.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

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

Postby Graf Zahl » Mon Jan 15, 2018 4:10 pm

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.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

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

Postby Cacodemon345 » Tue Jan 16, 2018 3:34 am

The MIDIMapper was removed in Windows 8 and higher.
Cacodemon345
 
Joined: 22 Dec 2017
Discord: Cacodemon345#9151

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

Postby Chris » Tue Jan 16, 2018 10:02 am

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...>
User avatar
Chris
 
Joined: 17 Jul 2003

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

Postby Rachael » Tue Jan 16, 2018 11:11 am

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.
User avatar
Rachael
QZDoom + Webmaster
 
Joined: 13 Jan 2004

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

Postby Graf Zahl » Tue Jan 16, 2018 11:36 am

The distinction between binary and text mode is made inside the CRT. I do not know the specifics that decide which is being set.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

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

Postby Jerry.C » Thu Jan 18, 2018 11:50 am

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.
Jerry.C
 
Joined: 06 Jan 2018

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

Postby Graf Zahl » Thu Jan 18, 2018 3:57 pm

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.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

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

Postby Cacodemon345 » Fri Jan 19, 2018 1:08 am

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.
Cacodemon345
 
Joined: 22 Dec 2017
Discord: Cacodemon345#9151

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

Postby _mental_ » Fri Jan 19, 2018 1:22 am

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.
_mental_
 
 
 
Joined: 07 Aug 2011

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

Postby Cacodemon345 » Fri Jan 19, 2018 1:23 am

Fluidsynth is less error-resistant.
Cacodemon345
 
Joined: 22 Dec 2017
Discord: Cacodemon345#9151

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

Postby Graf Zahl » Wed Feb 21, 2018 2:48 pm

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.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

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

Postby Kotti » Thu Feb 22, 2018 2:36 am

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.
Kotti
 
Joined: 27 Dec 2016

PreviousNext

Return to General

Who is online

Users browsing this forum: Yandex [Bot] and 7 guests