You are here
Home › Forum home › VirtualMIDISynth › Announcements & news › VirtualMIDISynth 2.1 - Release Candidate 2 ›VirtualMIDISynth 2.1 - Release Candidate 2
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!Pages
- easyaspi314
- Posts: 5
- Joined: June 1, 2017 - 21:05
- Kj
- Posts: 51
- Joined: April 25, 2016 - 12:19
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.
- maxverri
- Posts: 10
- Joined: March 3, 2017 - 20:18
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
- easyaspi314
- Posts: 5
- Joined: June 1, 2017 - 21:05
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
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.
- coolsoft
- Posts: 1978
- Joined: March 25, 2012 - 01:19
easyaspi314 wrote:In testing this, I decided to program the player to fire a MIDI panic signal (0xB0x7C 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".
- coolsoft
- Posts: 1978
- Joined: March 25, 2012 - 01:19
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.
- easyaspi314
- Posts: 5
- Joined: June 1, 2017 - 21:05
coolsoft wrote:easyaspi314 wrote:In testing this, I decided to program the player to fire a MIDI panic signal (0xB0x7C 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
- easyaspi314
- Posts: 5
- Joined: June 1, 2017 - 21:05
Coolsoft, is this maybe a 32-bit exclusive bug?
It would be weird, but you never know.
- coolsoft
- Posts: 1978
- Joined: March 25, 2012 - 01:19
@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.
- coolsoft
- Posts: 1978
- Joined: March 25, 2012 - 01:19
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
Navigation
Login
Support me
Click here if you want to support CoolSoft using PayPal