Setting up Bome Network with 3 Computer Nodes

[jmcdouga]

I spent many hours over the weekend working out how everything actually works on the PC based environment.

1. version 1.6 does work
2. I had missed a step
3. there is some very strange restrictions
4. 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.

1. 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.
2. 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.

1. 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.

[SteveC (Steve)]

Hi,

I would recommend that on Node 2 you use MIDI Remote Direct to access all of the ports on Node1. I’m not sure how your ports are named but as an example, the computer name for Node 1 is ‘Node1’ and the port names on that node are ‘port1, port 2, etc’. With MIDI Remote Direct you would simply check the ports you want to use on Node 2 from Node 1 and then you could access them from Node 2 with the names ‘Node1:port1’, ‘Node1:port2’ etc
On Node 3 you would follow the same procedure for accessing Node 1 but you would set it up on Node 3.

As an example I have 2 computers. One (Node 1) is named ‘Steve-HP-Pavillion’. From my Gaming PC ‘Steve Gaming’ I can select Steve-HP-Pavillion on Steve gaming and it I am presented with all available ports on Steve-HP-Pavillion.

![Steve-HP-Click|336x46]
(upload://snTddr5wV7QoWE8YYhlbXo5jYOe.png)

After clicking you can select the ports you want.

Now you can access any of the ports from Node 2.

Do the same on node 3. And yes they can be shared.

You applications would see the names as Hostname:portname

For you keyboards, you might need something on Node 2 to
tell the keyboards which port on the remote host to connect to. For this, I typically use Bome MIDI Translator Pro. But you could set up routing on the Bome Network MIDI router to do this as well. Simply create input from a Keyboard to one of the Remote Direct MIDI port inputs.

For instances IN: M8000 → IN: Node1:port2

I do it in MT Pro because I can change ports with MIDI using MT Pro logic.

The same would be for Node 3 connecting to Node1
For Node 1, you could set up Auto Accept connections from Both Node 2 and Node 3. The below shows how I set this up from when Steve-Gaming makes a connection request to Steve-HP-Pavillion. I got to this screen by simply clicking on Steve-Gaming on Seve-HP-Pavillion.

You can have Node1 Auto Accept from any other node or not.

I hope this is helpful!

Steve Caldwell
Bome Customer Care

---

Also available for paid consulting services: bome@sniz.biz

[FlorianBome]

@jmcdouga

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.

I must say, I am a bit confused by names like ‘Virtual Virtual In’. Maybe you’ve created a virtual Named MIDI Port ‘Virtual’ or the name of a node is ‘Virtual’?

A little background…

Bome Network (BN), and all our MIDI products, use the suffix Virtual In for the ‘private’ end of a virtual MIDI port that gets its MIDI data from a ‘public’ MIDI OUT port named without the suffix. This public MIDI OUT port is for use by other software on the computer.

And vice versa for the Virtual Out suffix: for example, let’s consider a port XYZ Virtual Out in BN. When sending MIDI messages to it from within BN, they will be received by an application using the public MIDI INPUT port XZY.

In general, when you create a BN connection from one computer ‘ABC’ to computer ‘XYZ’, you will see three things created on both BN instances. Here is the description for computer ‘ABC’:

1. An internal MIDI IN+OUT port named ‘XYZ’. It represents the network MIDI connection. Sending to this MIDI OUT will send it off via the network. What is received from the MIDI IN is received directly from the network.

2. One virtual port ‘XYZ’. Inside BN, it is represented by ‘XYZ Virtual In’ and ‘XYZ Virtual Out’.

3. Two automatic MIDI Routes: XYZ -> XYZ Virtual Out and XYZ Virtual In -> XYZ. These routes provide the glue from the internal network port to the virtual port. Note that these automatic MIDI Routes cannot be deleted, only disabled.

On computer ‘XYZ’, the same happens but with the ‘ABC’ name. Like that, when a 3rd party application on computer ‘XYZ’ sends a MIDI message to the MIDI OUT port ‘ABC’, the MIDI message will eventually end up in a 3rd party application on computer ‘ABC’ that is receiving on the MIDI IN port ‘XYZ’.
The full MIDI flow is this:

‘XYZ’ 3rd party app: MIDI OUT ‘ABC’
→ ‘XYZ’ BN: MIDI IN ‘ABC Virtual In’
→ ‘XYZ’ BN: MIDI OUT ‘ABC’
→ ‘ABC’ BN: MIDI IN ‘XYZ’
→ ‘ABC’ BN: MIDI OUT ‘XYZ Virtual Out’
→ ‘ABC’ 3rd party app: MIDI IN ‘XYZ’

The same happens for each Remote Direct MIDI port. The remote MIDI port name is prefixed with the remote computer name.

Just routings for Virtual to Virtual. hmmm!

‘Virtual’ to ‘Virtual’ sounds like a loopback MIDI route. BN never creates loopback routes on its own.

For me, it would be much easier to understand if you could post screenshots of what is happening, explaining what you would have expected instead? For the full picture, please show the Network connection page (listing Remote Direct MIDI section), and the MIDI Router page. Sorry for the additional hassle!

Be careful with port and computer naming.

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.

This is not the design. One BN instance can serve a given MIDI port to unlimited other BN instances. We’re not aware of a bug, either.

Thanks!

[FlorianBome]

(Please provide a configuration option to auto accept connection requests, I could not find a config option for this)

Steve pointed out how you can auto-accept connection requests per remote node. I don’t think this option is useful, because once a connection is established, it stays. You will only be prompted for a connection once. They’re paired now. After restarting BN or a device, and after network interruptions, the paired connections will be re-established without user interaction. The only way to end this pairing is by manually clicking on Disconnect.
I am considering to remove this per-node setting. It has frequently been misunderstood and actually caused other problems, too.

Additionally, there is a global option in the Network Settings:

I don’t recommend disabling this. With three nodes, you will need to acknowledge connections exactly 3 times and never after (unless you manually disconnect). It provides a safeguard against accidental connections and malicious attacks.

[FlorianBome]

PS: I’ve separated this discussion into a new topic. It’s unrelated to the initial request for the ‘scenes’ feature.

[jmcdouga]

Last night I snipped everything that I am seeing. Here is Node 1 - Rack1AMidi Names

[jmcdouga]

Here are the routes on Rack1aMidi

[jmcdouga]

Here is what is created in software devices

[jmcdouga]

This is the ‘Provider’ node and here is Node 2 - Laptop used for testing. It will be replaced with another NUC

and her is connected.

[jmcdouga]

I connected Proteus 1

Here is what no shows in Midi Ports

and here is what shows in routing

[jmcdouga]

I tried previously to create a set of Virtual names for the actual keyboard on Midi but the only think that would work is the following:

[jmcdouga]

Now Node 3 is MusicUtl primarily running MidiQuest patch editor/librarian. Here is it loaded with showing the equivalent of Rack1aMidi. The settings icon on each synth is where you specify the input and output ports for connection to that synth.

So now I connected to Rack1aMidi

And then enabled the Proteus1

Again here you see the Virtual Virtual In and Virtual Virtual Out ports that are used for the actual connection back to the synth

These were auto-created by selecting the Proteus1

[jmcdouga]

Now for the problem

You will note that there are two software devices that were created for the Proteus1 but have the same name.

[jmcdouga]

When I go into setting for the Proteus1 in MidiQuest, it shows Rack1AMidi and Rack1aMidi:Proteus Virtual. The Virtual Virtual In connection that is required to communicate across the network does not show because no software device has been created for it. Although this does show a Midisport attached, it was temporarily plugged in on the USB switch used to switch between MusicUtl and the Sequencer PC so it would not normally be attached.

[jmcdouga]

At this point I have a working method for connecting a midi hardware equipped Requester Node (Laptop currently) to a Provider Node (Rack1aMidi) and now I need help as to how to connect a software only based Requester Node to a Provider. Remote midi connect only works from the Provider node backwards to the Requester as it is not showing up on the Requester node just the Provider node.
It is interesting to note that the 4 midisport ports A,B,C,D that are doubled , MidiQuest can recognize them as MIDIsport in and out port and actually have a name but cannot read the input and output designations from the Rack1AMidi: Proteus 1 Virtual devices.

What do I need to do to get input and output ports to show in MidiQuest that will actually work across the network?

Thank you

[FlorianBome]

Thanks for the screenshots. Interesting setup!

Nodes 1 and 2

You’re using the virtual ports like aliases of existing physical ports. That should work, although I guess what you’d really like to do is to rename e.g. ‘MIDI 16x16 4’ to ‘Proteus1’. We’re considering adding ‘routing only’ MIDI ports to BN which aren’t exposed as virtual ports and thus don’t have the overhead of a real virtual port. And they don’t have the ‘Virtual IN/OUT’ suffix, either.

Just to clarify (by example of Proteus1):
On Node 1, you have this route:
"OUT Proteus1 Virtual Out" -> "OUT MIDI 16x16 4"
Now on Node 2, sending to the Remote Direct MIDI port ‘Proteus1 Virtual’ will be sent to Node 1, where it uses the above route to send it to ‘MIDI 16x16 4’.

I don’t see the other way round, but if you want to receive from the Proteus1 on Node 2, you can set it up like this:
On Node 1, create this route:
"IN MIDI 16x16 4" -> "IN Proteus1 Virtual In"

I don’t think you need to create a Remote Direct MIDI port on Node 1 for something on Node 2 as shown in post #11.

Node 3

In MidiQuest, you see the virtual port ‘Rack1aMidi:Proteus Virtual’. This is an IN+OUT MIDI port (as are all Bome virtual ports). Sending to it from MIDI Quest will end up (eventually) at Node 1 ‘Rack1aMidi:Proteus Virtual Out’, which is routed to ‘OUT MIDI 16x16 4’.

And if you set up my route above on Node 1, then whatever is received on ‘IN MIDI 16x16 4’ on Node 1 should be sent via the network, and be eventually received by MidiQuest on ‘Rack1aMidi:Proteus Virtual’.

PS

Now for the problem
[…]
You will note that there are two software devices that were created for the Proteus1 but have the same name.

This is normal (one each for IN and OUT). It is not a problem. Often, it is not obvious what the Windows driver subsystem does.

[jmcdouga]

You are correct. I assumed that Unlimited Midi Names was just that. The ability to use aliases for the physical midi ports. When you have a lot of ports on the network, being able to name them as to what the connection is, becomes really significant.
I do have a question. When I tried from the laptop to route the midi keyboard port I was using for testing, the connection would not work routing to the Proteus1 Virtual In or Virtual Out ports. It would only work if I routed from the MIDI 4x4 2 In to the Proteus 1 Virtual Virtual In as shown in the laptop routing. When I enable connect to a Virtual port in a rack I can see these Virtual Virtual IN/Out ports in routing but they are not software devices. What is their purpose? I will play some more with the connections on the MidiQuest PC tonight based on your comments.
All synths on the Rack1AMidi do have both input and output routing, the screen wasn’t large enough to capture all of them. With 32 ports on the Midiplus (16 x2) it makes for a lot of routes with 12 synths in the rack.
There are 5 Midiplus units in the network, 1 for each rack and each rack has its own NUC (4 Provider nodes + 1 Requester node that handles the Drum inputs). The other requester nodes use smaller M-Audio Midi units (2x2, 4x4, etc.).

[jmcdouga]

I have spent multiple hours over the past several days testing various scenarios. Rack1AMidi has been structured as per your comments with virtual in routed to midi in physical in ports and virtual out routed to midi out physical ports.
On the laptop connecting a physical in port to a virtual port only worked if I routed the midi in physical port to a Virtual Virtual In port. When I did this, I could see in the log on Rack1AMidi that the data was actually coming out the Virtual Out port and this worked since the Virtual Out port was routed to the physical out port.
On the MusicUtl PC(patch editor) using Virtual ports did not work at all. However, I did get it to work if instead of opening a virtual port on Rack1AMidi, I opened the connection to the physical port. It appears that for a software only node, the connection has to be between the software and the physical port on the target node. This does create some unnecessary overhead back on the Rack1AMidi node because of the routing of the Virtual Out to the physical Midi out, The data received is sent to both the physical midi out and to the Virtual Midi Out.
One last thing to try before moving on to the sequencer node is to try on the Laptop, mapping the physical midi in port on the laptop to the physical midi port on Rack1AMidi. If this works, then it would appear to eliminate the need at this point, for any virtual ports.
Unfortunately, this leaves me back with the issue of having to maintain a cheat sheet mapping each synth/input device back to a rack and midi port(currently almost 90 ports). Playing with the patcher editor PC also brought home the need for scenes but I will post my comments in that thread.