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...