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: 4
Joined: July 15, 2015 - 23:15
Re: CoolSoft VirtualMIDISynth 2.0.0-alpha16 released
Ray890 wrote:

Just out of curiousity, do you happen to still get this slowdown with VMS2 if you change the "additional output buffer" setting to 0?  That, or otherwise turning off the preload function might do the trick too.

The additional buffer thing did the trick, yes.

coolsoft wrote:

That misbehaviour is due to your Windows appearance configuration: you selected Windows classic in both "Windows and buttons" and "Color scheme" boxes in Desktop | Properties | Appearance tab, like this:
http://www.theeldergeek.com/images/HT2_003/SP32-20040709-140751.gif

This combination deactivates Windows Compositing Layer, which helps Windows in drawing complex dialogs with hardware supported transparency layers.
I'll have a look for a workaround but, honestly, I don't think there could be any and, also, I think this Windows classic configuration is not so "popular"... ;)

Oh wow, WTF.

This is hilarious.

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

This sequence lead me to reproduce bug on my side BUT I'm still investigating on how it could be better solved.
My first thought was to not allow VirtualMIDISynth.exe to close if some device is still open, to avoid crashing (or at least freezing) the connected MIDI client(s).
But what if a client crashes (or was killed by task manager leaving the device open)? VirtualMIDISynth cannot be closed.
So I added that warning message, where the Continue option should be the "last resort" to close VirtualMIDISynth.
Once closed, clients left open will continue sending messages (to nowhere) without crashing.

The problem I kind of have with this is that I sometimes go on WebMIDI powered websites, those that may or may not make actual use of VirtualMIDISynth for example, however due to a bug (that I reported here), chrome keeps every device's ports open until every chrome.exe process is closed, and I tend to not close or restart chrome all that often.

My concept of a solution could have something to do with this, how about there could be a temporary process blacklist that could be automatically and instantly generated by detecting processes are already requesting the VMS driver (excluding the process request that triggered VMS to load as well as processes already on the main blocklist) right before the actual synth component loads up.

- 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
CoolSoft VirtualMIDISynth 2.0.0-alpha17 released

VirtualMIDISynth 2.0.0-alpha17 was just released, download link is in first post.
No new features, only bug fixes and improvements.

v.2.0.0-alpha17 - 2015-07-22

  • FIX: Fixed "Another instance of VirtualMIDISynth is already running..." bug when quickly restarting more than one instance of the synth.
  • FIX: Lowered update FAST mode threshold: 1ms update rate is now active for most of the time.
  • FIX: FAST mode now stays on for at least 10 seconds once activated.
  • FIX: IPC MIDI queue deadlock with really fast rate MIDI traffic.
  • FIX: Optimized MIDI queue efficiency.

---------

I still have a couple of new features to add:

  • WASAPI/ASIO support (I'm going to add ASIO only, it's much more needed by advanced users then WASAPI)
  • builtin MIDI --> MP3 converter (no more play & record tricks, just select your MIDI(s) and get an MP3/WMA/FLAC/...)

After that I'll freeze features and enter the beta stage:

  • users feedback/survey about
    • dropping XP support
      Recent C++ compilers have to be set in compatibility mode to let built executables run on Windows XP.
      This introduces some kind of "compatibility level", performance and features loss.
      Also WinXP is nowadays relegated to low performance hardware, surely not recommended for VMS2 performances and features.
      Finally testing VMS2 on 5 OSes (XP, Vista, 7, 8.1, 10) is becoming really hard, so dropping Windows XP will be great.
      Since VMS1 will always be available, these users are needed to stay on it.
    • dropping 32bit operating system support
      I'd like to drop 32bit OSs support for VMS2.
      NOTE: I'm talking about OS bitness and not the MIDI client.
      VMS2 will only install on 64bit Windows versions, while both 32 and 64 bit MIDI clients can use it (VanBasco and DosBox are safe ;) don't worry).
      This will give full memory support to load lot and/or large SF2 files, and also removes WOW64 emulation on 32bit synth.
      AFAIK 32bit OS installations of Win7/8/10 are a small minority respect to 64 bit ones; is it really needed to still have a 32bit setup?
      So, in my mind I'm thinking: sorry x86 guys, stay with VMS1!
  • setup reorganization
    Now that driver and synth components are splitted, I'd like to install VMS2 into its own folder in %programfiles% and stop crowding System32 (in fact only the driver component VirtualMIDISynth.dll is required to stay there).
  • translation
    Once features are freezed, translators can start their work (thanks again for that).
    I'd like to have the same great VMS1 language support for first VMS2 release, but first I'll import unchanged VMS1 strings to VMS2, so translators can work faster only on new ones.
Posts: 14
Joined: October 14, 2014 - 00:11
Re: CoolSoft VirtualMIDISynth 2.0.0-alpha17 released

