VMS 2.0 - Problems with access (Overture 5)

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: 29
Joined: June 26, 2015 - 03:15
VMS 2.0 - Problems with access (Overture 5)

Greetings,

I recently upgraded my CoolSoft VirtualMIDISynthesizer from V1.8.1  to V2.0

I believe that V1 established a single "device" with multiple-input capability. Thus several open applications could choose it as their MIDI destination device and there was no conflict. V2.0 can establish up to 4 distinct devices, but it seems that perhaps they do not have multiple input capabilities. Thus I run into conflicts when I try work with several MIDI-capable applications.

I thought to overcome this by configuring v2.0 to establish four separate devices, expecting to have each of my major MIDI-capable devices use a separate one as its destination device. (Rather a pain at best!) But one of my newer applications, Overture 5, finding four instances of the synthesizer, enrolls all of them into its stable of available devices, after which other applications cannot choose any of the four.

It may be that this behavior by Overture 5 is itself not "appropriate". I will look into that on the forum for that Application.

In any case, for the moment, I have uninstalled V2.0 and re-installed V1.8.1, telling it not to check for updates!

How should I proceed to be able to enjoy the improved performance of V2.0?

Thank you so much.

Best regards,

Doug

Posts: 1535
Joined: March 25, 2012 - 01:19
Re: VMS 2.0 - Problems with access
Doug Kerr wrote:
I believe that V1 established a single "device" with multiple-input capability. Thus several open applications could choose it as their MIDI destination device and there was no conflict.

V1 should have been a single device but being an in-process DLL there was no easy way to interlock its multiple usage, so sometimes users were able to load it multiple times.
That behavior was not expected nor supported ;)

V2 has a strict interlocking between resources that disallow reusing the same virtual device more than once and it should work on a per-device base: VirtualMIDISynth #1 and VirtualMIDISynth #2 are 2 distinct devices.
Should be great for me to test it on my side to check how the device is opened; is there a demo of Overture 5 available (that has the same issue)?

Posts: 29
Joined: June 26, 2015 - 03:15
Re: VMS 2.0 - Problems with access

Hi, Chief,

Sorry I don't know yet how to mark things here as quoted, and the indenting doesn't seem to work either.

coolsoft wrote:
V1 should have been a single device but being an in-process DLL there was no easy way to interlock its multiple usage, so sometimes users were able to load it multiple times.
That behavior was not expected nor supported ;)

Oh. Well, it was handy for me for many years!
I had thought that there is a legtimate "multiple input" form of MIDI drivers.

coolsoft wrote:
V2 has a strick interlocking between resources that disallow reusing the same virtual device more than once and it should work on a per-device base: VirtualMIDISynth #1 and VirtualMIDISynth #2 are 2 distinct devices.
Should be great for me to test it on my side to check how the device is opened; is there a demo of Overture 5 available (that has the same issue)?

Sure. You can download the latest commercial version (I am using a slightly-later beta test version) on a trial basis here:

https://sonicscores.com/downloads/

You will see the battle zone immediately at Audio/MIDI>MIDI Settings

Meanwhile I am looking into making Overture ignore all but one instance.

Thanks.

Best regards,
Doug

EDIT: fixed quoting

Posts: 29
Joined: June 26, 2015 - 03:15
Re: VMS 2.0 - Problems with access

Hi, Chief,

As you probably know, LoopBe is a MIDI software "loopback cable" that allows us to interconnect two MIDI-capable applications so the MIKDI Oiut of onme canm send into teh MIDI IN of another. It comes in two flavors, LoopBe1, which offeres only a single instance, and LoopBe30, which can establish up to 30 [independent] instances.

The publisher's site for LoopBe30 says this:

"Basically LoopBe30 provides [up tp] 30 independent "invisible cables" to connect MIDI outports of applications to any other application's MIDI inport.

"You may connect up to 8 applications to every single inport and up to 8 application to every single outport, all sending and receiving at the same time. Every port provides the full 16 MIDI channels."

