One of 3 Programs Not Initiating When VirtMIDISynth Is Installed

Posts: 1
Joined: September 13, 2017 - 14:39
One of 3 Programs Not Initiating When VirtMIDISynth Is Installed

My school district is licensing several software programs...more in future. All NEW computers ...All Windows 10. All programs were installed individually on each workstation (28) and we're in desperate need (due to latency issues) of CoolSoftVirtualMIDISynth.... a program that might be the most stable I've had through Windows XP and Windows 7.

https://sonicscores.com/score-writer/  ....works when compatibility mode is set to Windows 7

https://Synthesiagame.com works when set to Windows 7

(Oh, when set to Win7, the Midi Mapper Settings of older versions show up...the selections...even though it is on Win10 computer with latest version of CoolSoftMIDI)

Ok, so the issue is with http://harmonicvision.com/forms/demoform.php   (MusicAce) ... the icon on task bar for VirtualMIDI pops up but error message appears and program never opens. If we uninstall CoolSoft ... it opens but we need your program to reduce unnacceptable latency.  Here is the conflict error message our I.T. rep obtained...he's contacting HarmonicVision and wanted me to contact you here. The HarmonicVision people of course think it's this MIDI software and not them but they're looking into it. Again, the entire conflict / error between Music Ace and VirtualCoolSoft MIDI  (attached as a file -txt file)

Attachments (Only registered users)
Virtual synth error.txt
Posts: 1125
Joined: March 25, 2012 - 01:19
Re: One of 3 Programs Not Initiating When VirtMIDISynth Is Installed

I've debugged the calls done by MAgp.exe to VMS driver and saw something strange.
This is somehow technical so please forward it to your IT and/or HarmonicVision people if needed (or let them know about this thread).

This is what I see on my side (VirtualMIDISynth.dll MIDI driver):

