VirtualMIDISynth 2.x alpha available for testing

Please let our ADS show!

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

  • 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 !!!


Posts: 16
Joined: 4 Set 2014 - 17:34
Re: CoolSoft VirtualMIDISynth 2.0.0-alpha13 released

Curiously, what's the odds of rigging up player-based master volume?  I don't know if it's a BASS limitation or VMS, but adjusting the volume of whatever player you happen to be using - whether that's a MIDI playback program like PotPlayer or an emulator like DOSBox - has no effect at all.  Individual channel volumes are clearly working, since you can hear fades and what have you as expected, and both a MIDI event and MIDI controller message exist to alter the master volume of a MIDI device; though whether or not these messages are being sent or not is debatable.

I would hope that such a thing could be implemented in tandem with VMS/individual SoundFont volumes, though.  Timbres of Heaven 3.1 seems to be quite loud and I've had to dial it back to 30% to get it balanced with wave output.

Posts: 26
Joined: 12 Mar 2013 - 16:35
Re: CoolSoft VirtualMIDISynth 2.0.0-alpha13 released
coolsoft wrote:

It's not just about speed, it's the requirement of a public IP address (or at least natting VisualStudio debugger port to your PC).
And, again, timezone differences...

Not a problem again, we are on the same time zone as well.

coolsoft wrote:

I really agree and, looking at source code, I still wonder how it could happen... ;)

My first thought was that VMS is not playing, but how you could explain working volume slider inside VMS :P

Posts: 102
Joined: 8 Mar 2014 - 22:29
Re: CoolSoft VirtualMIDISynth 2.0.0-alpha13 released
coolsoft wrote:
KaleidonKep99 wrote:
So, why you don't make a 64-bit version too?

Actually the driver already has 2 versions, x86 and x64.
Unlike VMS1, VMS2 drivers are lightweight and not linked to BASS libs; the only component linked to BASS is the synth that, actually, is x86.
So the setup only contains the x86 version of BASS.

My initial VMS2 thought was to drop the x86 synth version completely and replace it with an x64 one.
Driver will still have both x86 and x64 versions, both communicating with the same x64 synth.

Let's see the different options (dual driver version requirement is actually unavoidable because most MIDI software is still x86):

x86 synth, x86+x64 drivers (current)

  • VMS2 will still run on every system, from XP to Win8, both x86 and x64
  • can be used by x86 and x64 MIDI programs
  • easier to mantain/test/debug
  • has SF memory limit

x64 synth, x86+x64 drivers:

  • still a single version of the synth to mantain/debug
  • no SF memory limit
  • can still be used by x86 and x64 MIDI programs

x86+x64 synths, x86+x64 drivers:

  • the number of components to mantain/test/debug will raise to 4: 2 drivers + 2 synths
  • must include both BASS dll versions to setup


As you can see, making 2 versions of the synth has some drawbacks I'd like to avoid; most of all I'm worrying about testing all of the x86-x64 combinations.

Anyway, nothing is still decided; I'd like to have some feedback from users... but I think most of them will came here when we'll reach the first beta.
I still have a couple of features to add to alpha, then we'll enter the beta stage.

My idea is to actually install only ONE synth basing on the operating system and the RAM.

Guy A is using a 64-bit PC with 4GB of RAM and Windows x64, the setup will automatically install the x64 synth and both x32 and x64 drivers.
Guy B is using a 64-bit PC with 4GB of RAM and Windows x32, the setup will inform the user that he's using a 64-bit PC, but not a 64-bit version of Windows, and it will automatically install the x32 synth and the x32 driver.
Guy C is using a 32-bit PC with 4GB of RAM and Windows x32, the setup will automatically install the x32 synth and the x32 driver.
Guy D is using a 64-bit PC with 2GB of RAM and Windows x64, the setup will automatically install the x32 synth and both x32 and x64 drivers.

That's what I was saying before, and I think it's a nice feature to the setup.

Posts: 1782
Joined: 25 Mar 2012 - 01:19
Re: CoolSoft VirtualMIDISynth 2.0.0-alpha13 released

Yes, I got it.