This sounds to me like the "multi-input" feature I have been talking about in this thread. It sounds just like what I experience with LoopBe1 (I only have that single-instance version, as it is free!), wiith a single instance of MIDI Yoke (another tool for the same purpose as LoopBe), and in fact (expected or not) with VMS 1.x. (I'm not so sure about the "all sending at the same time" part.)

Where am I going wrong here?

In any case, whether this behavior was intended, or even expected, with VMS 1.x, I sure miss it!

Thanks.

Best regards,

Doug

Posts: 29
Joined: June 26, 2015 - 03:15
Re: VMS 2.0 - Problems with access

In fact, I just noticed that the LoopBe publisher's site for LoopBe1 (whcih only offers a single instance of the "loopback cable") says:

"You may connect up to 8 applications to LoopBe's inport and up to 8 applications to the outport, all sending and receiving at the same time. "

Again, I am suspicious of the "all sending . . . at the same time" part, but again this certainly sounds to me like the behavior I have been discussing.

Best regards,

Doug

Posts: 29
Joined: June 26, 2015 - 03:15
Re: VMS 2.0 - Problems with access

It comes to me now that the term most often used for the capability I discuss above is "multi-client" MIDI drivers.

My orignal awareness of this came about many years ago, so the details come back to mind slowly!

The following is from the site for MIDI Yoke, a "device-side" MIDI loopback facility:

"MIDI Yoke can be configured to provide a varying number of MIDI Ports (from 1 to 16).
In addition, each port allows multiple opens of both input and outputs: up to 4 openings per port."

The latter clause refers to the capability I discuss.

Best regards,

Doug

Posts: 1535
Joined: March 25, 2012 - 01:19
Re: VMS 2.0 - Problems with access

Let me clarify what I mean with "unexpected behavior".

Being VMS a MIDI device, it should be used by a single client at a time, just like any other MIDI device (virtual or not).

When a MIDI client starts, it opens its out device, initializes it with own configuration (programs, controllers, volumes, ...) then starts sending MIDI messages (notes) to it.
What if another client opens the very same device and, say, changes track 1 program from Acoustic Grand Piano to Sax?
This is a race condition where the last one wins; this is what I call unexpected, so devices are opened exclusively.

Well, what happened in VMS1 then?
VMS1 is an in-process driver: it means that each MIDI client loads its instance of the driver exclusively into its own process space, because each instance is naturally separated from the others.
This (could) have some positive effects like multi-instance, but also has a lot of drawbacks:

  • load time: each instance must load its own soundfont configuration and, also, its copy of soundfont files into memory
  • memory usage: see point above
  • DLL hell: VMS1 driver also needed to loads BASS libraries, causing any kind of issues with MIDI clients built on BASS too
  • MIDI mixer: VMS MIDI Mixer was contained into the driver DLL so, when the MIDI client released the driver, all of the VMS data is discarded (Mixer, Soundfonts, ...) and must be reloaded at next usage

I tried to put some kind of interlock in VMS1 but the solution was worst than the possible issues caused by unintended multiple usage, so the idea was abandoned.

VMS2 splitted the driver component (now really lightweight) from the synth (more details in this thread) so the interlock is easily done on the synth side: no more than one driver can talk with the same virtual device.
My intention wasn't to remove multiple usage but replace it with real multiple device support, where each (virtual) device has its own config.

So now I'd like to investigate on why, when Overture 5 opens VirtualMIDISynth #1, other devices from #2 to #4 are marked as in use too.

@Doug Kerr: could you please check VMS2 about tab (VMS2 Configurator --> About tab) when Overture 5 is using device #1: look at the reported PIDs of the processes using devices #2...#4.
It should report the same PID number for all devices from #1 to #4.

Posts: 29
Joined: June 26, 2015 - 03:15
Re: VMS 2.0 - Problems with access

Hi, Chief,

I uninstalled VMS 1.8.1.0 and installed 2.0.

I started Overture 5 and opened the MIDI setup dialog. It intially looked like this:

MIDI_setup_VMS-02.jpg]

Only one instance of VMS was enabled (this may have been remebered from an eralier situation).

The VMS about tab looked like this:

[VMS_About-01.jpg]

I donl't know where the PIDs are shown - perhap they are the "#6908" seen after the situations of each of teh instances of VMS.

Now, with the system in this situation, I opened Cakewalk Home Studio and told it to send its outputs to VirtualMIDISynth #2. I got an error message:

[CHS_MIDI_error-01.jpg]

So this is in fact the problem situation with which I am concerned.

Now that I have this clarified, I will contact Don Williams of Overture and ask about his end of this.

Is there a way on this forum that I can make graphic files visble in-line?

Thanks.

Best regards,

Doug

Attachments (Only registered users)
MIDI_setup_VMS-02.jpg
VMS_About-01.jpg
CHS_MIDI_error-01.jpg
Posts: 14
Joined: May 27, 2015 - 16:09
Re: VMS 2.0 - Problems with access

stesso problema succede con "cubase 5 VST32"   una volta avviato su #1 anche #2, #3 e #4 risultano occupati.....SISTEMA OPERATIVO  WINDOWS 7 PRO X64 ....se servono più info sul pc in uso mi faccia sapere ....

Posts: 1535
Joined: March 25, 2012 - 01:19
Re: VMS 2.0 - Problems with access

I've tested Overture 5 (Trial) on my test system and I see that it opens all of the available devices (at least all of the VirtualMIDISynth #1...#4) regardless of its MIDI devices configuration.

I enabled VirtualMIDISynth #1 only at first, but I still receive MODM_OPEN calls for all of the devices.
The same happens if I completely disable VirtualMIDISynth (see attached picture).
That confirms the correctness of what is reported by the About tab: Overture5.exe is using all VirtualMIDISynth virtual devices.

There's nothing more I can do on my side; I believe this is a client issue so it must be addressed by Sonic Scores.
I don't know if they have a support forum; if yes, please start a support request and backlink it here so I can follow it.

Pages