VirtualMIDISynth 2.x alpha available for testing

Please let our ADS show!

This sites offers only FREE software and it's supported by a few advertisement boxes (no intrusive popups).
Please:

  • disable your AdBlocker by adding CoolSoft website to whitelist
  • give the proper cookie consent
  • enable JavaScript for this website

This seconds wait is to let you update your browser configuration...

Ok, I've done the required changes... now show me your content!
!!! Please enable JavaScript !!!

Pages

Posts: 1972
Joined: March 25, 2012 - 01:19
CoolSoft VirtualMIDISynth 2.0.0-alpha16 released

Just released Alpha16, with some quick fixes:

v.2.0.0-alpha16 - 2015-06-25

  • NEW: Confirmation dialog, shown when VirtualMIDISynthAdd is being closed, now shows active clients process names and PIDs.
  • FIX: Lowered fast-mode threshold level, it now switches to 1ms update rate even with non-intensive MIDIs to avoid stuttering.
  • FIX: Disable Mixer VUMeter option is not applied live.
  • FIX: Increased watchdog timeout from 2 to 5 seconds, to avoid false positives when playing black MIDIs.
Ray890 wrote:
if virtualmidisynth lags hard enough, the synth gives up until it is restarted

Should be fixed now; watchdog timeout was too short leading to false-positives.
Now it could lag a bit more before detaching.

Ray890 wrote:
Seemingly new to this version, I hear a bit of random stuttering during non-intensive playback; The "update rate" is 10ms during these points, as opposed to 1ms

Should be fixed now; alpha16 will easily switch to 1ms update rate (VMS1 is always at 1ms, so there should not be a problem and, maybe, I'll definitely remove this switching and fix update rate to 1ms...)

Ray890 wrote:
If you re-openVirtualMIDISynth.exe immediately (within 0.25 seconds?) after you tell it to exit via taskbar menu, a message saying "Another instance of VirtualMIDISynth is already running, but can't find it" shows then keeps an invisible VirtualMIDISynth process open, rendering VMS unusable until the invisible process is killed manually

Can't reproduce it, really ;)
I tried to close and reopen it as fast as I can but I've never deadlocked it.
I also tried with an external exe that sends a close to existing and opens a new one, but I've never seen that "Another instance..." message (which was added just in the remote case a deadlock happens).

Ray890 wrote:
If a VirtualMIDI port is requested while no VirtualMIDISynth.exe process is open, it will open but the requested port doesn't get used until the port is re-requested

VirtualMIDISynth.exe is started when the first VMS device is opened, and this happens when the first MIDI client sends the MODM_OPEN message to the driver.
So it all depends on how much the client can wait for the driver to get back from that call (which is supposed to return quickly).
Some will wait indefinitely (i.e. VanBasco) someothers give up marking the port as unusable.
VMS startup is already as fast as possible, so this could be fixed (from beta versions on) by configuring VirtualMIDISynth.exe to start at logon.

Meanwhile, if you tell me which is the MIDI client that have issues when VirtualMIDISynth.exe is not already started I'll have a look at it...

Posts: 59
Joined: April 19, 2014 - 06:23
Re: CoolSoft VirtualMIDISynth 2.0.0-alpha16 released

Alright, first off, both the "VMS Port doesn't open when VMS process is not running" and the "Re-opening the VMS process rapidly causes stuck invisible process" bugs seem to be fixed as I can no longer reproduce them.
 
I still can reproduce the "Another instance of virtualmidisynth ..but can't find it" message if I launch the virtualmidisynth.exe file more than once rapidly (eg. ~0.15 second in between) with the process initially closed, but really it isn't anything to worry about because it creates nothing except for that message and the situation is rather unrealistic.
 
 
 
Now, I see the "giving up" issue is a little less of an occurance than before, but it still happens.  I've found a MIDI file that seems to cause the VirtualMIDISynth2 to give up even while sounding completely normal during playback (to be opened with Tmidi64/Tmidi, it takes a long time to open with VanBasco's Karaoke Player), as attached here, along with Tmidi64.mid: https://drive.google.com/open?id=0ByIDTUMUvYUWUktGWVJwYmEzTTA (Warning, MIDI file is ~2GB when uncompressed/extracted)

- Main laptop: Sager NP4658, Intel i7-4810MQ, 2*8GB DDR3 (PC3-10700), 512GB+512GB SSDs, Intel HD4600/NVidia GT840M

Posts: 26
Joined: March 12, 2013 - 16:35
Re: CoolSoft VirtualMIDISynth 2.0.0-alpha16 released

Claudio, there is one thing that is buggy for sure, Preloading the soundfont into memory.

It's been buggy since I remember.

No matter what bank I use as long as the bank is not put in a real RAMDisk, VMS is droping occasionaly a notes during playback.

I can reproduce this on each version.

Using ANY 3rd party RAMDisk software, for example "SoftPerfect RAM Disk" - completely fixed that problem.

I think I need to do a video demonstrating this problem as this bug bothers me for a while.

Ray890: please try to use a real ramdisk software for testing that the "giving up" issue.

I've found it that using preloaded sound bank into a real RAMdisk helped me to cure A LOT of weird VMS's problems.

