Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Grenache]

I have Theater View on my Windows tablets and after a lot of practice I get along. However, to watch someone else pick up the tablet and trying to control MC is another story. Even with the Obsidian Touch skin it just doesn't work very well. I've also tried JRemote, which is of course way better, but sadly it's not being developed anymore. Instead I use EOS on my Android tablet, but this isn't a JRiver app, so only the developper knows its future. Yet another touch option is Gizmo (and WebGizmo), which I don't care for, mainly because it has some limitations and looks dated.

During the years there have been many discussions on touch support, recently the "Pretty Face" thread (though started more than a year ago). This discussion seemingly led to the development of "Panel", which is both for lighting and MC, but - at least for now - a far cry from the original idea proposed in the "Pretty Face" thread. And then there's even another touch option in the making called "OneRemote", which - as I understand it - might not be relevant for controlling MC. So a lot of touch options, but none that are working at the level of what you should expect from MC.

JimH asked me to come up with specific suggestions, but it's actually quite simple. What I propose is to take advantage of the ongoing development of Theater View for Mac and Linux and instead of "just" doing a port of Theater View to modify it so it works seamlessly with touch. I know this wasn't the original intent of Theater View, but then again touch didn't really exist back in the days when Theater View was developed. Would this be a solution? If not, is "Panel" destined to replace both JRemote and Theater View on a tablet?

[JimH]

Could you make a specific suggestion for a change or two?

[Grenache]

Could you make a specific suggestion for a change or two?

Only two? Well, then it has to be:

1)
Make finger scrolling in Theater View more responsive, precise and consistent. The current implementation lags, doesn't scroll very fast and sometimes requires tapping, sometimes "flicking" to select or expand elements.

2)
Make finger scrolling possible in Standard View without using the scrollbars and risking to move something around. I don't expect Standard View to be as good on a tablet as with a mouse, but would like it to be functionable.

[JimH]

Make finger scrolling in Theater View more responsive, precise and consistent. The current implementation lags, doesn't scroll very fast and sometimes requires tapping, sometimes "flicking" to select or expand elements.

This should be the same as what happens when you use a mouse. 

More details might help.

Try running a benchmark (under the Help menu) and pasting the results here.  It's possible you could improve it by reducing the framerate that Theater View uses.  Theater uses 3D drawing and it's expensive.

[Grenache]

Try running a benchmark (under the Help menu) and pasting the results here.  It's possible you could improve it by reducing the framerate that Theater View uses.  Theater uses 3D drawing and it's expensive.

