VirtualMIDISynth 2.x - Release Candidate 2 released

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!
!!! Please enable JavaScript !!!

Pagine

Posts: 1972
Joined: 25 Mar 2012 - 01:19
VirtualMIDISynth 2.x - Release Candidate 1 released

VirtualMIDISynth 2 - Release Candidate 1 is finally available!

  • NEW: VirtualMIDISynth is now integrated with CoolSoft MIDIMapper.
  • NEW: Value of each soundfont "bank" setting can now be set to -1, which means "load all banks".
  • NEW: Added Comodo internet security to blacklisted processes.
  • NEW: Updated BASS to version 2.4.12.0, BASSMIDI to version 2.4.9.24 and BASSENC to version 2.4.13.
  • FIX: Removed wait delay if the device is already opened by the same process (added to fix Chrome bug and now useless with the new "Suppress device already opened message" option)
  • FIX: Fixed setup in case DLL or EXE is in use during install.
  • FIX: Fixed status of setup option "Autostart when setup completes" when a reboot is needed.
  • FIX: Fixed Soundfont configuration error message: now it checks for enabled soundfonts (and not configured ones only) for each device.
  • FIX: Fixed "click here to open soundfont configuration" not working on systray balloon
  • FIX: Fixed wrong resize behavior of UpDown and label controls in configurator dialog
  • FIX: Fixed crash of blacklist editor dialog when selecting running process (Win10 only)

Setup is available at first post of this thread.
I'm just finishing the new official VMS2 webpage so RC1 will be downloadable by everyone, no need to register.

UPDATE: VMS-2.0-RC1 is now available on VirtualMIDISynth page too.

Posts: 102
Joined: 8 Mar 2014 - 22:29
Re: VirtualMIDISynth 2.x - Release Candidate 1 released

BASS and BASSMIDI are pretty out-of-date.
You should upgrade them to 2.4.12.8 and 2.4.9.30 respectively.

EDIT: Also BASSenc is out-of-date, version 2.4.13.2 is out. o:

Posts: 102
Joined: 8 Mar 2014 - 22:29
Re: VirtualMIDISynth 2.x - Release Candidate 1 released

VMS 2.0 RC1 performs worse than Alpha24 and Beta1 with Black MIDIs.
Audio is horrible and not stable at all.

Video: https://www.youtube.com/watch?v=5KIQ0T2bFII&feature=youtu.be

Posts: 16
Joined: 25 Mar 2016 - 02:50
Re: VirtualMIDISynth 2.x - Release Candidate 1 released

I've installed RC1.  While I don't have any Black MIDI files to test with, I do notice some static/scratchiness every so often with just my first test.  Beta6 gave me no static, ever.  It only lasts for a second or two, and only happens periodically (unlike the video above).  One moment it tends to happen often is when I start playback of a song.  This also never happened under Beta6, which was a great improvement over the 1.XX releases where it happened constantly.  I haven't changed any settings since Beta6.  My update rate on the About tab tends to stay around 1ms.  When the static happens it's around 10ms.

This is how my main VMS settings are configured, for reference.

I see the "Realtime" setting has been removed.  It might have been gone in Beta6 and I didn't notice.  Looking at the thread priorities in Process Explorer, the dsound.dll thread appears to have the Real-time priority.  But it tends to have less of a CPU load than the two threads (presumably one for each device—playback is using two at the moment) that actually seem to be doing the work.  Is this the way Beta6 was?

I also have noticed that playback stops and the dsound.dll thread drops to 1% CPU utilization.  After a little bit, it kicks up to 12.5% and stays there.  I do not know if Beta6 did this but I thought it a bit odd and that it should be pointed out.

I really appreciate you hard work on this fantastic software.  If you have questions on the above, just let me know.

Joseph

[JJH/Jovet]

Posts: 16
Joined: 25 Mar 2016 - 02:50
Re: VirtualMIDISynth 2.x - Release Candidate 1 released

As an update to my above post: 

I tried turning off Hardware Mixing.  It helped but did not eliminate the problem.

Since the static/stuttering seemed to happen when the update rate dropped below 1ms (usually to around 10ms), I decided to try and implement a 10ms output buffer.  I have always tried to use VMS with zero buffer because latency is evil, but the 10ms buffer did eliminate the problem.  And 10ms latency seems hardly noticable.   Unfortunately I never really monitored these performance figures under Beta6 or earlier, since I never experienenced any serious problems.  I am curious what changed under the hood between Beta6 and RC1 that would exacerbate this problem, though.

Joseph

[JJH/Jovet]