Just untick "Preloading the soundfont into memory." when bank is preloaded into a RAM to avoid unnecessary second preloading.

Posts: 59
Joined: April 19, 2014 - 06:23
Re: CoolSoft VirtualMIDISynth 2.0.0-alpha16 released
supergod wrote:

Ray890: please try to use a real ramdisk software for testing that the "giving up" issue.

I've created a 3GB ramdisk and I've placed my soundfont in there along with disabling Preload, no improvement, then I put the MIDI Player (tmidi64.exe), the midi file (red zone giant mode.mid) along with the soundfont; the issue is still happening.  Here's some video footage I've created of the latter situation:  https://drive.google.com/open?id=0B2mBT1sJj4cobG1PRkFMZ3BkaHM&authuser=0

- Main laptop: Sager NP4658, Intel i7-4810MQ, 2*8GB DDR3 (PC3-10700), 512GB+512GB SSDs, Intel HD4600/NVidia GT840M

Posts: 59
Joined: April 19, 2014 - 06:23
Re: CoolSoft VirtualMIDISynth 2.0.0-alpha16 released

Update:  Actually I found out Alpha16 still has that "VMS process opens but fails to open port on MIDI Player's request" bug, but I figured out the cause of it.  In order for this to happen, you need to choose the option to have 2, 3, or 4 VirtualMIDISynth devices, as opposed to just one.

- Main laptop: Sager NP4658, Intel i7-4810MQ, 2*8GB DDR3 (PC3-10700), 512GB+512GB SSDs, Intel HD4600/NVidia GT840M

Posts: 1972
Joined: March 25, 2012 - 01:19
Re: CoolSoft VirtualMIDISynth 2.0.0-alpha16 released
Ray890 wrote:
I still can reproduce the "Another instance of virtualmidisynth ..but can't find it" message if I launch the virtualmidisynth.exe file more than once rapidly (eg. ~0.15 second in between) with the process initially closed

Got it, and fixed. Thanks!

Ray890 wrote:
I've found a MIDI file that seems to cause the VirtualMIDISynth2 to give up even while sounding completely normal during playback

Just tested it and I suppose the bottleneck here is TMidi64.
When VMS watchdog closed the device, on my testing machine, TMIDI64.exe was stuck at 25% (quadcore CPU, so 100%) while VirtualMIDISynth.exe was at 10% and no note came in for more than 4 seconds (as seen on MIDI mixer activity LEDs).
I don't have another x64 MIDI player to test with, could you suggest something?

supergod wrote:
Using ANY 3rd party RAMDisk software, for example "SoftPerfect RAM Disk" - completely fixed that problem.

That's a good workaround.
VMS doesn't directly manage soundfont loading/preloading, BASS libs do.
Preloading is just an additional step called to BASS library during soundfont load.
I think it's better to post this question on Un4seen forum together with a real test case; Ian Luck is really active there (and he's also a very kind person).
Ray890 already asked for other optimizations and they were included in BASSMIDI.dll updates.

Ray890 wrote:
If a VirtualMIDI port is requested while no VirtualMIDISynth.exe process is open, it will open but the requested port doesn't get used until the port is re-requested
Ray890 wrote:
In order for this to happen, you need to choose the option to have 2, 3, or 4 VirtualMIDISynth devices, as opposed to just one.

Still can't reproduce, but this won't be an issue anymore when users would be able to autostart VMS with windows.
Anyway, could you please post the exact sequence of operations to reproduce it?

Posts: 59
Joined: April 19, 2014 - 06:23
Re: CoolSoft VirtualMIDISynth 2.0.0-alpha16 released

Alright, I've done further testing and I've gotten some better information regarding the two bugs I've found

  • Regarding the giving up issue, I get the giving up situation even in the middle of playing notes as can be seen in my video footage.  There is obviously no 4 second pause between notes before the giveup occurs, in fact there is no lag indicated at all (CPU usage of Tmidi64 and virtualmidisynth processes were at ~8% [out of 13]), when played with my i7 laptop.  I'd say, that MIDI file with TMidi64 is best used on Windows 7 (NOT Windows 8+ due to performance bottlenecks), as well as a good CPU. Even with my i3 laptop, it does perform poorly to the point where there is a 2 second gap between notes (still not 4 seconds) and the giving up thing happens over there too.

    It doesn't seem like TMidi is the cause of the watchdog timeout, because I've specifically done extreme throttling (99.9%-100%) on the TMidi process specifically for even a minute during intense black midi playback, and when I unthrottled it the port still held on and played normally.  This isn't limited to just 64-bit MIDI programs, I've been also able to reproduce this with 32-bit TMidi, but not as quick just due to the lesser note traffic caused by the 512 track limit of that version.  Lastly I should also mention, I was using stock settings when reproducing this bug.
     

  • Turns out I was incorrect on my assumption on how to re-produce the "requested port doesn't initialize" problem.  Rather, here's how to produce the bug:
    1. Open a MIDI program, start playing a midi or whatever, and keep the port used by it
    2. While the port is still used, exit VirtualMIDISynth from the systray and press continue on the message saying the port is in use
    3. Open another MIDI program and get it to request a port, VirtualMIDISynth will open but the port remains free, cease and re-request the port with the second program while VMS is open, then the second program will use and play on the port.