Theater View isn't lagging like in being "choppy". It rather lags substantially behind my finger when I'm scrolling up and down. It's difficult to explain but it's a very different and less responsive touch experience compared to most other touch supported programs and especially modern apps. Like if you had a thick screen protector applied (which I don't).

Nevertheless, I'm more than ready to experiment. I run Theater View on three different tablets - this benchmark is from my Surface Pro 4:

=== Running Benchmarks (please do not interrupt) ===

Running 'Math' benchmark...
    Single-threaded integer math... 5,404 seconds
    Single-threaded floating point math... 3,737 seconds
    Multi-threaded integer math... 3,014 seconds
    Multi-threaded mixed math... 2,067 seconds
Score: 1336

Running 'Image' benchmark...
    Image creation / destruction... 0,683 seconds
    Flood filling... 0,321 seconds
    Direct copying... 0,481 seconds
    Small renders... 1,801 seconds
    Bilinear rendering... 1,653 seconds
    Bicubic rendering... 1,005 seconds
Score: 3701

Running 'Database' benchmark...
    Create database... 0,268 seconds
    Populate database... 1,580 seconds
    Save database... 0,451 seconds
    Reload database... 0,098 seconds
    Search database... 1,440 seconds
    Sort database... 1,377 seconds
    Group database... 0,810 seconds
Score: 3569

JRMark (version 21.0.90): 2869

[JimH]

Does it work smoothly with a mouse?  Any difference?

Try setting the frame rate down just to see what happens.  There is a drawing quality setting too.

That's a good machine, not great, in terms of performance.

[Grenache]

Does it work smoothly with a mouse?  Any difference?

I haven't tested it with a mouse and don't have one here. When using the trackpad Theater View scrolls much faster, actually too fast for the covers to completely redraw (which is expected and not a problem). Anyway, what I'm looking for is not a better visual scrolling (which is fine, even on my smaller and slower tablets), but a better touch - or tactile, if you want - experience.

Try setting the frame rate down just to see what happens.  There is a drawing quality setting too.

I've tried different settings from 10 to 90, but it doesn't seem to make a difference. If anything, the default at 60 might show the best. I haven't been able to find the "drawing quality setting".

That's a good machine, not great, in terms of performance.

I know. I guess without a fast, dedicated GPU you can't expect more from Theater View in its current state. That's why I proposed some sort of adaptation towards a better touch interface now that you're working on Mac and Linux versions anyway. I understand if that's not possible. Maybe "Panel" will some day turn out to be what I'm looking for.

[JimH]

Under settings for Theater View > Appearance, try wider scrollbars.

[Grenache]

Under settings for Theater View > Appearance, try wider scrollbars.

Already have it at "wide", and it's working fine and fast. For me, that is. Because you have to notice the scrollbar is there, and most persons used to touch-friendly interfaces just don't expect to use scrollbars. As said in my first post, I personally get along with Theater View on a tablet. The problem is rather missing WAF and F(riends)AF.

[blgentry]

Touch interfaces are their own thing.  They aren't the same as mouse and keyboard interfaces.  They are different than "10 foot view" interfaces.  I don't think adjusting existing non-touch interfaces will produce a good touch experience.

That's why JRemote is so widely accepted and lauded:  Because it's a native touch app on a touch device.

Perhaps something that was engineered from the ground up could be implemented such that it had very *similar* mouse, touch, and 10 foot interfaces.  Otherwise, what you seem to want is a different (in some way) touch interface, as compared to JRemote, EOS, and Gizmo.

What features or functionality are you wanting that you don't currently have with these other touch based interfaces?

Brian.

[mwillems]

Touch interfaces are their own thing.  They aren't the same as mouse and keyboard interfaces.  They are different than "10 foot view" interfaces.  I don't think adjusting existing non-touch interfaces will produce a good touch experience.

That's why JRemote is so widely accepted and lauded:  Because it's a native touch app on a touch device.

Perhaps something that was engineered from the ground up could be implemented such that it had very *similar* mouse, touch, and 10 foot interfaces.  Otherwise, what you seem to want is a different (in some way) touch interface, as compared to JRemote, EOS, and Gizmo.

What features or functionality are you wanting that you don't currently have with these other touch based interfaces?

Brian.

Brian, he's trying to use MC on a Microsoft Surface device which is an x86 tablet that runs full windows.  So gizmo, eos, and JRemote aren't options.  I'm in the same boat as I have a surface too, and MC isn't as touch friendly as I'd like either, but Theater view with the obsidian skin is close.  The lag he refers to is just that the interface seems to treat a touch swipe as though it were a turn of a mouse wheel, longer or faster swipes don't "accelerate" the touch motion particularly, and it takes a moment for the motion to start after you start the swipe.  This creates the impression of lag as your finger starts moving before the screen does, and your finger can sometimes keep moving after the interface has already stopped.  Generally, improving the "kinetic" qualities of the touch control would be a help.

Regardless, it's not perfect, but it's perfectly usable with the scrollbar on extra wide; theater view is currently the most functional interface for MC I've found on a windows tablet, but you're right that it doesn't work entirely like a native touch app.  Neither gizmo nor JRemote works (fully) in any of the Android emulators that I tried for Windows either, so that collateral option isn't an option.

Webgizmo/Panel has a few advantages over theater view for touch use, but has some serious flaws when used with a touchscreen at the moment with large collections (I've laid them out in detail in some prior posts, but could repost if anyone's interested).  The short version is that if webgizmo worked more like Gizmo, it would be perferctly good as a touch control on x86 systems. Theater view is a much better option at the moment. 

Tl;DR not all touch devices run android or ios. On linux-based touchscreens, unfortunately, webgizmo is what there is for the moment.  I'm excited for theater view to come to linux as it's very close to good enough for touch control.

[Grenache]

That's why JRemote is so widely accepted and lauded:  Because it's a native touch app on a touch device.

mwillems is right that I mainly use Windows, but I also have an Android tablet and agree that JRemote is very good, but it has some shortcomings and problems (just browse the Remotes forum), the biggest one being that JRiver has stopped developing it. So instead I'm using EOS, which I also like better.

What features or functionality are you wanting that you don't currently have with these other touch based interfaces?

Besides owning mainly Windows devices, Theater View is a far better option for my use because I like flexibility and have quite a heavy customization that can't be done in JRemote or EOS. So I rather use Theater View on my tablets and live with its - relatively speaking - lack of touch-friendliness. At least for now.

[Grenache]

The lag he refers to is just that the interface seems to treat a touch swipe as though it were a turn of a mouse wheel, longer or faster swipes don't "accelerate" the touch motion particularly, and it takes a moment for the motion to start after you start the swipe.  This creates the impression of lag as your finger starts moving before the screen does, and your finger can sometimes keep moving after the interface has already stopped.  Generally, improving the "kinetic" qualities of the touch control would be a help.

Thanks! That's exactly the experience I was trying to explain to Jim above, when I (due to lack of words as English isn't my native language) wrote "like having a thick screen protector applied".

