I spent many hours over the weekend working out how everything actually works on the PC based environment.
- version 1.6 does work
- I had missed a step
- there is some very strange restrictions
- there are some significant issues
First I want to apologize for some of my previous comments.
First let me change the Master/Slave terminology to something that is more appropriate. Requester/Provider because Unlimited Midi Names works appears to be very dependent on which side of the ‘/’ you are on.
For my testing I focused using three nodes. As I have gone through this I have been doing screen captures to document, so I can assemble a decent and somewhat comprehensive guide on how the Windows PC based environment works as it appears to work quite differently than the MAC environment because of the different methods Midi is implemented in the operating systems and because the user interface is also different.
Node 1 is a rack of synths connected to a MIDIPlus 16x16 USB3 native windows compliant midi device. Each synth is connected to a pair of input and output ports. In Bome, Midi names have been assigned to each synth and routings created between the virtual names and the physical ports(In to Out, Out to In. With 9 synths in the rack trying to remember which synth is connected to each port is a problem, especially when one considers there are 3 other equivalent racks.
Node 2 for testing is a laptop connected to a M-Audio 4x4 unit , 3 inputs are used. A Kawai M8000, a StudioLogic SL88i and a M-Audio ES88 are connected to the laptop through the device. I created virtual names for each keyboard.
Node 3 is a PC running MidiQuest 13 Librarian. There are no physical Midi ports on this machine, just Bome network.
Here is what I found:
Node 1 can be classified as a pure Provider only. It receives connect requests but does not act as a requester to any other machine.
All Midi Naming/Name to port routing works as expected.
Node 2 is a pure Requester at this point. All I am trying to do is connect keyboards to specific synths on Node 1
When I connect to Node 1 and click on the node after connected (Please provide a configuration option to auto accept connection requests, I could not find a config option for this) I can see a complete set of virtual and (MidiName) virtual virtual in and (MidiName) virtual virtual out connections. I eventually figured out how this works but it is not intuitive:(Note: it would be helpful to have text on the line for a connection that says ‘click here to access device connections within this node’ when connection has been established. This would make it more intuitive.
- A (midiName) Virtual Virtual In port is actual the output port to the provider so to connect to a synth. I had to use the Virtual Virtual In as the connection device that is actually outputting to input of the synth in a route. I had to go back and forth between logs on both nodes to finally get to this.
- You cannot use the Midi Names in or out on the requester for this routing for the connection. The only route that I could get to work is to map the actual M-audio 4x4 physical port to the Virtual Virtual In synth Midi Name. This does work and I could map multiple keyboard to multiple synths so one to many, many to one, and many to many appear to work and I had multiple midi connections running between the two nodes.
Next I tried to add Node 3.
Here life got interesting, and I ran into a functional issue.
- When I connected Node 3 to Node 1, the connection was enabled but only virtual ports showed. There were no Virtual Virtual In and Virtual Virtual Outs showing. Just routings for Virtual to Virtual. hmmm!
Now I went back and disconnected both Node 3 and Node 2 from Node 1 and reconnected Node 3. Now when I connect to Node 1, all the Virtual Virtual In and out ports are visible. So just like the adage a Slave cannot serve two Masters, it appears that a provider can only service one requester or at least it appears to work that way based on my testing so far.
Now for the real problem on Node 3. The Virtual Virtual In and VIrtual Virtual Out ports show for connection BUT when I load MidiQuest and go to do the connections to the synths on Node 1, the only things that shows in the drop down selection is the VIrtual Ports not the Virtual Virtual ports. This is definitely a windows based problem. As indicated previously on Node 2, the only way to get this to work was to connect a physical port which has a true windows device to the Virtual Virtual In port. When I check Device Manager, the Virtual Devices are there but not the VIrtual Virtual In and Out as devices. Software apps on windows such as MidiQuest pull the available ports for connections lists from the Windows devices so the connections I need to communicate to the synth, the Virtual Virtual Ports are not available to be selected in the list. I have another node running nothing but Sonar Platinum as a sequencer (another primarily software node) and although I have not tested yet, I am positive, based on what I am seeing in Windows devices on Node 3, it will not work as a requester for the very same reason because it also uses windows devices for its connections lists which is a major problem.
I am also spinning back up a VST host server to host VSTs. This will also be a provider, but I am suspecting that this mayalso have a problem serving the VSTs as devices. No physical ports to map. In this situation it would be an absolute software to software connection across the network. This would be a totally logical environment for a small personal studio to have a DAW on a laptop and supplement by having a VST host on a NUC or something similar to push some of the processing load off to a secondary machine rather than loading all the VSTs within the DAW.
Steve, Florian is there something I need to do to make those Virtual Virtual In/Out ports usable from a software application? I tried using the Virtual Ports themselves as the input and output connections but as I expected that did not work.
I will continue to test this weekend by adding another provider node into the mix and see what impact this has on repeating tests from a single requester node.
Since it appears that a provide can only service one requester, this makes the ability to load and save scenes almost mandatory, if one has to drop and reconnect from requesters, so you can reconnect and load Midinames and routings on demand.
For example, if I am running the sequencer with a set of connections to various synths and I want to load a new bank of patches to a particular synth on a node I am using, then I have to disconnect the sequencer requester, connect the patch editor requester and set routing for that particular rack to access that synth, load the bank and then disconnect, go back to the sequencer , reconnect and load the midi names and routings that I was using before I can proceed. That is, providing we can overcome the issue I just raised on connecting a software package to the Virtual Virtual In/Out connections.
Sorry for the long post, but I wanted to provide concise and detailed descriptions so they would be useful.