Cubase to BomeBox over WiFi has intermittent interruptions

Hi.
I replace my previous midi interface with Bome Box.
I use BomeBox without BMTP, just as a simple midi interface.
The setup is the Following:
Mac with CUBASE (wifi) > to BomeBox (Din) > to octatrack (Din) > to Synths.
Cubase sends:
Midi Clock
Transport
Program Changes messages
CC messages
After a few minutes, BomeBox temporarily interrupts the MIDI stream:
The midi output signal blinks and then stable again, but the octatrack stops playing.
Maybe the Bomebox is receiving too much data and stops sending data for a while?
I Use Bomebox without a router, with access directly from mac wifi.
If I use a midi interface from mac, connected to the BomeBox Din, everything works stable.
The advantage of using BomeBox is the remote control via Wifi, without cables.
Any idea how to stable this?
Thanks.

Hi,

The first thing I would suggest is to make sure your BomeBox is set to the correct country as having that set wrong can certainly slow things down.
Then make sure you set your MIDI routes on your BomeBox to only the devices you are using to prevent possible MIDI loops.

The only other thing that I would suspect is if you are in a busy WiFi area and other WiFi devices are competing for radio bandwidth. Unfortunately the only way to fix this is to either move to a quieter radio area or use ethernet instead.

Finally if your BomeBox is also has an ethernet connection, disconnect the ethernet as it is possible that BomeNet might be trying to use both ethernet and WiFi routing.

Let me know if any of this helps.

Steve Caldwell
Bome Customer Care


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

Thanks again SteveC
Bome box is configured to the right country.
Only one route (from mac to Din).
I am in a quite zone, i live in the country and only have one wi-fi signal. I even disconnected the home router.
I dont know how to disconnect the ethernet on the BomeBox. I dont have any ethernet cable connected.
In resume.
Have tried multiple options (different computers) and Daws:
Logic Pro, Cubase and Ableton Live always as master sending clock over wifi, even in a new project without any other midi message, the BomeBox always fail, and octatrack stops.
If I try the octatrack as master and connected to the Bomebox Din, sending signal over wifi to Ableton Live (Logic and Cubase cannot be Slave). it works fine, it’s never interrupted (maybe meaning Bomebox is sending right information over wifi, but nor receiving well).
Can anyone try something similar?
Sending the clock from a Daw via wifi, receiving the signal (Transport/Clock) through Din Midi.
I tried now with nothing connected to the Din Port, only BomeBox and computer. Can be tried like that.
If you look to the led of the midi Din output, he is always more or less stable. After a while (1 min, 2min or even 5min, random time) the led blinks a few times and stable again. In that moment my sequencer stops.

Can I assume you are running Bome Network version 1.4 and BomeBox firmware version 1.5? If not, update those first.

Also make sure the last device in the MIDI DIN chain does not have MIDI thru set otherwise there will be a MIDI loop created. Although this issue would be true with both only MIDI DIN and USB, since USB is faster, the issue would be more prevalent.

Also make sure on your BomeBox “Auto-Create MIDI routes” is not checked, (which I’m pretty sure you did already).

Steve Caldwell
Bome Customer Care


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

Thanks SteveC.
Tried almost everything. :frowning:
Downgrade to firmware 1.4.
Reset to factory defaults.
Only have one midi route from macbook to Din out.
The Din Out from BomeBox runs to Din In of the octatrack and do not return, neither to mac or Bomebox.
Just wondering if i have a faulty unit. I Bought it from Thomann and can return it, but if it is something common, maybe i´ll keep it.

I’ve not seen this before although I know that WiFi may be less reliable than wired ethernet. This would be true for any WiFi device. Maybe you can monitor the traffic with MT Pro to see if we are getting something we don’t want. Are you using MIDI Remote Direct Ports on your Mac or are you just sending to the main network port. It might be better to select the BomeBox DIN port on your Mac as a MIDI remote direct port and then turn off all routing in the BomeBox as MIDI direct would bypass the BomeBox MIDI router that way.