[ferday]

Webgizmo/Panel has a few advantages over theater view for touch use, but has some serious flaws when used with a touchscreen at the moment with large collections (I've laid them out in detail in some prior posts, but could repost if anyone's interested). 

could you re-post or link the prior?  i'm interested.  I will be acquiring internet (finally) in a week and i have been planning on doing my best to integrate Panel in place of a few DLNA devices.  i haven't been able to play with Panel due to said lack of 'net

[mwillems]

could you re-post or link the prior?  i'm interested.  I will be acquiring internet (finally) in a week and i have been planning on doing my best to integrate Panel in place of a few DLNA devices. 

So just to provide a little context: I have raspberry pi's set up around the house controlling satelite audio systems.  I currently control via the library server using DLNA or JRemote or gizmo on my phone.  However, I wanted to create an option for local control of the pi's so that family members could just walk up and play music by touching a touchscreen next to the speakers.  The problem was that the pi's run GNU/linux (not android) so I couldn't use gizmo or jremote, and theater view is not available on Linux. 

So I tried to use them with webgizmo to control local playback, and it worked in a basic way, but I ran into a lot of limitations.  I've currently shelved the plan until theater view is available for Linux.  To be clear panel currently "sits on top of" a webgizmo backend for music and video playback, so all these observations still apply to my knowledge (I did some quick tests and they appear to still be valid).

But I think the devs are working on addressing a few of these issues with panel/webgizmo (specifically I think a fix for number 3 might be in the works); you should do your own testing, but here were the issues I found when I did my main testing over a period of months:

So on devices that can run android, there are lots of options.  And on windows there's theater view which works great on my Surface Tablet.  However, on vanilla Linux there's nothing but webgizmo, which has definite limitations on a touchscreen.  If you were looking for specifics, here are the biggest issues I hit using webgizmo as a touch interface daily on a raspberry pi for about six months:

