VirtualMIDISynth 2.x alpha available for testing

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: 1536
Joined: March 25, 2012 - 01:19
Re: CoolSoft VirtualMIDISynth 2.0.0-alpha19 released

Good, thanks for reporting it.

Will see if I can add a "warning" when loaded soundfonts will lead to memory overflow...

Posts: 1536
Joined: March 25, 2012 - 01:19
CoolSoft VirtualMIDISynth 2.0.0-alpha20 released

Quick release to add customizable blacklist feature: it is now possible to add custom items to the client blacklist, to avoid selected executables to load the driver (i.e.: chrome.exe, firefox.exe, ...).
This feature could help Chrome users to workaround "MIDI port already in use" bug.

NOTE: actually the feature doesn't have a GUI to set it.
Custom items must be added manually to configuration file VirtualMIDISynth.conf, section [Advanced] key ClientBlacklist.
Multiple items can be added by separating them with a semicolon:

[Advanced]
...
ClientBlacklist=program1.exe;program2.exe
...

v.2.0.0-alpha20 - 2015-08-30

  • NEW: User can now add custom exe names to driver blacklist. These blacklisted executables won't load VirtualMIDISynth anymore.
    NOTE: actually there's no GUI for this feature, custom names must be manually added to VirtualMIDISynth.conf file, section "[Advanced]", key "ClientBlacklist".
  • NEW: Updated BASSMIDI to 2.4.9.12.
  • FIX: Optimized configuration parser.
Posts: 59
Joined: April 19, 2014 - 06:23
Re: CoolSoft VirtualMIDISynth 2.0.0-alpha20 released

I've discovered two bugs that stand out in the recent alpha builds:

1. VirtualMIDISynth lag can cause infinately sustained notes in playback

