Bome Box USB Workflow

Bome Products
,
1

hi there!

great software, and i need to upgrade :slight_smile: looking at the bome box,
and I wonder, how many USB-Midi-devices could I connect with a powered usb3.0 hub?
would lets say 8 or 10 devices work? I have some trouble with too many devices on hubs connecting to another hub, because my usb ports are overcrowded.
when would you recommend to use regular midi port connections?

let me try to explain my setup, is that a configuration that would work? sorry for so much text :wink:

the Mac Pro would be recording audio from instruments and recording/saving/arranging all the midi-notes for sequencing/arranging.
so the Mac Pro would be the Midi Clock Master.

there are two computers, the mac pro 2009 and a amd ryzen laptop/win 10, synced with ableton link over a different ethernet, running bitwig on both machines.
Midi Notes go from the mac pro to the PC, and play notes there on vst midi instruments + fx.
The audio is for playback from both machines is routed into a rme fireface uc with direct monitoring (which acts as a monitor controller) connected with analog connections, so the asio latency from both machines is not adding up.
(for mixing: exchanging the bounced wav-files from one machine to another).

Devices:

(1)hardware sequencer
USB 2.0

(2) Midi Keyboard
USB 2.0

(3) Icon Platform Nano Air ( which is a Mackie Control device, or should this not be routed through bomebox)
USB 3.0

(4) simple Midi Encoder controller
USB 2.0

(5) Hardware Synthesizer X
USB 2.0

(6) Hardware Synthesizer Y
USB 3.0

(7) second Midi Keyboard
USB 2.0

————————> USB 3.0 Hub Anker —> BomeBox

(1) --> mapped to BomeBox ETHOUT1 Midi Channel 1
(2) --> mapped to BomeBox ETHOUT1 Midi Channel 2
(3) --> mapped to BomeBox ETHOUT1 Midi Channel 3
(4) --> mapped to BomeBox ETHOUT1 Midi Channel 4
(5) --> mapped to BomeBox ETHOUT1 Midi Channel 5
(6) --> mapped to BomeBox ETHOUT1 Midi Channel 6
(7) --> mapped to BomeBox ETHOUT1 Midi Channel 7

(the recorded midi clips will in that case save all the midi notes+cc data from all used devices, that is pretty nice)

BomeBox ETHOUT1 —> Mac Pro with Firewire800/Ethernet Adapter —> Bome Network Tool Standard, License 1 -> Bitwig

and also to the second computer:

(1) --> mapped to BomeBox ETHOUT2 Midi Channel 1
(2) --> mapped to BomeBox ETHOUT2 Midi Channel 2
(3) --> mapped to BomeBox ETHOUT2 Midi Channel 3
(4) --> mapped to BomeBox ETHOUT2 Midi Channel 4
(5) --> mapped to BomeBox ETHOUT2 Midi Channel 5
(6) --> mapped to BomeBox ETHOUT2 Midi Channel 6
(7) --> mapped to BomeBox ETHOUT2 Midi Channel 7

BomeBox ETHOUT2 —> MSI Bravco 15 Laptop / Ethernet to USB-C-Adapter —> Bome Network Tool Standard, License 2 (?? do i need a second license?) —> Bitwig

when playing back sequences from mac pro —> Midi is routed back

Bome Network tool Midi Out (correct ?) Midi Channel 1-7 —> BomeBox ETHERNET-IN-1 , Midi Channel 1-7
–> mapped to BomeBox ETHOUT2 Midi Channel 1-7
will this be more staple or reliable than a apple network midi connection (to rtpMidi)?

how does this sound?
thanks! :slight_smile:
cheers, Henrik

2

Hi, I believed I answered this in email but let me know if you have any more questions.

To restrict channel mapping to only certain channels you will need to load a Bome MIDI Translator Project into BomeBox.

BomeBox to BomeBox, PC or Mac is OK with standard Bome Network, however if you want PC to Mac, Mac to Mac, or PC to PC over Bome Network you will need the Pro version,

Bome Net is very stable and will usually auto-rediscover upon reboot which is something that rtpMIDI doesn’t always to well.

Steve Caldwell
Bome Customer Care

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

hey,
i wanted to share the conversation, thanks for the feedback!

i now read more about midi-jitter, and that i should use an external clock source. i would use the sequencer Topaiz Squid.