Posts: 20
Joined: 10 Giu 2016 - 13:55
Re: VirtualMIDISynth 2.x - Release Candidate 1 released

I've also upgraded to the Release Candidate 1 and I'm impressed. The overloading I noticed in Beta 6 appears to have all but vanished and the dynamic contrasts seem greater than before. There also seems to be greater clarity of individual voices in the harmony. I have also just tried decreasing the latency to zero but I've started noticing clicks and thumps every so often - seems worst with Pad1 (New Age) instrumentation in NoteWorthy Composer - so I shall have to increase it somwhat. There were no extraneous noises with a setting of 60 mS so I'll try something lower than that. Since moving to version 2, I've not noticed any "continuous notes" either so it would seem that problem has been solved. From my point of view, I think the software is reaching a high degree of finesse although I appreciate that I am only using it for one specific purpose and there may still be difficulties for other users.

Johnno

Posts: 1972
Joined: 25 Mar 2012 - 01:19
Re: VirtualMIDISynth 2.x - Release Candidate 1 released

Hello everyone, thanks for your reports.
I'm actually on vacation, with a "poor" connection, that's why my replies are so delayed.

KaleidonKep99 wrote:
BASS and BASSMIDI are pretty out-of-date.
You should upgrade them to 2.4.12.8 and 2.4.9.30 respectively.

You're right, will do it in next RC2...

KaleidonKep99 wrote:
VMS 2.0 RC1 performs worse than Alpha24 and Beta1 with Black MIDIs.

Beta1 (and worst Alpha24) had a "unsafe" IPC fast queue, leading to lost events (notes) under heavy loads (BlackMIDI is one of them).
IMHO they performed "better" only because they were loosing notes on their way, so only a part of them reached the synth.
This should be the same effect as limiting maximum simultaneous notes using the related configuration option, anyway I have no data to confirm my feeling.
They also were bundled with a different version of BASS* libs, so this could be the change.
Will update them in RC2 and let's see...

Jovet wrote:
Beta6 gave me no static, ever.  It only lasts for a second or two, and only happens periodically (unlike the video above).  One moment it tends to happen often is when I start playback of a song.  This also never happened under Beta6, which was a great improvement over the 1.XX releases where it happened constantly.

There was no change at all to the synth part between Beta6 and RC1, so I suppose this could be related to BASS version (see above).

Jovet wrote:
My update rate on the About tab tends to stay around 1ms.  When the static happens it's around 10ms.

This is something I've implemented in the "less bad" way possible:
BASS needs to be updated with the incoming messages at a given rate: if the incoming data rate is higher (a complex MIDI part) then the BASS update rate must be higher too... but it will also increase CPU usage.

The most performant choice is to keep BASS update rate at a fixed 1ms rate, but this will keep the CPU busy indefinitely as long as VMS is running. Since VMS2 is almost "always-running, this is unacceptable.

The best choice is to update at 10ms and increase it to 1ms when needed but... when?
VMS is a device and it can't predict what's going to happen on its MIDI input; only the MIDI client can (i.e. a MIDI player knows thet the user pushed the Play button).
VMS2 actually raises its update speed when a note comes in and keeps it high as long as there's silence for, say, x seconds. That x was based on my experience but could be changed (or made configurable).
The better way should be having VMS update speed linked to "at least one device connected" state, but that info was not available at the time of MIDI queue writing... will have a look.

Jovet wrote:
I see the "Realtime" setting has been removed.  It might have been gone in Beta6 and I didn't notice.

