Any way to optimize sliders in a Crestron system. (more fluid response)

[yellowfin]

I am not sure there is a fix for this, but is seems that sliders with
a crestron system are pretty "laggy" and not very fluid. This has
always been an issue on Crestron touch panels, but with the advent of
the iPad/iPhone people seems to expect smoother swipes etc. Has
anyone figured out a way to do this?

Best

Jared

[Chap]

Hi,
Make sure you scale the values to the smallest number of steps you
can, less than 100 for sure. Less analog traffic.
chap

[Scott Shanafelt]

On a crestron panel/processor, it's still sort of slow because the processor and the nature of having to send a value and wait for it's feedback over a network are often inherently slow.

One possible solution is to use the analog input (the user input) of the slider as our feedback while it's being pressed, and the true feedback from the processor when the slider is released. It wouldn't be true feedback while being dragged, but you would still be transmitting those levels so it should be pretty close, eliminating the UI latency. Does anyone know if you can configure a slider in this way with CF?

Scott

> --
> You received this message because you are subscribed to the Google Groups "CommandFusion" group.
> To post to this group, send email to comman...@googlegroups.com.
> To unsubscribe from this group, send email to commandfusio...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/commandfusion?hl=en.
>

[Jarrod Bell]

This could be done by setting the slider to simulation mode, and only
sending the analog value back from the crestron processor on the slider
release, by using the digital join attached to the slider and detecting
the join going low.

Jarrod

[NDSNI]

How can you scale the feedback from CF to the Crestron processor, does
the analog join not always give out 0-65535 even if the max/min are
set on the slider?

Noel

On Jan 20, 2:44 am, Jarrod Bell <jar...@guilink.com> wrote:
> This could be done by setting thesliderto simulation mode, and only

> sending the analog value back from thecrestronprocessor on theslider

> release, by using the digital join attached to thesliderand detecting

> the join going low.
>
> Jarrod
>
> On 20/01/11 1:53 AM, Scott Shanafelt wrote:
>
>
>
>
>
>
>

> > On acrestronpanel/processor, it's still sort of slow because the processor and the nature of having to send a value and wait for it'sfeedbackover a network are often inherently slow.
>
> > One possible solution is to use the analog input (the user input) of theslideras ourfeedbackwhile it's being pressed, and the truefeedbackfrom the processor when theslideris released.  It wouldn't be truefeedbackwhile being dragged, but you would still be transmitting those levels so it should be pretty close, eliminating the UI latency.  Does anyone know if you can configure asliderin this way with CF?

>
> > Scott
>
> > On Jan 19, 2011, at 4:34 AM, yellowfin wrote:
>
> >> I am not sure there is a fix for this, but is seems that sliders with

> >> acrestronsystem are pretty "laggy" and not very fluid.  This has
> >> always been an issue onCrestrontouch panels, but with the advent of

[Jarrod Bell]

True, but the 'slowness' that people see is only the feedback side of
things.

Jarrod

[NDSNI]

Have you not found that using a slider to send the value into a
Crestron processor then through an analog scaler, out to a device
cause a lot of traffic in toolbox and the processor seems to try and
keep up with the slider. this also can cause disconnects. so far we
have only been using a gauge with Crestron projects.

[Jarrod Bell]

Sliders should not be used for volume, even with a Crestron touch panel
hard wired.
But for anything else, I haven't found there to be an issue.

What do you mean by 'a lot of traffic in toolbox'? You mean debugger?
Never judge a systems performance with debugger open.

The disconnects is generally if you are sending the reply directly back
with the analog value, which causes crestron to not be able to keep up
with heartbeat replies.
1. Set slider to simulation mode
2. Only send the actual analog value on slider digital join release.

Jarrod

[Heath Volmer]

Part of the problem in that scenario is toolbox itself. It causes the processor to choke faster because of the additional load caused by toolbox. I've had certain logic solutions choke when toolbox was open, probably poorly-designed ones.

But yes, a slider isn't the best tool for volume (unless you're Dr. Dre on an HP commerical I guess) I would offer mainly because of the potential to accidentally crank the volume with an errant press.

Heath

[Kafkaesque]

I have found that a slider can cause a log-jam of communication when
used with an iDOCV. Clients expect to be able to 'swipe' the slider
to scroll down the list of albums, but of course each page needs to be
loaded from the iDOC dynamically, which can mean a wait of 10-20
seconds for it to sort itself out. I've fixed this by using either an
analog sample to reduce the analog updates to 3 times a second, or
alternatively just using a gauge with 15-20 small transparent buttons
laid over it which feed into an analog init.

Brandon.