About the MIDI Exporter, it will only support compressed formats like mp3/wma/flac/ogg... or it will also export standard uncompressed .vaw? When i use an audio rendered MIDI on a video, i usually use .vaw due to no quality loss and compatiliby with all video editors.

Well. if dropping XP support for new features is necesary (like a feature which it might not work reliably on XP) would be a good chocie. I use an i5 2500K running Windows 7 as my main PC, but i still have many other PCs, most of then are Pentium 4s running the good old XP, but when it comes to MIDIs, VMS2 runs OK on a single threaded 2.8 ghz Pentium 4 (2002) with normal MIDIs, but it becomes laggy when it comes to bigger MIDIs like black MIDIs, in my tesing VMS2 delivered very bad perfomance with blacks MIDIs probably because of the old CPU since is an old Pentium 4 without hyperthreading. If i would drop older OS support if feature needs a new complier unsupported by XP, i kinda guess also Windows Vista support will be dropped as well near future since Office 2013 and VS2013 (as host) already dropped Windows Vista as well. (Visual Studio 2013 comples for Windows 7 and newer and SSE2 target by default, I wonder if VS 2015 will fully drop XP/Vista support)

About VMS and old hardware, I would consider as the minimun hardware for VMS a Pentium 4 HT with 512 MB RAM (small soundfonts only), as recomended: a Intel Core 2 Duo with 1-2 GB RAM

Also about dropping old systems support, will VMS2 drop support for single core/threaded CPUs? and also drop support for CPUs without SSE2* (if your compiler supports SSE2 targeting*)?

*CPU targets (common in VS2013, i omited AVX/AVX2) can be set to
IA32 - All x86 CPUs
SSE - Pentium III and newer, Athlon XP and newer
SSE2 - Pentium 4 and newer, Athlon 64 and newer

Note that is only useful if you are going to still supporting 32 bit as well since there no x64 CPUs without SSE2.