One more thing, Alpha16 seems to still sometimes set the bass update rate to 10ms occasionally during super-light loads with voices still active but it's much less often than Alpha15, I still hear the stuttering sound each time it happens.

- Main laptop: Sager NP4658, Intel i7-4810MQ, 2*8GB DDR3 (PC3-10700), 512GB+512GB SSDs, Intel HD4600/NVidia GT840M

Posts: 4
Joined: July 15, 2015 - 23:15
Re: CoolSoft VirtualMIDISynth 2.0.0-alpha16 released

http://i.imgur.com/zAQPsNP.png

I get this weird, see-through, click-through GUI with latest alpha.

OS is WinXP SP3.

 

This driver is already better than the 1.x branch.

No more pesky slowdown at playback start with WinGroove player(this app runs inside NTVDM).

 

Edit:

I take the slowdown thing back. Still happens, but it's less drastic than with the 1.x branch.

So far, this seems to be the only driver that does this with WinGroove. Bassmidi Driver, by contrast, keeps proper tempo.

Same effect also happens in Crescendo! browser plugin when sending midi to CoolSoft synth(win32 NPAPI)

https://a.pomf.cat/omcsjo.ogg

http://justnopoint.com/felineki/midi/kuyashii.mid

Posts: 59
Joined: April 19, 2014 - 06:23
Re: CoolSoft VirtualMIDISynth 2.0.0-alpha16 released
turkeybaster5723 wrote:

So far, this seems to be the only driver that does this with WinGroove. Bassmidi Driver, by contrast, keeps proper tempo.

Same effect also happens in Crescendo! browser plugin when sending midi to CoolSoft synth(win32 NPAPI)

https://a.pomf.cat/omcsjo.ogg

http://justnopoint.com/felineki/midi/kuyashii.mid

Just out of curiousity, do you happen to still get this slowdown with VMS2 if you change the "additional output buffer" setting to 0?  That, or otherwise turning off the preload function might do the trick too.

- Main laptop: Sager NP4658, Intel i7-4810MQ, 2*8GB DDR3 (PC3-10700), 512GB+512GB SSDs, Intel HD4600/NVidia GT840M

Posts: 1972
Joined: March 25, 2012 - 01:19
Re: CoolSoft VirtualMIDISynth 2.0.0-alpha16 released

@All: sorry for the long silence, I was reading all of your messages anyway.

Ray890 wrote:
Regarding the giving up issue, I get the giving up situation even in the middle of playing notes as can be seen in my video footage.

That file (red zone giant mode.mid) was perfect to find what's wrong, a deadlock of IPC queue.
The messages queue deadlocks at about 1:00 from start and no more messages are trasmitted from player to synth; player is waiting for new free slots and synth is waiting for new data, both at 0% CPU, so the watchdog stops everything.
Now I fixed it, but I'm still working on some queue optimizations...

Ray890 wrote:
Turns out I was incorrect on my assumption on how to re-produce the "requested port doesn't initialize" problem. Rather, here's how to produce the bug...

This sequence lead me to reproduce bug on my side BUT I'm still investigating on how it could be better solved.
My first thought was to not allow VirtualMIDISynth.exe to close if some device is still open, to avoid crashing (or at least freezing) the connected MIDI client(s).
But what if a client crashes (or was killed by task manager leaving the device open)? VirtualMIDISynth cannot be closed.
So I added that warning message, where the Continue option should be the "last resort" to close VirtualMIDISynth.
Once closed, clients left open will continue sending messages (to nowhere) without crashing.

Now I need a way for the client to detect synth has been closed, other than testing it before sending each message (bad performance).

I suppose the actual behavior is a good compromise between performances and reliability.
Once user forcibly close the synth he/she should prepared for any kind of malfunction, like the "requested port doesn't initialize" you reported.

Ray890 wrote:
One more thing, Alpha16 seems to still sometimes set the bass update rate to 10ms occasionally during super-light loads with voices still active but it's much less often than Alpha15, I still hear the stuttering sound each time it happens.

As I said, VMS 1.0 always run at 1ms. I added 10ms-1ms switch because some clients open the device just after loading it, without using it.
Since this is a third party malfunction (and also a big waste of CPU) I decided to add this detection to switch to 1ms only when really needed.
Actually I lowered the threshold limit so low that any minimal activity will switch to 1ms.

turkeybaster5723 wrote:
I get this weird, see-through, click-through GUI with latest alpha.
OS is WinXP SP3.

That misbehaviour is due to your Windows appearance configuration: you selected Windows classic in both "Windows and buttons" and "Color scheme" boxes in Desktop | Properties | Appearance tab, like this:
http://www.theeldergeek.com/images/HT2_003/SP32-20040709-140751.gif

This combination deactivates Windows Compositing Layer, which helps Windows in drawing complex dialogs with hardware supported transparency layers.
I'll have a look for a workaround but, honestly, I don't think there could be any and, also, I think this Windows classic configuration is not so "popular"... ;)

Pages