VirtualMIDISynth 2.1 - Release Candidate 2

It seems you're using an AdBlocker or JavaScript is disabled!

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

This 10 seconds wait is to let you update your AdBlocker whitelist...

Got it, show me the content...
Please enable JavaScript!

Pages

Posts: 5
Joined: June 1, 2017 - 21:05
Re: VirtualMIDISynth 2.1 - Release Candidate
coolsoft wrote:
Can you confirm you're in sleep mode (PC almost powered off except RAM, cannot remove power/battery) and not in hybernate mode (everything saved to disk, you can safely remove power and/or battery)?

Actually, I take that back. It has nothing to do with sleep mode or anything. I have been noticing that I have to keep connecting and disconnecting to VMS from my editor to get sound output, and it disconnects randomly when the window is in the background.

I did recently update my editor to an unstable version, so I'll try an older version that I know works to be sure.

I'll update my post when I get a reliable result.

Update: An older version of MidiEditor (the program I used) still appears to have the issue, yet Anvil Studio works fine from initial tests.

I checked "Override incoming MIDI SYSEX events" and it worked. Unchecked it, and after switching, it didn't work. It may be a coincidence, but what baffles me is that there were no SYSEX events in the MIDI file.

Wait. I tried changing the "Bank" option on the soundfonts a while ago, and changing them all to 0 made it work again. Messing around with values makes me think I found the culprit: Even if it is disabled, setting the Bank option to -1 causes this odd issue.

A side note: It looks like your website resources aren't working properly at the moment. I am looking at a plain HTML site right now. It seems on and off.

Posts: 47
Joined: April 25, 2016 - 12:19
Re: VirtualMIDISynth 2.1 - Release Candidate
coolsoft wrote:
coolsoft wrote:
Well, there seem to be an issue in open/close detection ;)

There was a bug in IPC connection between client and server: under some conditions the server wrongly thinks that the client has disconnected.

Now fixed, wait RC2 for it.
Thanks both for reporting it ;)

Another possibly partially related issue I've noticed the this latest release candidate. Whilst playing a MIDI file and opening the VMS MIDI Mixer, I muted all tracks and then unmuted a couple of tracks for cloer listening. When the MIDI file is stopped and played again, the track muting in the MIDI Mixer has no effect, all tracks are played. So I unmuted all tracks and then start muting tracks again and the muting starts to work again.

http://kiwi6.com/artists/GEN_MIDI

Posts: 10
Joined: March 3, 2017 - 20:18
Re: VirtualMIDISynth 2.1 - Release Candidate

Hello Claudio,

I resolved my trouble. I just need open as first Cubase, and after Winlive. About Winlive is the 7.0.10 version. Cubase is an old simple version I use just for edit the text, insert the chords, and some personal change about the sounds.

As always, THANKS CLAUDIO, it's amazing what you are doing for us!!!!!

Have nice holidays!!!

Massimo Vernucci

coolsoft wrote:
I'm actually on vacation, so it's hard for me to test something.
    Anyway I'll ask some clarifications to get ahead whan I'll get back home.
  
      easyaspi314 wrote:
  
    
Whenever the computer goes into sleep mode (seemingly with a program connected to it), it seems that VMS stops working. I have to quit out and restart VMS to make it work.

Can you confirm you're in sleep mode (PC almost powered off except RAM, cannot remove power/battery) and not in hybernate mode (everything saved to disk, you can safely remove power and/or battery)?
  
      maxverri wrote:
  
    
I have to close Winlive 7, because it use all device of VMS and there is no way to deactivete the devices inside it.

2.1-RC2 is supposed to let each MIDI client program to access all of the VMS virtual devices.
    Can you confirm you're using that version?
    If yes, can you post the specific version numbers of Cubase and Winlive7 you're using?

maxverri wrote:

Hi Claudio,

as always THANKS for you great job!! I want purpose my situation. I use Winlive 7 for my job on Win 7. Many times I need open Cubase for edit midi files and even with the new release, I have to close Winlive 7, because it use all device of VMS and there is no way to deactivete the devices inside it. So to open and work with Cubase I need close Winlive 7. I'm doing something wrong?

Thanks in advance for everything you are doing!!!

Massimo Vernucci

Posts: 5
Joined: June 1, 2017 - 21:05
Re: VirtualMIDISynth 2.1 - Release Candidate

OK, so I found something interesting about the whole "not connecting/staying connected" thing.

I have determined via experiment that everything before was a coincidence.

I put the "Available devices" window next to my MidiEditor window, and when switching the output ports, the status screen showed that about 80% of the time, the connection would show up and then disconnect after about a second for no apparent reason.

However, if I disable the playback halt in the settings and switch the output port while the MIDI file is playing, the connection appears to remain stable.

In testing this, I decided to program the player to fire a MIDI panic signal (0xB 0x7C 0x7F, 0xB 0x78 0x00) immediately after setting the output port and it seems to be a temporary fix for the dropped connection.

Is the issue some sort of idle timeout firing too early?

That would make some sort of sense. My theory is that there is an idle timeout, but it doesn't get properly reset because of the multiple connections. As a result, the port is always at the timeout cutoff. I don't reboot/shut down often, which may also be a part of it.

For reference, MidiEditor uses RtMidi in C++, which in turn uses WinMM.

I do not get this issue with Microsoft GS Wavetable Synth.

