VirtualMidiSynth API?

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 !!!
Posts: 25
Joined: May 17, 2017 - 14:12
VirtualMidiSynth API?

Hi there,

Love the VMS running on this machine with all the other addons. Never knew it was this easy. Great!

Please let me introduce myself as a coder (of sorts) and in the middle of currently updating an ancient VB6 program.

It uses basic calls to mcisendstring- e.g. Open, Play, Stop, Seek, Close. Works well with the midimapper!

It's when user turns off the midi there's an issue as it won't let the program close handles to all ports when using midiOutClose(hWnd).

Not a big drama as the program can be restarted. I'll update tomorrow as some refactoring is still required. :)

However this is much less of a problem if there are APIs (Multibyte for VB6 please) e.g. open/close port handles.

Keep up the good work!

Posts: 25
Joined: May 17, 2017 - 14:12
Re: VirtualMidiSynth API?

Some further testing revealed:

  • Bit unstable and throws MMSYSERR_ALLOCATED if not setting the Default device as  VirtualMidSynth#N, but that's documented aleady.
  • Testing with just one soundfont at the moment: Chaos_V20. But midiOutGetNumDevs still allocates 4 devices.
  • Using midiOutOpen to switch devices. Not working, as probably handles are assigned. These are system handles, not user handles- so an API might want to provide user handles. Might be a bit of work there.
  • Again, midiOutClose will not close the handles for above reason.
  • Used "deadmau5 - Hyperlandia  (midi by Carlo Prato)" (www.cprato.com) to test. Obvious difference when switching def WM_Device in VM Synth, but always plays as VirtualMidSynth#1 in program, no matter what ports are chosen. Cannot play it with GS Wavetable (not that it's all that big a deal but still nice to have option)
  • Interestingly the above file plays faster in-program than through the W10 WM_Player

There's a fair bit of overhead in setting up a "user" system for midi. But it's probably the way to go as it may be of some use to other OEMs down the track. What do you think?

Posts: 25
Joined: May 17, 2017 - 14:12
Re: VirtualMidiSynth API?

Ehm, in reflection this may not be necessary:

Using these functions -

midiStreamOpen

midiStreamOut

Playmidi files with mcisendstring until we change port (or device: Only issue here is what mcisendstring might do to barf it all up.)

Quit - or Change port device, followed by

midiStreamStop

midiStreamClose

Don't require device handles any more as midiStreamOpen creates its own stream handle.

Will post back on how this goes. :)

Posts: 25
Joined: May 17, 2017 - 14:12
Re: VirtualMidiSynth API?

Well it's a success story- mostly. :) MidiStreamOpen returns the GWS Wavetable device as permanently used, but the other VM devices open nicely for stream. Think I can call this app VirtualMIDISynth compatible! :D

Posts: 1972
Joined: March 25, 2012 - 01:19
Re: VirtualMidiSynth API?

Sorry for leaving you alone with your experiments.

Well, I don't have any experience with mcisendstring commands, being it such a legacy technology.
I suppose something is acting behind the scenes, keeping you away from tha hassle of opening and managing handles and such.
That's why this "helper" behind you keeps handles open.
This all started (and was projected) when people had only one device and one MIDI client, so I suppose it's not so easy to make it work nowadays, when a standard musician have more than 2 devices and a lot of MIDI softwares all together...

The workaround you found is to open the device "by hand" and get your own handle; this seems to me the best approach; yes, it's more difficult, but scalable and efficient.

Posts: 25
Joined: May 17, 2017 - 14:12
Re: VirtualMidiSynth API?

Thanks. As a feature request for the next VMSynth, please port the conf settings to registry. This is because querying the Windows midi port(devices) always returns 4 (or more) irrespective for VMSynth.

Selecting a port(device) which is out of range of DevicesCount will result in

"VirtualMIDISynth.dll, version: 2.0.1.0, time stamp: 0x58fcc276
Exception code: 0xc0000005"

Fortunately this occurs during the client program exit sequence. Strangely, subsequent use of an out of range port will produce the fonts of the default VirtualMIDISynth MIDI out device without error!

Also it would be nice to be able to access the soundfonts chains in the actual VM devices, as all other slected ports only return the sound of the default VirtualMIDISynth MIDI out device. Would extra code be necessary? Although the WM_Player default device works!

Looking forward to the next release. :)

Posts: 25
Joined: May 17, 2017 - 14:12
Re: VirtualMidiSynth API?

This is interesting- the above holds if limiting the client devices to 2. That is all is fine if VMSynth has 2 or more midi port(devices) configured.
But increasing them to a max of 4, ensuring that all 4 of the VMSynth devices are correctly configured it's crashing again regardless. Tried a few combos without success.

...

NVM the above:

Assuming that MyAPP as a client can only have one active port at a time. If user changes port, streams must be closed and opened on new ones gracefully. However, this doesn't happen- probably due to some ancient MS cruft.

The actual problem occurs when using midiStreamStop and midiStreamClose on possibly null streams.

device 1 returns a handle

device 2 doesn't return a handle (this is the WM_Default here)- but that shouldn't be an issue

device 3 returns a handle

device 4 returns a handle
Does VMSynth support these functions, to the extent that when midiStreamClose is used the handle is released from a midiStreamOpen?

Posts: 1972
Joined: March 25, 2012 - 01:19
Re: VirtualMidiSynth API?
lmstearn wrote:
please port the conf settings to registry

This is something I'd like to avoid because... I simply hate the registry thing ;)
I know it's easier for a developer to load/save data from registry respect from/to an INI file, but for non-technical users accessing the registry is a nightmare and could lead to any kind of damage.
I've already experienced the pain to ask an user to read/change a setting value in the registry (I've done phone support in the past...):

  • tell the user to open regedit.exe (most users have never opened a command prompt or WIN+R in their whole life)
  • go to a deeply nested key (they will probably stop here, only the brave will go further on and, maybe, open the wrong key)
  • export it to a .reg file (will save a subfolder or the wrong key)
  • they finally attach it (...and the winner is ;))

It seems a bit exagerated but... it happens a lot and it requires a lot of time to be sorted out.

lmstearn wrote:
This is because querying the Windows midi port(devices) always returns 4 (or more) irrespective for VMSynth.

That's not how it should work, will investigate it.

Posts: 25
Joined: May 17, 2017 - 14:12
Re: VirtualMidiSynth API?

Thanks for looking into the ports issue, especially the same Synth output for every port.

Yes, registry is not really for users- Maybe consider some kind of backup reg key so users can revert to defaults without data corruption and direct registry edits - but heck, ini files are much easier. :)

Posts: 25
Joined: May 17, 2017 - 14:12
Re: VirtualMidiSynth API?

Just an update on observations:

After a fresh reboot, the first application that assigns midi ports will own the ports, excluding other apps which may then fault when accessing them. Found this to be the case when running MyApp before Reaper- in which case Reaper promptly crashes.

However running MyApp as admin there's

"Device "VirtualMIDISynth #1" is already in use by process "C:\..MyApp.exe", PID #XXXXX."

But toggling the port off/on the music returns even on the same elevation.

The program can rerun on a different PID but wil play the music, as long as it is unelevated.  Weird, must be a Windows thing going on.

Thanks for all the hard work, and look forward to developments. :)