Steve Caldwell
Bome Customer Care


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

Also you need to be at firmware 1.5 on BomeBox to use Remote Direct MIDI ports. On your computer you need Bome Network 1.4

Steve

Hi, this is not a known problem. As Steve suggested, it still sounds a lot like a WiFi issue. Interference can always occur from unexpected sources. In the interest of eliminating other causes, could you try with an Ethernet cable, if one available? It’s also strange that the way back works without problems. WiFi connections are always bidirectional.

Also, the Advanced configuration (follow bottom link in web config) allows changing the WiFi channel. That could improve matters, too.

Last, but not least, it is theoretically possible that your unit is somehow faulty. If shipping to Germany is not a problem, we can also provide a replacement box directly to you.

Hello Florian.
With ethernet cable works fine, at least for the entire project (40 minutes) runs without any stop.
In the afternoon tried with Ableton in slave mode (Bome receiving the clock via Din from octatrack and send it via wifi to Ableton) and worked fine at least for half an hour (without blinks or stops).
Tried changing the wifi channel and at first try make it worst. Change the With to 40 MHz and worked for a long time (15 minutes) but then an interruption appeared again.
In the afternoon also tried sending the clock via Ipad wifi, with genome midi sequencer, and do not worked.
This is the configurations I use (pdf). I assume everything is ok.

Settings_Bome.pdf (281.7 KB)

Hi, so sorry for the hassle! Thanks for the great documentation using video and screenshots.
So I think we can exclude the internal MIDI routing engine as a cause.
WiFi still seems to be the root cause, somehow. We do know that many customers use MIDI over WiFi for their shows.

I assume that you’re running BomeBox WiFi in HotSpot mode?
How far are your Mac and the BomeBox away?

This seems like a temporary interruption (e.g. WiFi signal loss), and then resuming. Because data was lost in between, the Octatrack might not be able to pick up?

Could you run one more test? It would be very interesting to retrieve some some log files, and capture the MIDI OUT of the BomeBox. I.e., use a MIDI interface connected to the Mac, then record the MIDI stream using e.g. Bome MIDI Translator Pro. If you don’t have a license, I can provide a temporary license to overcome the 20-minute trial time.

Steps:

  1. In BomeBox web config, go to Log page and check verbose:
    image

  2. Use a USB-DIN adapter connected to Mac and to the MIDI OUT of the BomeBox
    (alternatively, you can route the MIDI data back from the BomeBox to the Mac using a MIDI cable from MIDI OUT to MIDI IN, or, yet another alternative, a direct loopback via the BomeBox MIDI Router)

  3. On Mac, start MIDI Translator Pro.

  4. Click the MIDI icon at top right (or MIDI menu → Project Default MIDI Ports). In the MIDI IN list, find and check the USB-MIDI DIN USB interface. The status should say Open now.

  5. From the View menu, enable the Log Window. In the Log Window, check all checkboxes (Timestamped is very important):
    image

  6. Now run your Cubase project. The Log Window should start capturing the MIDI stream.

  7. Soon after the error happened, stop Cubase, and go back to MT Pro’s Log Window. If you can see from the timestamps where the error happened, scroll a few hundred lines up (to catch some more history), and select all following lines, at least a few hundred lines after the error, too. Or, select all (Command-A or right-click menu). Then copy/paste the log to this forum (or send it to us via email).

  8. Now go to the BomeBox web config:
    a) go to the Log page, copy/paste anything +/- a few minutes before and after the error happened
    b) You can also go into the Advanced Configuration and do the same for the System Log and the Kernel Log from the Status menu.

Maybe we can see anything from all those logs!

Thank you very much. I know it’s cumbersome, but it’s probably best to first try to find out if there is any other cause before replacing the hardware – and then possibly still experiencing the same issue!

Thanks!