That option was removed long time ago (can't check when now, but long time), now VMS has its own - REALTIME - process so there's no need to raise up the client one.

Jovet wrote:
Since the static/stuttering seemed to happen when the update rate dropped below 1ms (usually to around 10ms), I decided to try and implement a 10ms output buffer.

A 0ms output buffer is always risky, because any unpredicted event could lead to hiccups; if you're ok with 10ms leave it like that.

Posts: 16
Joined: 25 Mar 2016 - 02:50
Re: VirtualMIDISynth 2.x - Release Candidate 1 released
coolsoft wrote:
There was no change at all to the synth part between Beta6 and RC1, so I suppose this could be related to BASS version (see above).

This is something I've implemented in the "less bad" way possible:

BASS needs to be updated with the incoming messages at a given rate: if the incoming data rate is higher (a complex MIDI part) then the BASS update rate must be higher too... but it will also increase CPU usage.

The most performant choice is to keep BASS update rate at a fixed 1ms rate, but this will keep the CPU busy indefinitely as long as VMS is running. Since VMS2 is almost "always-running, this is unacceptable.

The best choice is to update at 10ms and increase it to 1ms when needed but... when?
VMS is a device and it can't predict what's going to happen on its MIDI input; only the MIDI client can (i.e. a MIDI player knows thet the user pushed the Play button).
VMS2 actually raises its update speed when a note comes in and keeps it high as long as there's silence for, say, x seconds. That x was based on my experience but could be changed (or made configurable).
The better way should be having VMS update speed linked to "at least one device connected" state, but that info was not available at the time of MIDI queue writing... will have a look.

Yes, I get what you're talking about.  What I'm seeing is that it drops down from 1ms right in the middle of playback.  I would not think it should be doing that, since it's in the middle of getting a constant stream of events. 

If that option to delay update speed fallback were configurable, I would start setting it to 10000ms and go from there.  I don't know about anyone else, but I am more than happy to sacrifice CPU time to have low latency, quality sound.

coolsoft wrote:
That option was removed long time ago (can't check when now, but long time), now VMS has its own - REALTIME - process so there's no need to raise up the client one.

Yes that makes sense, and I did not mean to imply that VMS 2 should or would have any control over the process(es) using the driver.  I was more wondering about the VMS process threads and which of them also do/should have elevated priority.

coolsoft wrote:
A 0ms output buffer is always risky, because any unpredicted event could lead to hiccups; if you're ok with 10ms leave it like that.

I did not expect eliminating the buffer to be very successful, but it worked very well for me.  Up until RC1.  The 10ms buffer has not completely eliminated the problem for me, but it is a lot more rare.

A few other notes:

I am using a chain of 6 sound fonts for all of the VMS synths.  I edited the sound fonts to put the sounds into different banks so there would be no collisions.  One of my sound fonts in the middle of the chain is a Piano, and I've noticed it doesn't seem to get invoked any longer.  I haven't seriously investigated this yet but I've wondered if anyone else has had a similar problem.

In investigating the above problem, I noticed a bug on the Edit Soundfont Properties dialog.  The Bank and Preset boxes reject typing a - sign for -1. 

I also find the button symbols on the VMS config dialog Soundfonts page to be a bit intimidating.  I wish they had Tooltips so I knew for sure what they did before I clicked on them.

Last, a feeble feature request:  How about more than four devices?

Enjoy your vacation!

Joseph

[JJH/Jovet]

Posts: 1972
Joined: 25 Mar 2012 - 01:19
Re: VirtualMIDISynth 2.x - Release Candidate 1 released
Jovet wrote:
Yes, I get what you're talking about. What I'm seeing is that it drops down from 1ms right in the middle of playback. I would not think it should be doing that, since it's in the middle of getting a constant stream of events.

I'll increase it to 30000ms.
Meanwhile: is it possible to have the MIDI showing this issue? Please post it here or privately through the contact form.

Posts: 2
Joined: 6 Set 2016 - 16:17
Re: VirtualMIDISynth 2.x - Release Candidate 1 released

Fantastic job on Version 2.0 RC1 here.  Fixed my problems with instrument volumes used above values of 96~100 volume causing distortion *AND* the stuck note issues - which were really annoying.

Working fantastic on Windows 7 x64 with my custom Regression FM (which is like a hybrid Game-blaster, soundblaster 2.0, Megadrive, Nes, C64, and even plays SNES stuff well).

I use this on my dosbox and windows games that use midi.  Sounds fantastic.  Really can't thank you enough.  I am disabled, so I have a lot of time at the PC.

I uploaded a 7zipped copy of my soundfont I've been using for a while (And a few sample midis), I've worked on it for the last 10 years and 9 months, it's a labor of love and is GM-friendly with some XG/GS instruments.  100% Chiptune.

Go on vgmusic.com and find some megaman or final fantasy stuff by TECK or KING METEOR, or choose from many of the good recent midi files.

You may put it on your site here if you'd like.  It works great for dosbox also, but let me know if there's issues with any games not sounding right.

Tested on Doom (all)  Duke (all), ROTT, Warcraft 1 & 2, Thexder, Whiplash, Liesure suit larry (the ones with midi music anyways), Heretic, Hexen, Descent (all that use midi), Transport Tycoon, SC2000, etc

This actually sounds considerably better than midi on my soundfont-supporting X-fi Titanium HD Pro PCI-E soundcard!!!

To anyone discovering this soundfont, you may use it in game production, music production, youtube videos, etc.  I don't ask for anything but credit - but if you get ritch don't forget about me :)

  -Cheers and thanks (and I will give a shout if there's any issues).

Attachments (Only registered users)
R_FM_v1.99g-beta.7z
R_FM_samplemidi.7z

Pagine