Audio scrubber jump to position working on desktop, but not on mobile

Hi @JimScott!

I have been working with this and have found some interesting results that I wanted to share.

In trying to add your demo code to my project, I was still not having any luck with my setup. The more I looked at it, the more it seemed like the issue was being narrowed down to two main factors as being a possible culprit:

  1. Having multiple layouts knocks the touch numbers out of whack. However, it seems like the issue may not be an id naming conflict, but rather something else. I say this because adding even a single blank layout (with no elements placed on the layout at all) still knocks the xLoc numbers out.
  2. Having a ‘group in a group’ setup definitely creates an offset problem, but I found that there is a good chance the main issue is more than just folder grouping. But rather, how the Flexible Layout settings are set.

I figured one way to prove the notions above would be use your demo file as a point of reference. I figured I’d try to individually add the issues listed above to your project and test (so as to isolate the issue, and eliminate the possibility that my setup or any of my elements was causing the undesirable behavior).

I made three different test files out of your demo (the three test files can be downloaded here).

  • The first test, named touchDemoTest.1, is your demo file, with only one modification: the Slider Ensemble group has been nested in another containing folder that is set with all Flexible Layout settings active. It is set with with the same Flexible Layout settings that I have active in my project which is: Pins & Sizing arrows and pins checked on, Shrink to Fit chosen from the dropdown, and Zoom contents checked on. Just placing the Slider Ensemble group in another group caused displacement. The added step of activating the Flexible Layout settings on the outer group seemed to cause number displacement as well, (thereby further compounding the distortion).

  • The second test, named touchDemoTest.2, is your demo file but with a different modification than the one outlined above. On this one, I added a single blank layout. I found that by adding a second layout (even with no elements placed on it at all!), major xLoc number distortions resulted. I have no idea why this would be, and since there are no elements placed on the blank layout at all it seems like it can’t be an id naming conflict, but rather just the layout itself.

  • The third test, named touchDemoTest.3, is your demo file but with both of the two previously listed modifications above combined. Not surprisingly, with both of these modifications added, the xLoc numbers were totally messed up (and worse than either of the issues alone. Combining both seemed to compound the amount that it was off by).

So, this being the case, I’m starting to wonder if a reasonable solution is even possible?

If my project was only a single layout and if I didn’t need all of those Flexible Layout options checked in order to maintain my design, then the functionality in your awesome demo would work perfectly!

But unfortunately, it seems due to the fact that my project needs both multiple layouts and Flexible Layout options, since these two factors seem to be at the heart of the issue, I’m starting to accept the likelihood that I may actually be hard pressed to even find a working solution.

The only other thought that comes to mind is using libraries (as @h_classen mentioned).
Might try looking into that.

I guess overall I am a bit bummed (and somewhat surprised) to discover that this sort of tap/touch-to-location feature isn’t a standard option for mobile sliders in 2019.

Thankfully, it’s not a make-it-or-break-it feature and if I have to leave it off then it would not be the end of the world. In your opinion do you think it’s worth continuing to look for solutions? I’m not even sure how to even approach troubleshooting the blank layout issue - seems so unrelated!

Anyway, I really appreciate your time with this. If you have any further thoughts on avenues to explore then I’d be game. However, I also don’t want to obligate you to participate in what might be a wild goose chase, lol. Thanks again and all the best. :slight_smile:

Now this is going to take sometime to sort through. :upside_down_face:

The major issue I’ve hit in a quick run through is the presence of the empty~blank layout. In touchDemoTest.2 I “solved” the issue by subtracting 100 from xLoc = (xLoc - sliderLocX);
i.e.
xLoc = ((xLoc - sliderLocX) - 100);
gave me a perfect hit no matter where I moved the “Slider Ensemble” group in the Scene - always 100 pixels off. Which would indicate there is an unknown container (or its equivalent) in the code that is offsetting the visible elements 100 pixels.

I’ve used Developer tools to hunt for something with this value (100), nothing so far - but I’ve just started. As the Wise Philosopher tells us, hard coding is not a real solution at least in this situation - so we need to find out what is skewing things.

And of course - as You know - removing the empty layout allows the original code to work fine…
a puzzle.

I will be curious to see if switching the element references to classes instead of IDs has any effect - it shouldn’t given there are no elements in the empty layout… but this whole scenario strikes me as weird. Possibly a fly in the Hype ointment - or browser shenanigans.

In any event sorting through all these things (including the flexible layout issue) will take time as I can find it… maybe by this weekend I will have something concrete.

Hey Jim,

For what it’s worth:
I was also able to get a perfect hit in touchDemoTest.2, but curiously, the offset that worked for me was: xLoc = ((xLoc - sliderLocX) - 70); - for both iPad pro and iPhone x. This would seem to that much further confirm the notion that hard coding would not be an option for the ‘possible unknown container’ issue since it seems prone to change.

And I totally agree that for the ‘empty layout mystery’, a fly in the Hype ointment, or browser shenanigans sounds about as reasonable as explanation as any at this point, lol!
A puzzle indeed.

1 Like