XR16 Experience

First, lots of successes...

I powered up my XR16, connected my iPhone to its built-in WiFi access point, and then opened the XAir Monitor Mixer app.

The app found and connected to the XR16 almost instantaneously.

It brought over the scribble strip values and displays them properly.

The previous state of the sliders also came over.

I didn't bother plugging anything into the mixer, so to see if things were working, I also connected my iPad and brought up the Behringer X Air app to see that if I moved a slider on the Monitor Mixer, it would also move on the iPad and vice-versa. It did, so I take that to mean things are working the way they should.

So, all-in-all, it pretty much works.

However, there were a couple issues...

  1. When I click the gear, the monitor buses have no labels. I just see 4 solid yellow boxes (see attached screen grab).

  2. Sometimes when I try to move a slider (makes no difference whether it's an individual channel or the master), it won't move. Then, after a few seconds, it will suddenly snap to the new position, or sometimes it won't move at all. If I wait long enough it will eventually "unstick" and start moving, though.

  3. Although I had nothing plugged into the inputs, the VU on every channel shows green for about 1/8th of its height. Sometime it vibrates up and down 1 tick or so. Looks like what you'd see if the gain into the meter is way too high and you're just seeing the noise floor.

  4. When viewing the mixer screen and I rotate the phone from portrait to landscape, the screen does a rotation animation, but ultimately just shows the same screen no matter the physical orientation of the phone. I guess it doesn't really matter, but it would nice if you could turn off the animation when the orientation of the phone changes since the screen doesn't actually change in appearance.

Comments

  • 3 Comments sorted by Votes Date Added
  • ETET
    edited September 2017 Vote Up0Vote Down

    First, thanks so much for testing the app for me. It's hugely helpful, as I don't have access to these mixers myself.

    I'm glad it "pretty much works". :)

    I'm going to address the issues out of order, because the first two may be related:

    1. Sometimes when I try to move a slider, it won't move. Then, after a few seconds, it will suddenly snap to the new position, or sometimes it won't move at all. If I wait long enough it will eventually "unstick" and start moving, though.

    This is most likely a symptom of packet loss. The mixer communicates using UDP, sometimes referred to as unreliable datagram protocol because it doesn't guarantee message delivery.

    When you move the slider, I send a UPD message to the mixer, but I have no way of knowing that the message has arrived. If I leave the fader where you put it and the mixer doesn't actually get the message, then my fader position is a lie. so, as long as your finger's on the fader, I follow it. But when you release your finger, I show the last position that's actually been acknowledged by a message from the mixer. If the connection is good, you see no lag. If there's packet loss, it can get glitchy.

    If you have an iPad, when you see lag like that in my app, can you try the faders in the Behringer's iPad app and see if you see similar glitchiness? That's what I found when I tested here. The PC app doesn't do that, so I think they have a different strategy.

    Although my feeling is that it's less technically correct, I'm going to change the app to leave the fader where you release it and just hope that the mixer received the message. There's a chance that the fader position will be inaccurate if there's packet loss, but it will appear much less glitchy.

    1. When I click the gear, the monitor buses have no labels. I just see 4 solid yellow boxes (see attached screen grab).

    This is more worrisome. This can also be caused by packet loss, but the fact that you have all the scribble strips casts some doubt on that hypothesis.

    Every 10 seconds, my app will ask the mixer for the channel and bus names/colors. Can you try waiting for a bit (a minute or so) and see if it eventually picks up the bus names/colors? If it eventually gets them, the problem is packet loss. The built-in wifi sucks, so that wouldn't be too surprising. If it doesn't, then there may be some difference in how these values are acquired on the XR18 vs the XR16 (it should be identical), and I'll probably have to get hold of an XR16 to fix it.

    Although I had nothing plugged into the inputs, the VU on every channel shows green for about 1/8th of its height. Sometime it vibrates up and down 1 tick or so. Looks like what you'd see if the gain into the meter is way too high and you're just seeing the noise floor.

    Hmm... I recently changed the algorithm I used for processing VU meters, was meaning to test it, and never did. Doh. Restoring my old algorithm, which works much better.

    it would nice if you could turn off the animation when the orientation of the phone changes since the screen doesn't actually change in appearance.

    Agreed. I'm aware of it, but it's been low priority. Even though I always render in landscape, I want the app to actually allow rotation so if you're using it in portrait and you swipe in from the top/bottom the notifications/menus are where you expect them. Just need to find out how to suppress the animation.

    Unfortunately, I can just shoot you another build, because Apple has to approve a build for beta testing which takes days.

  • Thanks for the response... Regarding the slider stuff...

    I understand the slider position and packet loss problem. But I'm not sure I like the idea of setting the visual slider position on the screen without getting confirmation from the mixer that it has really changed.

    How hard would it be to create a "ghost" slider that's overlayed on top of the "real" slider (by overlayed, I mean along the "Z" axis which is perpendicular to the plane of the phone's screen)? Move the ghost slider based only on input from the user. Move the real slider based only on feeback from the mixer. Most of the time, if the data makes a proper round-trip to the mixer, then the ghost slider and real slider will line up and you won't see it. But if there's packet loss, you'll see an offset. Furthermore, as for as long as there is an offset between the ghost slider and the real slider, keep sending the user-input position to the mixer. Eventually it should get though. But.. maybe there should be a timeout mechanism so that if the offset persists for a long enough time (a couple of seconds?), you give up and go ahead and just snap the ghost slider to the real slider's position.

    As for the bus names... I've never made any attempt to customize the names of the buses. They're just Bus 1, Bus 2, etc. Perhaps that's why you're not getting bus labels from the mixer? Maybe initialize the bus names on the config screen to "Bus 1", "Bus 2" etc. so that there is something there even if the mixer is slow to send you the labels, or doesn't send you any at all.

  • I've never made any attempt to customize the names of the buses. They're just Bus 1, Bus 2, etc.

    Ahh... that explains it. Behringer's app show defaults if no names have been set. My app just shows a blank label.

    Perhaps that's why you're not getting bus labels from the mixer? Maybe initialize the bus names on the config screen to "Bus 1", "Bus 2" etc. so that there is something there even if the mixer is slow to send you the labels, or doesn't send you any at all.

    That's a great idea. I'm going to do the same thing with channel labels (01, 02, etc.)

    How hard would it be to create a "ghost" slider that's overlayed on top of the "real" slider

    It wouldn't be that hard. My concern is that it would be confusing. You and I would understand that's happening, since we understand the issue, but I think to the uninitiated it would be bizarre looking.

    I'm not sure I like the idea of setting the visual slider position on the screen without getting confirmation from the mixer that it has really changed.

    Nor I. That's why I implemented it the way it is in the first place. That was a carefully considered design choice.

    However, the feedback I get when users see it is that it's a bug. What's happening is really non-obvious.

    On further consideration, I don't think it's that bad to just leave the fader, for three reasons:

    1. As you drag the fader, it's sending a message for every single increment of the slider, so if you move the slider an inch, there are maybe a dozen messages sent. Some of them will probably get through, and as you and Ronn reported, the fader appears to eventually catch up. So the position is not totally inaccurate. And this tool is really about setting levels to taste in your monitor, so what matters is that you eventually hear what you want, and you'll keep dragging the fader until that happens. So a bit of inaccuracy in the visual representation of the fader is not that bad.

    2. The reports I've gotten have all been people testing with the internal WiFi, which you'd never used live (or if you do, you're going to run into issues much worse than laggy faders), so inaccuracy is likely to be non-existent or very small with a 5GHz router.

    3. The faders in Behringer's iPad app work like mine (i.e. if you lose connection, the faders don't move; if you lose packets, they glitch; when I discovered that, having implemented the same solution myself, I knew exactly what they were doing internally). However, the faders in Behringer's PC app work like we're proposing: they stay where you put them, whether the mixer has responded or not. I don't see people complaining about this in the PC app, so maybe it's not so bad? o.O

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!