Bome Network Pro - Multiple Virtual Ports?

Two (2) questions: 1. With Bome Network Pro, am I able to open multiple connections (virtual ports) from one computer to another computer? 2. Am I able to run multiple instances of Bome Network Pro (BNP) with a different network port?

Here's why I ask: Basically, I need more than 16 MIDI channels. On my primary computer, I have two sound modules connected via USB (a Yamaha MOTIF-RACK XS and a Roland INTEGRA-7). BMTP and BNP are running on the primary computer. I also have a Windows Surface Pro with BNP and separate applications to manage the MOTIF and INTEGRA. Each app uses all 16 MIDI channels. I would like to be able to use these applications concurrently while routing MIDI messages appropriately. I know that I could accomplish this in BMTP by enabling/disabling presets to control MIDI routing, but this would require a function on the Surface Pro to trigger BMTP preset changes each time I switched between using the MOTIF app and the INTEGRA app. I really would like to avoid this if at all possible.




Right now, Bome Network exposes only one MIDI network port per computer connection. There are plans to do what you ask in a future release. I am not sure, but I don’t think you can open more than one instance of Bome Network Pro on a single computer, however you can have network connections to multiple computers from a single instance of Bome Network Pro.

A workaround might be either using different presets as you suggest or use some other scheme with Bome MIDI Translator Pro such as perhaps converting notes from each instrument to some sort of Sysex Message to handle the routing. The Syesex message would contain information on the source port on the sending system. Then on the receiving system, you could have MT Pro look at the sysex message to route not only to the required channel but also the required port. You would then embed the actual MIDI message within the Sysex so it would be some sort of proprietary protocol.

Sending side would send based on source port

Incoming Note on Note 40 channel 1 on Port 1

Sysex header – Source Port, Channel , Encoded MIDI Message(no high bit within this message anywhere) End of Sysex

Then over the network. On the other side revers the procedure.

The reason I suggest Sysex is that Sysex message would not be broken up when making the trip over the network. An entire sysex message would need to be retrieved on the receiving end before processing the embedded MIDI message.

Kind of a proprietry sysex protocol to handle port routing.

As I said, there are plans in the works for exposing more ports and I can ask Florian, but I’m pretty sure, he will not give a date as I have never seen him pre-announce anything.

I suggest if you want to use the Contact me form to ask him and perhaps he may also have other suggestions.


Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist




First of all, thank you very much for your quick reply.

Wow! This sounds very interesting. Let me see if I understand it correctly…

I would have BMTP running on both computers (I would need to install and configure BMTP on the Surface Pro). On the Surface Pro (where the MOTIF and INTEGRA apps are running), I would create/open a BMTP Virtual MIDI Port for each app. Within each of the apps, I would route the MIDI data to the ‘app specific’ BMTP Virtual MIDI Port. BMTP on the Surface Pro would then convert the MIDI message received from the app into a propriety SysEx message (with source app information and the original MIDI message embedded). The propriety SysEx message would be sent to the primary computer using the BNP port. BMTP on the primary computer would reverse the process and send the original MIDI data to the appropriate USB port connected to the hardware.

This sounds like a doable solution for my situation. Please let me know if my understanding in on target and I’ll post an update once I try it out.



Yes, this is what I had in mind. You would then basically be using the Sysex to indicate the additional port routing information. As I think about it, maybe you don’t have to include the source information in the sysex message and jus the destination information. The trick is that whatever information you include on the transmitting end, you use on the receiving end to determine which port to route it to. You assign a port number to each of the attached actual ports (doesn’t matter how you assign them as long as they are consistent) and then have different translators (or presets) to handle the output to each of the receiving ports.
As I think about it, I think I would embed both the source and destination port number in the encoded sysex so you could use either piece of information on the receiving end to deterime the routing. Say you have 16 ports, you could use the first 4 bis of a veriable to determine the source and the second 4 bits the destination. That way you could encode this into a single variable so from port 0 to port one the value of the variable would be 0x10. For port 15 to port 15 it would b 0xFF. If you want to have more ports available on both ends, of course you could use more bits in the encoding but I doubt if you would need more that 16 ports each with 16 channels (256 combinations).
Instead of 90 for note on on MIDI channel 1 within the embedded sysex, I would use a different scheme to identify the type of MIDI message. For instance for note on you could use 1x and for note off 2x for controller message 3x etc
So and example MIDI message coming from port 0 on MIDI Channel 1 destined for Port 15 MIDI channel 1 on the receiving side Note-on note 64 velocity 127 would look like this:
HEADER 0xF0 0x10 0x40 0x7F END
On the receiving end end you would use the first byte after the Syexe head for routing. Convert the 0x10 to 0x90 and then leave the note number and velocity untouched.
Make sense?
Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
PS. Port FF in the sysex would be a non-no as the high order bit in a sysex has to be 0. If you want 16 ports, you would probably break up into 2 bytes so instead of FF it would be 0F 0F.
First byte being destination and second being source. (or visa versa as long as you are consistent) You could still use a single global variable and extract the bits into two bytes before sending.
Sysex would look like the below:
Header 0F 00 10 40 7F Footer


I am totally on board with this concept! The more I think about this approach, the more I like it. Also, I fully understand the need to remap the embedded MIDI Command portion of the MIDI message because the first bit of all bytes following the ‘MIDI Status’ byte cannot be ‘1’. Example: Let’s say I wanted to send a Change Control Volume of 100 to a synth module. I could construct a proprietary SysEx message as follows:

Incorrect: F0 aa bb st B0 07 64 F7
Correct: F0 aa bb st 03 07 64 F7

Where: ‘aa’ & ‘bb’ could be some ‘command identifying’ information. ‘s’ could indicate the source port (app) and ‘t’ could indicate the target port (synth). Both ‘s’ and ‘t’ could have valid values of 0-7 (for a total of 8 source app ‘virtual ports’ and 8 target synth ports). If I need more app virtual ports than 8, I would have to change ‘st’ to ‘ss tt’. LOL I don’t think I’ll need to do that though. The high order bit of the Change Control command (B0) would be stripped (03) on the transmitting side and then reapplied on the receiving side.

I can also embed the native synth SysEx within the proprietary SysEx as long as I stripped off the leading ‘F0’ and trailing ‘F7’!

The beauty of this approach is that it is not difficult to implement. It does add two (2) additional processing layers (one on the sending side and one on the receiving side). But I don’t think this will be a noticeable overhead. Certainly needs testing!

Thanks again for your suggestion!


Hi Greg,
I would recommend that the identifying information in the sysex header conforms to MIDI standards.
As far as embedding sysex within the sysex stream, I would recommend you don’t do this and just let the original sysex go to all ports untouched. Normal Sysex usually has it’s own identifying information so that it is properly processed (ie MFG, Model and Serial), so the other devices will just ignore the information anyway.

Yes note-on could be 1x note off 2x, control change 3x (with only 2 trailing bytes), PC could be 4x. (or whateve convention you want to follow).

Go to for guidance on the sysexe header, I think 7E followed by a series of bytes is the “Generic” MIDI manufacturer for those that don’t register with MIDI.ORG.
I think I used 7E followed by the ASCII for “BOME” when I built the MIDIBuddy Helper for Bome MT Pro.

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist

Greg, if you don’t have the time or patience to set this up, send me and email and I can put this together for you for a fee.