But that means I must build/test/debug both versions of the synth (one more than now) and both versions of the driver.
This leads to 1 more build (x64 synth) and 2 more testing setups (x86 driver-->x64 synth + x64 driver-->x64 synth).
That's what I'd like to avoid ;)

Finally all the 4 components have to be included in setup; making 2 different setup files will be a nightmare so it's not an option.

UPDATE: I'm not saying a big NO, I'm just waiting to see if it's really a show-stopper feature (I hear a voice saying "do it, do it... ;)").

Posts: 1782
Joined: 25 Mar 2012 - 01:19
CoolSoft VirtualMIDISynth 2.0.0-alpha14 released

v.2.0.0-alpha14 - 2015-05-26

  • NEW: All settings changes can now be applied live.
  • NEW: Mixers can now be kept always on-top (through mixer context menu).
  • NEW: Option to set CPU usage limit.
  • NEW: Option to enable dynamic voices limit control.
  • NEW: Option to release only the last occurrence of a note when voices limit is reached.
  • NEW: Option to enable "sinc interpolation" (BASS_MIDI_SINCINTER flag).
  • NEW: Status box (into About tab) now auto updates its content when needed.
  • NEW: Added OS, memory, MIDI client and active voices info to Status box.
  • FIX: Improved soundfonts loading and their assignment to devices.
  • FIX: An error message is now shown when a soundfont file fails to load.
  • FIX: Fixed painting issues when resizing configurator dialog under Win8.
  • FIX: Fixed detection of WinXP-x64 that hasn't SP3 available.
  • FIX: Fixed linker parameter that prevented VMS running on XP
Posts: 59
Joined: 19 Apr 2014 - 06:23
Re: CoolSoft VirtualMIDISynth 2.0.0-alpha14 released

The added "CPU Usage limit" and "dynamic voice limit" settings doesn't seem right at all to me in this release.  In my testing, I found that all the "dynamic voice limit" does is set the voice limit to 200, as confirmed by testing this on both an intel atom and i7.  Setting a value in the "CPU usage limit" setting seems to do nothing at all.