On Jan 20, 2:24 pm, Heath Volmer <hvol...@digitaldomainsystems.com>
wrote:

[Jarrod Bell]

Is it possible to request the full list of information from the iDOC
without waiting an hour for it?
That way you could retrieve the whole list and create a real dynamic
scrollable list in iViewer based on the list protocol as documented in
the Developers Manual PDF on our downloads page.

Jarrod

[Heath Volmer]

I think the only way to do it that wouldn't stall down the operation of things would be to call for a "page" of the list, with a certain pad of pages around it, in the background, building up the data in pieces. The goal being, by the time a user got to where they were scrolling to, the whole thing would be populated. Some process on the Crestron processor would have to be calling for and cataloging all this or referring it to iViewer.

Along those lines Jarrod, do you think that if the data was free-flowing from a Crestron processor (streaming out lists of artists/albums/etc and not waiting for an iDoc or other source) then could the list keep up as data was streaming in? Or, would the data need to be spewing out behind the scenes and caching on iViewer? I'm picturing a scrolling scenario where the list is flying by and no data is visible for a few seconds.

The reason I ask, is that it would be nice to have some common data source (Crestron processor) for the data, that could be shared between iViewer and maybe a traditional Crestron TP that (as of now) can't scroll the same. If iViewer can receive, cache and display data fast enough then the normal TP can do it's page by page thing and both feel normal.

Heath

[Jarrod Bell]

I don't think it will be feasible with the speeds from iDOC to Crestron
processor, parsing the data, formatting it for display in our protocol.
But if its all cached data, on the processor ready for sending, then
maybe it would work.

You can send data as needed from a list, when you scroll a list check
the data coming back to Crestron. There should be a list message
containing the current list size, number of items visible on the list
and the index of the first item currently visible. You could use this to
know when to send more data, until eventually the list would be full.

Jarrod

[Mqsack]

When running in "iPod Ondemand OFF" mode, the CEN-IDOCV loads the
iPod's library into internal memory so it can pass it along to the
crestron processor faster. Does anyone know if it is possible to
extract that information from and IDOCV and use it to build our list?
We could watch for the trailing edge of the "Loading Music Library"
signal from the dock as a trigger to re-populate the list. My gut is
they will say "NO", but I will put in a TBTS request today just in
case...

On Jan 21, 11:51 pm, Jarrod Bell <jar...@guilink.com> wrote:
> I don't think it will be feasible with the speeds fromiDOCto Crestron

> processor, parsing the data, formatting it for display in our protocol.
> But if its all cached data, on the processor ready for sending, then
> maybe it would work.
>
> You can send data as needed from a list, when you scroll a list check
> the data coming back to Crestron. There should be a list message
> containing the current list size, number of items visible on the list
> and the index of the first item currently visible. You could use this to
> know when to send more data, until eventually the list would be full.
>
> Jarrod
>
> On 22/01/11 1:40 AM, Heath Volmer wrote:
>
> > I think the only way to do it that wouldn't stall down the operation of things would be to call for a "page" of the list, with a certain pad of pages around it, in the background, building up the data in pieces.  The goal being, by the time a user got to where they were scrolling to, the whole thing would be populated.  Some process on the Crestron processor would have to be calling for and cataloging all this or referring it to iViewer.
>

> > Along those lines Jarrod, do you think that if the data was free-flowing from a Crestron processor (streaming out lists of artists/albums/etc and not waiting for aniDocor other source) then could the list keep up as data was streaming in?  Or, would the data need to be spewing out behind the scenes and caching on iViewer?  I'm picturing a scrolling scenario where the list is flying by and no data is visible for a few seconds.

>
> > The reason I ask, is that it would be nice to have some common data source (Crestron processor) for the data, that could be shared between iViewer and maybe a traditional Crestron TP that (as of now) can't scroll the same.  If iViewer can receive, cache and display data fast enough then the normal TP can do it's page by page thing and both feel normal.
>
> > Heath
>
> > On Jan 20, 2011, at 7:55 PM, Jarrod Bell wrote:
>

> >> Is it possible to request the full list of information from theiDOCwithout waiting an hour for it?

> >> That way you could retrieve the whole list and create a real dynamic scrollable list in iViewer based on the list protocol as documented in the Developers Manual PDF on our downloads page.
>
> >> Jarrod
>
> >> On 21/01/11 5:48 AM, Kafkaesque wrote:
> >>> I have found that a slider can cause a log-jam of communication when
> >>> used with an iDOCV.  Clients expect to be able to 'swipe' the slider
> >>> to scroll down the list of albums, but of course each page needs to be

> >>> loaded from theiDOCdynamically, which can mean a wait of 10-20