2. Quickly closing and re-opening a MIDI port (eg. Changing song position in Vanbasco's) while the queue is full can cause an infinate looping sound until VMS is closed

Both of these are demonstrated here: https://drive.google.com/open?id=0B2mBT1sJj4coYXFIWEl3SWtSekk

 

Starting with Alpha18 you said having a full queue should return MMSYSERR_NOTREADY to the MIDI player; I'm having doubts that this is actually working as intended, as queue-induced slowdowns aren't affecting the MIDI player's playback speed at all.  This can partly be seen with the above video, but especially when I throttle VirtualMIDISynth.exe's execution speed: https://drive.google.com/open?id=0B2mBT1sJj4coX3Zza1ZfbjFoekE

Also, I think seeing a piece of realtime information about the VMS MIDI queue in the about page would be nice to have, or at least indicate whenever it's full or not.

 

I'm still having doubts that VMS2's rendering is truely multithreaded yet, as getting one VMS port to slowdown is causing the rest of the ports to slow down too: https://drive.google.com/open?id=0B2mBT1sJj4coMUdJQ2FEcFZ5bUE

 

 

Lastly, a new BassMIDI dll, version 2.4.9.13 has been released!  Not only does it raise the maximum voice limit to 2000, but it completely solves the clicking sound you get when voices are killed, a major win for sound quality with complex MIDIs, can you update again to this version for the next Alpha build?

If you do expand the voice limit option to support up to 2000, you might want to put some hinting "performance warning" indication of some sort, such as changing the setting's label color from black to orange as soon as the user inputs >1000 in the setting's textbox.

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

Posts: 1536
Joined: March 25, 2012 - 01:19
Re: CoolSoft VirtualMIDISynth 2.0.0-alpha20 released
Ray890 wrote:
Starting with Alpha18 you said having a full queue should return MMSYSERR_NOTREADY to the MIDI player; I'm having doubts that this is actually working as intended, as queue-induced slowdowns aren't affecting the MIDI player's playback speed at all.
Ray890 wrote:
1. VirtualMIDISynth lag can cause infinately sustained notes in playback

That's true, and I confirm it but it's up to the player decide what to do when receiving a MMSYSERR_NOTREADY.
Most of them (if not all...) go on, discarding the failure.
This leads to sustained notes because NOTEOFF messages were lost, because of full queue, and not resent by the player.
From VMS point of view, it received a NOTEON and never received the corresponding NOTEOFF.

Ray890 wrote:
2. Quickly closing and re-opening a MIDI port (eg. Changing song position in Vanbasco's) while the queue is full can cause an infinate looping sound until VMS is closed

I can confirm that VanBasco does not close/reopen the device when scrubbing back and forth, it only sends a lot of NOTEOFF events (or a full NOTEOFF, I don't remember now) to ensure everything is silenced before moving to the new position.
Once moved, it send all the initialization and SYSex messages of the song till that position; think about a controller change that happens in the middle of a song, it must be re-sent if you're scrubbling after that point.

In case of a full queue these messages are discarded and VanBasco is notified with a MMSYSERR_NOTREADY.
But if it does not retry to send these messages... we have the sustained notes effect.

Ray890 wrote:
I'm still having doubts that VMS2's rendering is truely multithreaded yet, as getting one VMS port to slowdown is causing the rest of the ports to slow down too

Rendering is not multithreaded, all of the BASS MIDI streams are updated by the same thread. Queue messaging and MIDI rendering are on 2 different cores.
But sonce all of these actors share the same shared-memory resources, being it full-separated-multithreading have some limits.
Making it multithread requires some work/synchronization/testing and I still wonder if it worths a try.
What's the point in having two distinct songs filling two cores of a CPU? ;)

Ray890 wrote:
BassMIDI dll, version 2.4.9.13 has been released!  ... can you update again to this version for the next Alpha build?

Done, and increased voices limit to 2000 too.

Posts: 102
Joined: March 8, 2014 - 22:29
Re: CoolSoft VirtualMIDISynth 2.0.0-alpha20 released

I actually made a tool that brings back the good ol' MIDI Mapper under Windows 8.x and Windows 10.

https://www.youtube.com/watch?v=MZ4k7ndR1Nc

You should make a checkbox that allow users to set the MIDI-Mapper settings, regardless they're using Windows 7 or not; the MIDI-Mapper setting is STILL present on Windows 8, but it can't be read because of the missing code.

Posts: 1536
Joined: March 25, 2012 - 01:19
Re: CoolSoft VirtualMIDISynth 2.0.0-alpha20 released

I've seen the video twice but I haven't found the tool (or the patch), just a player playing some black MIDIs...

Did I miss something?

Posts: 102
Joined: March 8, 2014 - 22:29
Re: CoolSoft VirtualMIDISynth 2.0.0-alpha20 released

I made the tool by myself, it's here:

Direct link: https://goo.gl/eJc3H3

Posts: 102
Joined: March 8, 2014 - 22:29
Re: CoolSoft VirtualMIDISynth 2.0.0-alpha20 released

Ops, I noticed that now. You wanted a VIDEO of the patch. Lel.

Here: https://www.youtube.com/watch?v=0Cn7Spfqx0w

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

This leads to sustained notes because NOTEOFF messages were lost, because of full queue, and not resent by the player.
From VMS point of view, it received a NOTEON and never received the corresponding NOTEOFF.

I suspected that to be the case.  However, if the queue system is staying this way, can there be something in place to work around this (Eg. All-note-off after a full queue)?  Not only does this give an odd song sustain impression that doesn't sound right, but this reduces performance with lower performance systems when rendering time limit is disabled: https://drive.google.com/open?id=0B2mBT1sJj4coRHljWnczZC1nMG8

coolsoft wrote:

I can confirm that VanBasco does not close/reopen the device when scrubbing back and forth, it only sends a lot of NOTEOFF events (or a full NOTEOFF, I don't remember now) to ensure everything is silenced before moving to the new position.

It seemed like it was the case, because each time I queue tracks on Vanbasco's backwards, it requests the cloased VMS2 process to open as if a new port connection is being made.

I don't think you understood the second bug I reported about the infinate loop; basically whenever I scrub the track backwards on Vanbasco's during a point of playback when the VMS queue is really full, it causes an infinate looping sound that persists until the VirtualMIDISynth.exe process is closed.  Upon further investigation, the source of the bug seems to be previous instances of the 'vms queue' thread getting terminated improperly before the next instance of the thread gets generated.  https://drive.google.com/open?id=0B2mBT1sJj4cob0k2bXJrTkw5RHc

coolsoft wrote:

Rendering is not multithreaded, all of the BASS MIDI streams are updated by the same thread. Queue messaging and MIDI rendering are on 2 different cores.
But sonce all of [the ports] share the same shared-memory resources, being it full-separated-multithreading have some limits.

Yeah, that wasn't a very good example from my part.  What I've really been thinking more about is the fact that CPU usage during load is only reaching a 13-14% maximum rather than 18-25% like I expected.  This to me indicated that the queue was mostly sharing the same core as the BassMIDI rendering as opposed to being processed separately on two cores like you said.  However, I've done additional testing using thread affinities and found it indeed it uses 2 cores, but it only makes use of up to 40-60% of them.  https://drive.google.com/open?id=0B2mBT1sJj4coa21tOHRfTHF2YWs

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

Posts: 1536
Joined: March 25, 2012 - 01:19
Re: CoolSoft VirtualMIDISynth 2.0.0-alpha20 released
KaleidonKep99 wrote:
Ops, I noticed that now. You wanted a VIDEO of the patch. Lel.

Yes, because I'm going to release a "real" MIDIMapper for Windows 8/10 and I wondered if it will compete with yours...

Now I see you're adding the old (Win7) winmm.dll to the folder of the being-patched program, is it?
This should work because Windows Multimedia is almost abandoned by Microsoft, so they won't change it anymore..
Beware only about the licensing of the Win7 dll you're distributing...

 

Pages