but the more i read, the more the question comes up: when would a device like one of those real expensive and dedicated midi clock source/clock-sync-devices be necessary? (S-N-D http://www.s-n-d.com/, E-RM http://www.e-rm.de/, Expert-Sleepers http://expert-sleepers.co.uk/moduleoverview.html, Innerclock-Systems http://www.innerclocksystems.com

i read that midi jitter mostly happens on bad USB connections with wrong cables, wrong connections (usb3/usb2/usb-c/???) and not enough power supply. is that something i have to watch for or is the bomebox taking care of that?

and what I hardly found information on is about high precision midi timestamping, especially on windows, does the bomebox support that? Reaper lets me choose (on windows) between high and low precision (low precision = old windows standard?), on a mac that setting seems irrelevant.

old! link from 2007 but goes deeper: https://www.soundonsound.com/techniques/solving-midi-timing-problems

cheers henrik

4

MIDI Jitter usually come into play as a part of the transport path which could introduce random delays if not reliable. a good USB or local ethernet connection should not be an issue. For network, you need to consider other MIDI traffic on the same network. If you use WiFi, it is more subject to jitter. I don’t think you need an expensive clock generator, just a reliable one and a good MIDI path for transporting the signal.

Steve Caldwell
Bome Customer Care

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

Chiming in with a few details:

  1. neither BomeBox, nor MIDI Translator Pro use timestamping. The protocols used in the BomeBox don’t have time stamping. They’re real time systems which always do everything as fast as possible.
  2. Therefore, our products do not have a precision setting, because there is not any timing precision to consider
  3. Our virtual MIDI ports, which are used by Bome Network (for connecting a BomeBox) and by MIDI Translator Pro, provide time stamps, but operate in real time, too.
  4. Because our products do not time any MIDI messages, most jitter or delay that occurs is introduced by the transport. As Steve said, local Ethernet has best performance, then USB, then WiFi. MIDI-DIN is between Ethernet and USB: it has very good timing, but very little bandwidth.
  5. USB timing is not so good to begin with: jitter ±0.5ms, more or less fixed delay
  6. But I would be very surprised to learn that USB performance depends on cables. Of course, the cable should be somewhat reliable. We have not measured or heard that USB-MIDI devices connected to the BomeBox have bad timing performance.

So the absence of a “high precision” setting does not mean that there is bad performance in the BomeBox, Bome Network, or in Bome MIDI Translator Pro. They all use our highly optimized MIDI processing engine to introduce as little delay/jitter as possible. Any delay caused by USB or network is propagated as is.

I hope that clarifies a bit…

1 Like
7

hey!
thanks a lot for your answers, yes that was very interesting and
well yeah its amazing how much more stuff there often pops up about midi that I still didn’t know!
probably because it mostly just works and nobody needs to find out.
greetings henrik

8

Hi Florian,

Regarding USB MIDI jitter, did you see this post from Colin Fraser on Sequentix Cirklon forum ?
http://forum.sequentix.com/search.php?keywords=Jitter&t=3166&sf=msgonly
Do you think it could apply to BomeBox as well ?
Sorry if it’s a naive question and thanks for your time.

Not sure if you can open the link without logging in, so here is a copy :

« Aug 05, 2020 by sequentix

The main problem with USB MIDI also turns out to be an advantage, in the right circumstances.
I’ve only recently discovered some aspects of USB protocol were not as I thought.
There are three main data transfer types - interrupt , for high priority transfers of irregular data; isochronous , for regular, high priority transfers of equal sized chunks of data; and bulk , for low priority transfers of potentially large chunks of data.
USB MIDI uses bulk transfer, which has the lowest priority of the three - no guarantee of bandwidth or latency on a busy bus.
The allocation of bandwidth to interrupt and isochronous transfers is based on the regular USB ‘frame’ interval.
That’s 1 millisecond on USB up to USB full speed (12mpbs), and 1/8th millisecond for USB 2 high speed (480mpbs)
In order to control the allocation of bandwidth, interrupt and isochronous transfers only happen once per device per frame period.
The host knows the maximum transfer rate and sizes for each device, so it can guarantee response times and bandwidth.
Bulk transfers, although the lowest priority, can happen at any time.
If the bus is heavily loaded with interrupt and isochronous traffic, then your bulk transfers may be late…
But in most cases, there will only be one device on a USB bus.
in which case, the low priority of bulk transfer isn’t a problem.
And the fact that the host doesn’t have to wait until the next frame to send another packet means the latency can be minimised.
That was what I had misunderstood about USB MIDI - I thought all transfers were limited by the frame rate.
Looking at MIDI output from my PC, I’d always seen a maximum of one USB transfer per millisecond.
But that turns out just to be a limit of the application or driver layer on the PC.
With Cirklon 2 acting as a USB host, and a class-compliant MIDI interface attached, when the OS sends a block of data to the USB controller to send to the interface, that bulk transfer goes out asap.
Also, when the USB host is reading data from the MIDI interface, once a read request has been issued to the USB controller, it immediately polls the device for data. If the device has no data to send, it NAK’s the IN (read request). The USB controller’s response to the NAK is to re-issue the read request, which it does at a very high rate until it gets some data.
So the receive latency can also be very low.

This video shows a logic analyser capture of MIDI output from Cirklon 2 -

There are three traces active, labelled TX 1, RX 2 and RX 3.
Three tracks are playing the same pattern, one routed to port 1, the other two routed to USB hosted ports.
TX 1 is MIDI output 1 of the Cirklon.
RX 2 and RX 3 are receiving MIDI output from 2 ports of my Midiface 16x16, connected to the Cirklon 2 USB host port.
Those outputs are patched back into Cirklon inputs just so they can be seen by the logic analyser.
You can see that the extra time taken to send via the Midiface is only in the order of 300 microseconds, with less than 50 microseconds jitter.
Much better than I was expecting, given my false belief that there could only be one USB output transfer per millisecond (which would impose at least 500 microseconds latency with +/-500 microseconds jitter).
(one annoyance is that the USB MIDI interface does not implement running status, so there are a few extra status bytes thrown in)

USB 3 improves on USB 2 by having Super-Speed transfer (5 gbps). Running at super-speed, the maximum sizes of packets increases significantly, and the use of frames for transfer timing and synchronisation is replaced with more efficient ‘isochronous timestamp packets’.
Really USB 3 is a separate interface to USB 2, running over additional conductors in the cable, with different electrical characteristics, in parallel with the legacy USB connection. USB 3 and USB 2 transfers can be made simultaneously over their separate busses. »

10

Hi @Hotchkiss , thanks for the link. The BomeBox uses the standard Linux USB driver, and our measurements confirm 1ms framing…