12:40:22.162: [DRIVER] DllMain: DLL_PROCESS_ATTACH, client=C:\Program Files (x86)\Harmonic Vision\Music Ace Demo\MAgp.exe
12:40:22.162: [DRIVER] DriverProc: DRV_LOAD
12:40:22.163: [DRIVER] DriverProc: DRV_ENABLE
12:40:22.163: [DRIVER] DriverProc: DRV_OPEN
12:40:22.165: [DRIVER] DriverProc: DRV_OPEN
12:40:22.165: [DRIVER] DriverProc: DRV_CLOSE
12:40:22.195: [DRIVER] modMessage: MODM_GETDEVCAPS, device #0, dwParam2 = 84
12:40:22.212: [DRIVER] modMessage: MODM_GETDEVCAPS, device #0, dwParam2 = 84
12:40:22.212: [DRIVER] modMessage: MODM_GETDEVCAPS, device #0, dwParam2 = 132
12:40:22.353: [DRIVER] modMessage: MODM_OPEN, device #0
12:40:22.513: [DRIVER] modMessage: MODM_CLOSE, device #0
12:40:23.676: [DRIVER] modMessage: MODM_GETDEVCAPS, device #0, dwParam2 = 84
12:40:23.677: [DRIVER] modMessage: MODM_GETDEVCAPS, device #0, dwParam2 = 84
12:40:23.678: [DRIVER] modMessage: MODM_GETDEVCAPS, device #0, dwParam2 = 132
12:40:23.678: [DRIVER] modMessage: MODM_OPEN, device #0
12:40:23.683: [DRIVER] modMessage: MODM_CLOSE, device #0
12:40:24.040: [DRIVER] modMessage: MODM_GETDEVCAPS, device #0, dwParam2 = 132
12:40:24.041: [DRIVER] modMessage: MODM_GETDEVCAPS, device #0, dwParam2 = 132
12:40:24.360: [DRIVER] modMessage: MODM_GETDEVCAPS, device #0, dwParam2 = 84
12:40:24.360: [DRIVER] modMessage: MODM_GETDEVCAPS, device #0, dwParam2 = 132
12:40:24.519: [DRIVER] modMessage: MODM_GETDEVCAPS, device #0, dwParam2 = 84
12:40:24.519: [DRIVER] modMessage: MODM_GETDEVCAPS, device #0, dwParam2 = 84
12:40:24.520: [DRIVER] modMessage: MODM_GETDEVCAPS, device #0, dwParam2 = 132
12:40:24.521: [DRIVER] modMessage: MODM_OPEN, device #0
12:40:24.532: [DRIVER] modMessage: MODM_CLOSE, device #0
12:40:24.859: [DRIVER] modMessage: MODM_GETDEVCAPS, device #0, dwParam2 = 132
12:40:24.860: [DRIVER] modMessage: MODM_GETDEVCAPS, device #0, dwParam2 = 132
12:40:25.381: [DRIVER] modMessage: MODM_GETDEVCAPS, device #0, dwParam2 = 84
12:40:25.382: [DRIVER] modMessage: MODM_GETDEVCAPS, device #0, dwParam2 = 84
12:40:25.383: [DRIVER] modMessage: MODM_GETDEVCAPS, device #0, dwParam2 = 84
12:40:25.385: [DRIVER] modMessage: MODM_GETDEVCAPS, device #0, dwParam2 = 84
12:40:25.385: [DRIVER] modMessage: MODM_GETDEVCAPS, device #0, dwParam2 = 132
12:40:25.385: [DRIVER] modMessage: MODM_OPEN, device #0
12:40:25.397: [DRIVER] modMessage: MODM_CLOSE, device #0
12:40:25.740: [DRIVER] modMessage: MODM_OPEN, device #0
12:40:25.749: [DRIVER] modMessage: MODM_GETDEVCAPS, device #0, dwParam2 = 84
12:40:25.750: [DRIVER] modMessage: MODM_GETDEVCAPS, device #0, dwParam2 = 132
12:40:25.750: [DRIVER] modMessage: MODM_OPEN, device #0
12:40:25.752: [DRIVER] modMessage: MODM_CLOSE, device #0         <--- LAST DEVICE CLOSE
12:40:26.084: [DRIVER] modMessage: MODM_GETDEVCAPS, device #0, dwParam2 = 84
12:40:26.086: [DRIVER] modMessage: MODM_GETDEVCAPS, device #0, dwParam2 = 84
12:40:26.089: [DRIVER] modMessage: MODM_SETVOLUME, device #0
12:40:26.091: [DRIVER] modMessage: MODM_DATA    <--- DEVICE IS CLOSED HERE, MIDI CLIENT CAN'T SEND DATA
12:40:26.091: [DRIVER] modMessage: MODM_DATA    <--- DEVICE IS CLOSED HERE, MIDI CLIENT CAN'T SEND DATA
12:40:26.091: [DRIVER] modMessage: MODM_DATA    <--- DEVICE IS CLOSED HERE, MIDI CLIENT CAN'T SEND DATA
12:40:26.091: [DRIVER] modMessage: MODM_DATA    <--- DEVICE IS CLOSED HERE, MIDI CLIENT CAN'T SEND DATA
12:40:26.091: [DRIVER] modMessage: MODM_DATA    <--- DEVICE IS CLOSED HERE, MIDI CLIENT CAN'T SEND DATA

What seems strange to me is the fact there's a lot of OPEN/CLOSE calls, like more than one thread is talking with the same MIDI device.
This is acceptable, no problems with that.

The error comes when MIDI client sends a MODM_DATA on a closed device (last line): this is not allowed and out of specifications.
It never happened with any other MIDI client AFAIK.

Maybe other virtual devices (like Microsoft GM Synth) could tolerate this, because they do not need to initialize/deinitialize lot of data (so they simply discard MODM_OPEN/MODM_CLOSE messages).
VirtualMIDISynth requires the device to be opened before accepting any data, after MODM_OPEN it loads soundfonts, starts audio device and so on.

As a workaround I've tried adding a safety check to remove the crash when a MODM_DATA message is received on a closed device.
Now MAgp.exe don't crash anymore, anyway no sound is generated by VMS because there's no soundfont loaded and the device is not properly initialized (in fact it's closed...).
So leaving that safety check in place is useless because it removes the crash but still makes the device unusable.

Again, lots of MODM_DATA/MODM_LONGDATA messages are sent by the MIDI client (some Black-MIDI tracks generate hundreds messages per second) so I'd like to keep them as fast as possible.

warning

Warning, JavaScript is disabled!

JavaScript is not available, maybe because you disabled it globally into your browser settings or you are using an addon like NoScript.

We do not have any dangerous JavaScript running here.
Please enable JavaScript; if you're using NoScript this image will help you adding CoolSoft to your whitelist.

Thanks for your comprehension and enjoy CoolSoft.