[Win32] Low-level DirectMusic MIDI driver #6787
Conversation
michicc
force-pushed
the
dmusic_win64
branch
3 times, most recently
from
aa1eb24
to
7294d76
Compare
src/music/dmusic.cpp
Outdated
|
|
||
| /* Some songs change the "Pitch bend range" registered parameter. If | ||
| * this doesn't get reset, everything else will start sounding wrong. */ | ||
| for (int ch = 0; ch < 16; ch++) { |
There was a problem hiding this comment.
Wouldn't it be better to simply move this loop into TransmitNotesOff as well?
src/music/dmusic.cpp
Outdated
| clock->GetTime(¤t_time); | ||
|
|
||
| /* Check for volume change. */ | ||
| static int volume_throttle = 0; |
src/music/dmusic.cpp
Outdated
|
|
||
| /* If we couldn't load the file from the registry, try again at the default install path of the GM DLS file. */ | ||
| if (dls_file.instruments.size() == 0) { | ||
| static const TCHAR *DLS_GM_FILE = _T("%windir%\\drivers\\gm.dls"); |
There was a problem hiding this comment.
This is wrong in both Windows 10 and Windows Me, and presumably also everything in between. %WINDIR%\System32\drivers\GM.DLS should be correct, also on 64 bit systems.
There was a problem hiding this comment.
Indeed, I think I had that right and then made some last-minute changes.
src/music/dmusic.cpp
Outdated
| return "Failed to activate port"; | ||
| } | ||
| } | ||
| const char *dls = LoadDefaultDLSFile(GetDriverParam(parm, "dls")); |
There was a problem hiding this comment.
This will likely fail on hardware synths, or really any time not using the default port. Should probably be guarded with pIdx < 0. (Haven't actually tested this yet.)
There was a problem hiding this comment.
LoadDefaultDLSFile is specifically checking for DLS support in the synth.
|
Update pushed. |
|
Smoke testing is positive, can also confirm it works with hardware synth. |
|
Updated to solve some delay issues at music start. |
| _fputts(OTTD2FS(buffer, true), stderr); | ||
| TCHAR system_buf[512]; | ||
| convert_to_fs(buffer, system_buf, lengthof(system_buf), true); | ||
| _fputts(system_buf, stderr); | ||
| #else |
There was a problem hiding this comment.
It makes sure that if you call DEBUG from a thread, it doesn't trash the global string buffer that is used by OTTD2FS.
src/fileio_func.h
Outdated
|
|
||
| /** Auto-close a file upon scope exit. */ | ||
| class FileCloser { | ||
| FILE *_f; |
There was a problem hiding this comment.
Our naming convention reserves the _ prefix for globals. I know that's wrong but should we maintain consistency?
| /** The buffer object collects the data to sent. */ | ||
| static IDirectMusicBuffer *_buffer = NULL; | ||
| /** List of downloaded DLS instruments. */ | ||
| static std::vector<IDirectMusicDownload *> _dls_downloads; |
There was a problem hiding this comment.
Do these globals need to be separate from the _playback variable?
There was a problem hiding this comment.
Do they need to? No. The DMusic interfaces are global in the current driver, so I just went with that.
…BUG() to make the call thread-safe.
…th a low-level driver that directly works with MIDI data. This allows using different music sources besides standard MIDI files on disk.
…ithout relying on high-level functions.
This is a re-write of the DirectMusic driver to only rely on low-level functionality that is still present, even on 64-bit Windows systems. It only uses header files that are still present in the current Windows SDK and does not need any of the files from OTTD useful.
It would be an alternative to #6774 and makes #6779 obsolete. The DirectMusic software synth is different from the normal system one, but I'm not sure this is reason enough to keep DirectMusic around.