VirtualMIDISynth 2.x - Release Candidate 2 released

coolsoft wrote:

v.2.0.0-beta5 - 2016-02-05
 
FIX: Fix for Chrome bug "Device already opened": now the message is delayed if the locking process has the same PID than the one trying to reopen the driver (replaces the similar workaround added in beta4)

 
Sorry to have to say this, but the Chrome bug has returned. Its there again in both VMS 2.0.0-beta4-chromebug and beta5 
I've been away for a week. When I got back, the pesky dialog started to appear again when I switch my keyboard on/off.
 
Thinking that Chrome must have changed their code, I reported the bug again at: https://code.google.com/p/chromium/issues/detail?id=580522
 
toyoshim now says:
 

toyoshim wrote:

Hum.... sorry, I noticed that Chrome actually could open the same port that Chrome already opened. But this is intended, and needed to enumerate new devices as accurately as possible.
VMS shows a dialog but this isn't a right direction, I think. Win32 API does not forbid to open the same port twice explicitly. Returning MMSYSERR_ALLOCATED looks an expected driver's behavior as other drivers do.

notator wrote:

toyoshim wrote:

Hum.... sorry, I noticed that Chrome actually could open the same port that Chrome already opened. But this is intended, and needed to enumerate new devices as accurately as possible.

VMS shows a dialog but this isn't a right direction, I think. Win32 API does not forbid to open the same port twice explicitly. Returning MMSYSERR_ALLOCATED looks an expected driver's behavior as other drivers do.

VMS actually (and correctly) returns MMSYSERR_ALLOCATED, after that warning message box.

I've added it because a lot of MIDI clients I've tried silently skip using the device in case it's in use, leading to silent audio.
In such situation user is not aware that something is going wrong, then he/she will start changing config, moving settings around and so on...

Maybe it's an overrated idea of mine, but before removing it completely I'll try another way: will compare PID (as actually I do) or the ProcessName.
If any of these is the same, I'll skip the message.

Otherwise I'll add a "Don't show this again" checkbox to the MessageBox, so users affected by this "double opening" can discard it easily.

Will release a dedicated beta soon...

Maaaybe. Toyed around with a ton of sf2 intruments and the GUI eventually just stopped adding stuff to the list.

coolsoft wrote:

notator wrote:

Sorry to have to say this, but the Chrome bug has returned. Its there again in both VMS 2.0.0-beta4-chromebug and beta5.

I've been away for a week. When I got back, the pesky dialog started to appear again when I switch my keyboard on/off.

coolsoft wrote:

before removing it completely I'll try another way: will compare PID (as actually I do) or the ProcessName.
If any of these is the same, I'll skip the message.

Attached here an hot-fixed beta5-chrome version with the new Chrome fix.
Please check it out...

The dialog is still appearing, but at longer time intervals.

It consistently appears 3 times when I turn the keyboard off, and 6 times when I turn the keyboard on. In both cases there is a 5-6 second delay before the first dialog appears, and between the dialog appearances. When I've clicked the last dialog away, I can continue to work normally. The keyboard works fine.

I've also (rarely) experienced the dialog appearing (once) out of the blue while working on something unrelated. For me at least, the dialog is just an unnecessary disturbance.

Thanks for your patience! :-)

notator wrote:

That sounds like a very good idea! :-) -- Or, maybe even better, add an option for this in Configuration/options.

Both of them, if possible: a "Don't show this again" checkbox into MessageBox and a "Suppress already open device message" into config, both linked to the same setting.
This way it'll be easier both to hide and restore that message.