1)  Unlike android gizmo, in webgizmo there is no load-on-demand infinite scrolling.  Album views are broken up into pages with 40 or 50 albums per page.  To switch pages you need to touch-press a fairly small hyperlinked number button at the bottom of the page.  Additionally, only four or five numbers are available for press at any one time (the rest are ellipsized, like 1, 2, 3 ... 45).  Android Gizmo and theater view both handle this through infinite scrolling, which would be nice for webgizmo.  Barring infinite scrolling (which would be ideal), larger, easy to press page buttons would be better, although if that's the solution, it would also be nice to have an alphabet (like in standard view).  As it is there's no good way to browse a large collection with webgizmo on a touch screen. To offer a concrete example, my music collection "album view" gets split across 50+ pages, and because the page numbers are ellipsized, getting to the "middle" of the collection is pretty hard.  It requires two dozen clicks and page loads to get to the "M's"! 

2) Unlike android, common desktop web browsers are not perfectly touch optimized. Many browsers (at least the the ones that run well on a raspberry) handle a touch screen by effectively treating it like a mouse.  This means "touch and grab" android style scrolling does not work, you have to use the browser scroll bars.  That makes scrolling even within the view pages challenging, as one has to grab the tiny browser scroll bar and drag it.  By contrast, Android Gizmo provides a nice large "grab bar" for assisted scrolling once you start scrolling.  An always-visible "grab bar" (like the one that appears on Android Gizmo, but always on) would be very nice to have in webgizmo. 

3) Unlike an android phone, the touchscreens I'm dealing with have no dedicated "back" button (many non-android tablets like the MS surfaces also lack such a button).  Webgizmo has no touch-friendly way to emulate this "back" function within the interface.  One can, of course, use the browser's "back" button, but in an appliance-type setting you don't want the browser chrome to be visible/accessible to a user (they could break things), you want the "app" to run fullscreen and be self-contained.  The lack of such a function within the interface makes navigation tough in full-screen.  Once you've gone down a level, your only option is to go all the way back to the top, which (combined with the above mentioned paged-view navigation) means that a single mispress can force you to start over on a chain of 10 or 15 clicks.  Gizmo for android relies on the fact that all android phones have a back button, but, a better example is theater view.  I use theater view on a windows tablet with no keyboard or back button and it works great because theater view always includes a way to move back up one level (through the rollers). I definitely don't think webgizmo needs rollers, but it would be nice if webgizmo had an onscreen way to either do what the browser "back" button does or just move up one level in the view hierarchy. Even just doing it the way Kodi does by making the first item in any view be "up one level" would do the trick.

4) This is a cosmetic issue, but it bothers me, so I thought I'd mention it.  The album cover thumbnails retrieved and displayed in android gizmo look nice and sharp, with no visible artifacts.  Often, the exact same album art in webgizmo appears to include artifacts or aliasing.  I'm not sure why that would be the case, but it's pretty easy to see if you look at the same album art in android gizmo and then in webgizmo on a browser on the same device. Art with large red or pink color fields seems to show it most prominently.

[...]

Gizmo and JRemote are both fantastic and hard to beat as dedicated media interfaces in the android setting though, they're very polished.  In the desktop space theater view is also excellent.  Any improvements to webgizmo to make it closer to those interfaces and/or more "touch friendly" would be greatly appreciated, although if/when theater view lands on linux it will solve most of these problems.  In any case, I hope this helps, and I appreciate the chance to offer input 

Most of the issues (1, 2, and 4) are essentially just making webgizmo work more like Gizmo; issue 3 is about accounting for a key difference in the hardware environment of a web app versus an android app.

[DJLegba]

You can repurpose an obsolete smartphone as your touch interface. Configure the phone to play through the relevant zone and leave it beside the speakers. Older phones typically lose their ability to hold a charge, but you can just leave it plugged in.

[syndromeofadown]

Could you make a specific suggestion for a change or two?

With my current setup I am using MC exclusively on touch screens and have some suggestions.
Do you want them here or on the original touch screen support thread:
http://yabb.jriver.com/interact/index.php?topic=96968.0

My wife is about to switch from using her laptop to our house's tablet and I am sure she will have some suggestions for me to pass on.