About dropping 32 bit OS support. it depends, 32 bit programs are limited to 2 GB RAM, 3 GB on 32 bit OS when it has the large address aware flag or 3 GB Switch/4 GB on 64 bit OS when the executable has the large address aware flag (More info about large address aware: https://msdn.microsoft.com/en-us/library/wz223b1z.aspx) About 32 bit OS PCs, many netbooks came with 32 bit OS as well with many/some other PCs from 2007-2010 which have a capable CPU of running VMS without issues. Also 32 bit OS instalations are very common on PCs with <3 GB RAM and even some with 4 GB RAM and not forgetting many Windows 8/8.1 tablets and sticks like Intel compute stick still comes with a 32 bit OS. I sugest keep 32 bit OS support in the final version, but dropping on a next major version (2.1.x-3.0?). For 64 bit OS only, VMS2 would end only having a 64 bit synth componet limited by the system RAM only (if preload is enabled). Anyways is your chocie

I also have some questions:

Can VMS2 use a different folder in System32/SysWOW64 like "VirtualMIDISynth2" and be installed angloside VMS 1.x? it can be a useful option/feature for betatesters (no need to install/resinall VMS1 for live perfomances) and some pepole who needs an old version for testing/compatibility or simply just want to test a new version.

Will be Synth component be able to use more CPU cores? Idk if it will be a good idea, but it can be for some features (eg, MIDI to audio exporter)

About VMS2 in general, i have been testing VMS2 since Alpha7 and it becoming better, it beats VMS1 in perfomance and runs pretty well despite having some issues

Carlos S. M. - Black MIDI Team Member
Channel: https://www.youtube.com/channel/UCgVv5sa3hZluRZ8AQdq5tEg

Posts: 4
Joined: July 15, 2015 - 23:15
Re: CoolSoft VirtualMIDISynth 2.0.0-alpha17 released
coolsoft wrote:

After that I'll freeze features and enter the beta stage:

  • users feedback/survey about
    • dropping XP support
    • dropping 32bit operating system support

Oh, bummer. Can't complain though.

Posts: 1536
Joined: March 25, 2012 - 01:19
Re: CoolSoft VirtualMIDISynth 2.0.0-alpha17 released
Carlos S. M. wrote:
About the MIDI Exporter, it will only support compressed formats like mp3/wma/flac/ogg... or it will also export standard uncompressed .vaw?

.wav export will be surely available because it's BASS native, others require additional encoding plugins.

Carlos S. M. wrote:
VMS2 runs OK on a single threaded 2.8 ghz Pentium 4 (2002) with normal MIDIs, but it becomes laggy when it comes to bigger MIDIs like black MIDIs, in my tesing VMS2 delivered very bad perfomance with blacks MIDIs probably because of the old CPU since is an old Pentium 4 without hyperthreading.

You're right, but looking to new features that users will loose by not being able to upgrade to VMS2 I wonder if is there a show-stopper one?

VMS2 actually gives these features over VMS1:

  1. instant play, no initial delay due to synth being already started
  2. multiple devices support
  3. no BASS DLL versioning issues with too new/too old MIDI client softwares
  4. live apply of settings changes

These are all great features to have, but for an (almost) obsolete hardware only (1) is really needed:

  1. yes, this is good to have on XP too, but I suppose can even do without it
  2. you're not supposed to run more than one virtual device on obsolete hardware
  3. obsolete hardware means not updated MIDI softwares too, so if if works now it will continue to work
  4. again I suppose users can even do without it
Carlos S. M. wrote:
Also about dropping old systems support, will VMS2 drop support for single core/threaded CPUs? and also drop support for CPUs without SSE2* (if your compiler supports SSE2 targeting*)?

Well, actually VMS does not really need SSE* instructions directly, but BASS surely does.
VMS needs to be as fast as possible in receiving MIDI messages, parse/patch and drive them to BASS.
MIDI synthesis is done by BASS, and this involves a lot of SSE instructions; AFAIK BASS has some kind of software emulation (and quality reduction) when running on no-SSE* CPUs.

So, the thought of removing 32bit synth will only help me in reducing the test cases that will exist (once a 64bit synth will be available):

  • driver-32 --> synth-32
  • driver-64 --> synth-32
  • driver-32 --> synth-64
  • driver-64 --> synth-64

together with reducing the size/complexity of setup, because anything related to synth (BASS and its plugins like BASSMIDI but, once added MIDI-->MP3 converter or ASIO support, I'll need more) wont be duplicated:

  • 32 bit supported: driver-32, driver-64, synth-32, synth-64, BASS-32 + BASSMIDI-32 (+BASSMP3-32 + ... + BASS*-32), BASS-64 + BASSMIDI-64 (+BASSMP3-64 + ... + BASS*-64)
  • 32 bit dropped: driver-32, driver-64, synth-64, BASS-64 + BASSMIDI-64 (+BASSMP3-64 + ... + BASS*-64)

The only pro in having a 64bit synth is that it can load large SF2, but also many smaller ones.
Cons are that we could loose a (I still don't know how much large) part of users.

Carlos S. M. wrote:
Can VMS2 use a different folder in System32/SysWOW64 like "VirtualMIDISynth2" and be installed angloside VMS 1.x?

It could, but I'd like to wait for beta stage (that will be tested by, I hope, a lot more users).
Alphas were targeting experienced users only, and I'd like them to focus on a single product without "noise" (think about first alphas when things happened witout any apparent reason...).
Also mixing things could have been be too confusing: VMS1 and VMS2 share the same systray icon and even really similar dialogs (mixers and so on).

Starting from beta, VirtualMIDISynth.dll will be installed straight to System32 while VirtualMIDISynth.exe (and all of its companion BASS*.dll and config files) will have their own place in %programfiles%.
That way it could be possible to have both VMS1 and VMS2 installed together without issues.

Carlos S. M. wrote:
Will be Synth component be able to use more CPU cores?

It already does, it tries to split MIDI IPC queue and rendering threads over all available cores.

Thanks for your post.

Posts: 59
Joined: April 19, 2014 - 06:23
Re: CoolSoft VirtualMIDISynth 2.0.0-alpha17 released
coolsoft wrote:
  • users feedback/survey about
    • dropping XP support
    • dropping 32bit operating system support

My idea is, while you got the 64-bit version out which uses just the 64-bit .dll and everything, why don't you create a second branch of VMS2 which is made 32-bit, has the 32-bit .dlls instead, and has windows XP compatibility?  Changes in the 64-bit branch could simply be merged with the 32-bit one, and let all the 32-bit and/or XP users report the bugs they discover instead of you wasting your time test every change (just warn that 32-bit version is untested by yourself, but you have an opportunity to report bugs in the forums).  Sounds like a win-win situation to me.

That being said, I actually DID test VMS2 on an x86 Pentium 4 hyperthreaded PC not too long ago, and it actually did pretty good with the Black MIDI I tested with, after I tweaked the settings as specified in the description, and yes VMS2 did do significantly better than VMS1 on it.

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

Posts: 16
Joined: September 4, 2014 - 17:34
Re: CoolSoft VirtualMIDISynth 2.0.0-alpha17 released

Something isn't quite right with A17.  I don't know exactly what it is, but it's like it's re-using existing voices in preference to going polyphonic - at least, that's what it sounds like to me.  The archive attached includes the 3 MIDI files I'm using to test.  They're not overly complicated (in fact, they're downright simple compared to some of the others used) but they demonstrate the issue clearly enough.

air.mid: The bass line seems to be almost entirely absent.  Noticeable right from the very start.

FuegeGM.Mid: Again, the low-frequency notes appear to be absent in large parts.  Noticeable right from the very start.

INTROGM.MID: Doesn't sound quite right off the get, but it becomes obvious with the brass line starting around 17 seconds.  Stacatto notes into full-length just meld together into one, longer note.

None of these issues were present with A16.  Trying out different sound fonts, different buffer lengths, different polyphony limits, processor allowances, etc, has no effect either positive or negative.

Attachments (Only registered users)
MIDI.zip
Posts: 59
Joined: April 19, 2014 - 06:23
Re: CoolSoft VirtualMIDISynth 2.0.0-alpha17 released

This is by far one of the more interesting revisions I've tested so far, not only have I found a couple of new bugs, but the new MIDI Queue changes has got my creative side going as to how the queue could be done:
 
 
Firstly, I've already figured what you're doing with the IPC queue system for a while, implementing your own method of preventing the synth from exceeding 99% rendering time to get rid of harsh stuttering noises, by queuing MIDI events after a certain data threshold determined by some sort of magic formula. With Alpha17, you seemed to have moved this queuing system from being internal into forcing the MIDI player's thread to slow down to use the their queue system instead.  While relying on MIDI Player's queue to smooth out the synth audio works well on most players such as Vanbasco's, tmidi on the other hand doesn't like it [video], but I'd blame that entirely on a flaw that should be fixed from tmidi's end.
 
While I've seen people already report having a MIDI Player slowdown at all being a bug, I personally disagree with that, I think this eliminates the inconsistency of having a slow synth while the MIDI Player is working at full speed, as well as cause VMS to sound smooth on slower synths.
 
That being said, I think the algorithm used for determining queue thresholds needs some work.  Currently I see it's dependant on CPU-thread headroom and the CPU-affecting synth settings.  However the relationship between the actual cpu headroom and the threshold seems to be very non-uniform, and causes the queue from starting to kick in anywhere between 60% rendering time to >100% (where it becomes useless because the synth's already stuttering), instead of kicking in right before the point of stuttering which I think is around 95%.  I've even seen some of my test configs trigger the queue-induced slowdowns even at a staggering ~30% rendering time.
 
Meanwhile, I've tested this alpha on my single-core Intel Atom N455 running Windows 7 32-bit, and the VMS synth went from being useless with black midis on A16 to nearly perfectly smooth sounding under very specific settings with A17.  The best results seem to have come from using a 300 polyphony and 22Khz sampling rate.  Talk about a VMS build being the most x86 friendly huh.  But for example, I've found that with the default sample rate, using a 200 polyphony [video] apparently slows down Vanbasco's just enough to be nearly stutter free, but using a 100 polyphony [video] speeds it up just a little too much and therefore causes stuttering.
 
To do further testing, I recommend using Bad Apple 5.1 million (2:00-2:10 and 3:00-3:30) and Armageddon to archeopterix and icaria 3 3 million (0:50-1:05), under several different CPU performance environments, as well as playing with settings such as polyphony and sample rate.
 
Oh, I should mention, with all of my testing mentioned above I have disabled the max rendering time function.
 
 
Now to my roundup of the new bugs I've found:
 

  • MIDI players are likely to hang if the VirtualMIDISynth process were to be closed or has crashed.  I think this one is a side-effect of an intentional feature you've added of getting MIDI players to "recognize" the closure of VMS, probably by telling the player to stall the MIDI-Data thread when the VMS process is not running or something.  Unless I'm missing something, I don't see the point in having something like this and I think it'll do more harm than good.
  • Closing and re-opening VMS while a MIDI Player is playing will not restore the port to that player, however if you open a second MIDI Player instance and call that to playback under the same VMS-port while MIDI Player #1 is playing yet inaudible will cause audio from both MIDI Player #1 and #2 to play at once.
  • Changing channel attributes (eg. instruments, vol.etc) for channels with one of the two midi-players in this situation will cause the attributes to take effect on both player instances.
  • All simultaneously run synth instances share the same CPU thread/core
  • Configurator: In the options tab, scrolling by clicking above or below the thumb element causes drawing problems
  • All non-percussion channel's instruments are reset to acoustic grand piano when the audio returns from live-applying a setting
  • Launching VMS can occasionally cause the mixers activity indicator to become stuck until "disable mixer note activity indicator" is checked then unchecked under Options
  • Lots of specific MIDI files have timing and sustain issues, as already reported in the last post

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

Posts: 4
Joined: July 15, 2015 - 23:15
Re: CoolSoft VirtualMIDISynth 2.0.0-alpha17 released

I did a recording of alpha17 on my system. It's hilariously broken.

http://a.pomf.cat/xowxuh.mid

http://a.pomf.cat/kidtap.ogg

Pages