Posts: 1542
Joined: March 25, 2012 - 01:19
Re: VirtualMIDISynth 2.1 - Release Candidate
easyaspi314 wrote:
In testing this, I decided to program the player to fire a MIDI panic signal (0xB 0x7C 0x7F, 0xB 0x78 0x00) immediately after setting the output port and it seems to be a temporary fix for the dropped connection.

Is the issue some sort of idle timeout firing too early?

The two components of VMS2 (driver and synth) continuously send messages one another, to ensure each part is still alive and not disappeared unexpectedly.
If the driver is not playing (device was opened and paused), it blindly sends a "PING" message every 2 seconds to say "I'm alive".

So there should not be any timeout, unless the driver is loaded and "freezed" for some reason.
Could you please check the CPU usage when the device disconnects?
Look at MidiEditor.exe and VirtualMIDISynth.exe CPU usages and also note that on a 4-cores system a 25% CPU means "all the CPU time".

Posts: 1542
Joined: March 25, 2012 - 01:19
Re: VirtualMIDISynth 2.1 - Release Candidate
Kj wrote:
Another possibly partially related issue I've noticed the this latest release candidate. Whilst playing a MIDI file and opening the VMS MIDI Mixer, I muted all tracks and then unmuted a couple of tracks for cloer listening. When the MIDI file is stopped and played again, the track muting in the MIDI Mixer has no effect, all tracks are played. So I unmuted all tracks and then start muting tracks again and the muting starts to work again.

Some players close/reopen the device on stop/play and newly opened device instances missed to set volume/mute state.
Fixed in next RC3, thanks for reporting it.

Posts: 5
Joined: June 1, 2017 - 21:05
Re: VirtualMIDISynth 2.1 - Release Candidate
coolsoft wrote:
easyaspi314 wrote:
In testing this, I decided to program the player to fire a MIDI panic signal (0xB 0x7C 0x7F, 0xB 0x78 0x00) immediately after setting the output port and it seems to be a temporary fix for the dropped connection.

Is the issue some sort of idle timeout firing too early?

The two components of VMS2 (driver and synth) continuously send messages one another, to ensure each part is still alive and not disappeared unexpectedly.
If the driver is not playing (device was opened and paused), it blindly sends a "PING" message every 2 seconds to say "I'm alive".

So there should not be any timeout, unless the driver is loaded and "freezed" for some reason.
Could you please check the CPU usage when the device disconnects?
Look at MidiEditor.exe and VirtualMIDISynth.exe CPU usages and also note that on a 4-cores system a 25% CPU means "all the CPU time".

Nothing seems to go over ~15% and I have a dual-core PC.

However, it does seem to disconnect within roughly 2 seconds.

I have attached in a split archive, the installer EXE for my compiled version of the MidiEditor program (tell me if you run into any issues) without the panic workaround, and the System Information dump. Make sure to put them all in the same folder and remove the extra ".7z" in each file extension. So instead of "info-and-midiedior.7z.001.7z", it is "info-and-midiedior.7z.001". You should then be able to extract it with 7-Zip.

This is compiled as 32-bit, so it may have issues on 64-bit. It runs with Qt 5.9.0, but it should be bundled with the installer.

Assuming everything works, you should be able to launch the program, then go to Midi -> Settings -> Midi I/O and check the box next to VirtualMidiSynth.

The system info.nfo should show my specs if you double-click it.

Edit: I was using Version 2.1.1 of RTMidi when I compiled that. I updated to the latest master branch version (3.0.0). Nothing appeared to change.

Also, I compiled this with MinGW 5.3.0, but compiling with Visual Studio 2015 (Qt doesn't support Visual Studio 2017 for 32-bit which is frustrating) doesn't fix the issue.

Attachments (Only registered users)
info-and-midieditor.7z.001.7z
info-and-midieditor.7z.002.7z
info-and-midieditor.7z.003.7z
Posts: 5
Joined: June 1, 2017 - 21:05
Re: VirtualMIDISynth 2.1 - Release Candidate

Coolsoft, is this maybe a 32-bit exclusive bug?

It would be weird, but you never know.

Posts: 1542
Joined: March 25, 2012 - 01:19
Re: VirtualMIDISynth 2.1 - Release Candidate

@Doug Kerr

It seems that watchdog timeout is too short for some programs.
While testing Overture I saw that it opens MIDI device very early at startup (so the device is set as used by Overture.exe), then it does a huge lot of initialization things keeping the CPU high enough to let the watchdog thread (which is a low priority thread) fail, then - after the initialization completes - I receive watchdog messages at server side but at that time the connection has been killed.

The watchdog is only a safety belt: is a way to detect when a MIDI client crashes or stop unexpectedly and free the used device.
I don't like to raise its thread priority so I've increased its delay up to 8 seconds in RC3.

@easyaspi314

I haven't tested your software yet, but I suppose it has the same bug as above.
Since I'm releasing RC3 in a while, please test it on your side and report if the issue is fixed or not.

Posts: 1542
Joined: March 25, 2012 - 01:19
VirtualMIDISynth 2.1 - RC3

VirtualMIDISynth-2.1-RC3 has been released (see first post):

  • NEW: About tab now shows full statistics for each virtual device.
  • NEW: Updated BASSMIDI.dll to version 2.4.11.0.
  • FIX: Current channels volume/mute state is not applied to newly opened device instances.
  • FIX: Increased watchdog timeout to avoid disconnection of long startup clients.

Pages