I think you mis-interpreted what I said when I was talking about the bass_cpu_limit suggestion and I'm not surprised.  Basically, the "BASS_ATTRIB_CPU" statistic flag (this could as well be useful to have under about too btw) refers to the bassmidi CPU Usage according to Ian, but in reality it's more of a indicator of processing timeliness is (eg. =50% meaning bassmidi has twice the headroom, >100% meaning it exceeded the headroom).  I was imagining a processing percentage limiter option in a form of a combo box using the flags "BASS_CONFIG_MIDI_CPU" or "BASS_ATTRIB_MIDI_CPU".  Voices will get killed when the "CPU" usage exceeds the specified level (it's still normal for usage to still go a little above the limit).

Also, I think the information in the about page could use a little raise in update frequency, like 8 times per second to match the mixer's.


Otherwise very nice work, everything else works fine and I especially like the new live setting change improvements.  There's one setting that fails to update live though, which is the "disable mixer vu meter" option.


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

Posts: 1782
Joined: 25 Mar 2012 - 01:19
Re: CoolSoft VirtualMIDISynth 2.0.0-alpha14 released

After completing the Dynamic voices limit and CPU limit features and using them for a while I actually consider them almost... useless.

Dynamic voices limit initial purpose was to automatically limit the CPU usage by incrementally decreasing the configured max voices option down to, say, 200, and increasing BASS update frequency.
Sadly, each time the voices count limits is reduced, the change can be heard clearly: suppose you're decreasing from 1000 to 900, it means that 100 notes will be silenced together.
So the decrease should be done in small steps, say 10 per cycle; again, levels should be kept for a while (hysteresis) to avoid jumping continuously up and down between them.

A well-done algorithm to obtain this result could consume a lot of CPU time, more than the one it saves by reducing voices limit.
So I decided to "test" it with only two levels: default mode (voices limit set by the user, say 1000, and 50ms update time) and "fast mode" (fixed 200 limit and 10ms update time).
When the algorithm decides it's time to decrease, the "fast mode" is kept for at least 5 seconds.

Rethinking about it I see that the only useful thing to keep is the tuning of update time: raising it helps BASS rendering the high number of incoming notes to play and, when the number of incoming notes decreases it can be safely lowered to save CPU.
Also, changing update frequency can be easily done without being heard.

In next version I'll change the algorithm as described and remove the Dynamic voices limit option (will be active by default).

CPU limit is obscure and useless, like the way BASS calculates it.. so I'll remove it.

Finally, I'll increase the status box update frequency but I wonder if this will affect synth on low-end machines.
Maybe a selectable frequency like slow-high and enable its updating only when the tab is active...

Posts: 59
Joined: 19 Apr 2014 - 06:23
Re: CoolSoft VirtualMIDISynth 2.0.0-alpha14 released

Honestly, to impliment my limiter, all I did was is add one line to it: BASS_ChannelSetAttribute(chan,BASS_ATTRIB_MIDI_CPU,95); //"CPU" limit = 95%

And I've got myself a very good automated function that helps prevent the "CPU" (BASS_ATTRIB_CPU) statistic from going higher than 1000 and doesn't have a very noticible side-effect: You can try it here:

In fact, Ian suggested that using that specific flag is your way to go.

And honestly, until it's been tested by multiple people like me, I disagree with the idea of making a such usage limiting system default especially if there's no option to disable it.

PS many blackers like to squeeze the most absolute performance they can get out before they start to lag/stutter


If you can't get this figured out, just forget this whole idea alltogether for now.

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

Posts: 1782
Joined: 25 Mar 2012 - 01:19
Re: CoolSoft VirtualMIDISynth 2.0.0-alpha14 released

Oh no no, I was not clear enough. I was not thinking to acrtivate the voices limit by default but:

  • change my algorithm so it only increases the update rate when needed, without touching the voices limit, and get back to default when the notes storm has been finished (or the user plays a standard MIDI). HIgh update rate (BASS_Update() calls) is the part that consumes much CPU, so I'll raise it frequency only when needed, maybe counting the number of notes received in the last update period).
  • voices limit will get back to a static configuraton option (like it was till alpha13): MIDI blackers know what they do and have high-performing machines... they don't need a "dynamic" help ;)

I'm already using BASS_ATTRIB_MIDI_CPU to set CPU limit, but it doesn't bring any noticeable difference, even when setting it to 10% or lower.
What almost all mid-level users expect (I'm excluding those who hardly know what the TaskManager is) from something called CPU limit is that, if they set it to 80%, when looking at the TaskManager they won't see VirtualMIDISynth.exe go higher than 80% (or 40% on dual core systems, but that's another story).
Actually it's not like that and, honestly, I'm the first having some doubts on how it works... will check it again.

Posts: 59
Joined: 19 Apr 2014 - 06:23
Re: CoolSoft VirtualMIDISynth 2.0.0-alpha14 released

I think this whole situation would be much less confusing if you added this as a statistic to the about page (Its probably a useful statistic to keep nonetheless): BASS_ChannelGetAttribute(chan,BASS_ATTRIB_CPU,&cpu); // get "CPU" usage

Because I repeat, the whole MIDI_CPU limit is really based on that particular statistic, I would trust looking at that more than task manager's own graph (even when dividing 100 by the amount of threads your cpu has to be the mental maximum usage).  Along with that statistic, feel free to provide a setting that'll manipulate BASS_ATTRIB_MIDI_CPU (of course with alpha13 behavior being default setting) in the next alpha if you think this could use a bit more experimentation before we give up.

Again, you may want to check out my "MIDITest Mod" program as I also linked in my last post, by default it has a MIDI_CPU limit set at "95", and it works very well at keeping the xx% statistic below 100 therefore the song continue, so it may demonstrate what results I expected, actually this version will give you the comparision between having the midi_cpu limit and no limit as well as extra-responsive gui updates for readability: 


The update rate increase (even to 24 per second) didn't seem to impact cpu usage on my MIDITest-mod by much, but you said it did for yours, so is it possible that you can also do the gui updates on a new thread so it'll not conflict with bassmidi's engine performance so this isn't much of a problem in the first place?

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