¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io
  1. Crestron
  2. Topics

Slider Crosspoint Issue

Jason Andersen
 

I attempted this several times and I still can't come up with a viable solution. I am going to do my best to explain this and if anyone wants to help it would be appreciated.

I want to use a slider for volume and I use crosspoints for the interfaces and room modules, like I'm suppose too.

When I use the slider on interface A it sends the volume to the room A module correctly but that slider value is held in memory.

When I change to room B, interface A still holds the slider value and changes the volume of Room B to whatever the slider was left at.

My brain hurts.
 

I just fixed this issue today. Here is what I did.

Analog equate driven off econnect room id that triggers an abuf for each
room that sets tp's analog fb to vol out of that room.

I have 3 sets of xpoints
TP -> Room -> Device

Hope that helps
Nick




Sent from my eMail.

On May 1, 2013, at 7:17 PM, Jason Andersen <jandersen@...> wrote:



I attempted this several times and I still can't come up with a viable
solution. I am going to do my best to explain this and if anyone wants to
help it would be appreciated.

I want to use a slider for volume and I use crosspoints for the interfaces
and room modules, like I'm suppose too.

When I use the slider on interface A it sends the volume to the room A
module correctly but that slider value is held in memory.

When I change to room B, interface A still holds the slider value and
changes the volume of Room B to whatever the slider was left at.

My brain hurts.




[Non-text portions of this message have been removed]
 

Or you can use an abuf driven by the digital press join of the slider.

--- In Crestron@..., Nick Mitchell <nick@...> wrote:

I just fixed this issue today. Here is what I did.

Analog equate driven off econnect room id that triggers an abuf for each
room that sets tp's analog fb to vol out of that room.

I have 3 sets of xpoints
TP -> Room -> Device

Hope that helps
Nick




Sent from my eMail.

On May 1, 2013, at 7:17 PM, Jason Andersen <jandersen@...> wrote:



I attempted this several times and I still can't come up with a viable
solution. I am going to do my best to explain this and if anyone wants to
help it would be appreciated.

I want to use a slider for volume and I use crosspoints for the interfaces
and room modules, like I'm suppose too.

When I use the slider on interface A it sends the volume to the room A
module correctly but that slider value is held in memory.

When I change to room B, interface A still holds the slider value and
changes the volume of Room B to whatever the slider was left at.

My brain hurts.
Jason Andersen
 

So my problem with the abuf solution is related to the output side of the abuf, it holds it value. So when that interface connects to another audio zone, the output of that abuf sets the volume for the next room it connected to through the crosspoints.

--- In Crestron@..., "jac777888" <jchelton@...> wrote:

Or you can use an abuf driven by the digital press join of the slider.

--- In Crestron@..., Nick Mitchell <nick@> wrote:

I just fixed this issue today. Here is what I did.

Analog equate driven off econnect room id that triggers an abuf for each
room that sets tp's analog fb to vol out of that room.

I have 3 sets of xpoints
TP -> Room -> Device

Hope that helps
Nick




Sent from my eMail.

On May 1, 2013, at 7:17 PM, Jason Andersen <jandersen@> wrote:



I attempted this several times and I still can't come up with a viable
solution. I am going to do my best to explain this and if anyone wants to
help it would be appreciated.

I want to use a slider for volume and I use crosspoints for the interfaces
and room modules, like I'm suppose too.

When I use the slider on interface A it sends the volume to the room A
module correctly but that slider value is held in memory.

When I change to room B, interface A still holds the slider value and
changes the volume of Room B to whatever the slider was left at.

My brain hurts.




[Non-text portions of this message have been removed]
Heath Volmer
 

Are you saying that when you switch crosspoints, that the "previous" room's volume feedback sets the volume in the "new" room?

Maybe if you pass the press associated with the slider through the crosspoint to an ABUF in the zone's logic, then the interface's logic won't force through that value unless it's being pressed. Let the zone or audio device decide when its volume should be changing, (when it's being pressed) and the interface provide presses and feedback only.

I like to send the user interactions as far down the chain as makes sense, as to keep things as abstract as possible. Do the operations as close as possible to the things being operated on, and let the interface merely reflect what the device is doing.

Heath

On May 2, 2013, at 11:25 AM, Jason Andersen <jandersen@...> wrote:

So my problem with the abuf solution is related to the output side of the abuf, it holds it value. So when that interface connects to another audio zone, the output of that abuf sets the volume for the next room it connected to through the crosspoints.

--- In Crestron@..., "jac777888" <jchelton@...> wrote:

Or you can use an abuf driven by the digital press join of the slider.

--- In Crestron@..., Nick Mitchell <nick@> wrote:

I just fixed this issue today. Here is what I did.

Analog equate driven off econnect room id that triggers an abuf for each
room that sets tp's analog fb to vol out of that room.

I have 3 sets of xpoints
TP -> Room -> Device

Hope that helps
Nick




Sent from my eMail.

On May 1, 2013, at 7:17 PM, Jason Andersen <jandersen@> wrote:



I attempted this several times and I still can't come up with a viable
solution. I am going to do my best to explain this and if anyone wants to
help it would be appreciated.

I want to use a slider for volume and I use crosspoints for the interfaces
and room modules, like I'm suppose too.

When I use the slider on interface A it sends the volume to the room A
module correctly but that slider value is held in memory.

When I change to room B, interface A still holds the slider value and
changes the volume of Room B to whatever the slider was left at.

My brain hurts.




[Non-text portions of this message have been removed]


[Non-text portions of this message have been removed]
Jason Andersen
 

When I switch crosspoints the slider input value which ends up sitting on the output side of the abuf gets sent to the set volume input of my room module.

Thanks Heath. That is actually an idea I came up with last night and when I compiled I forgot to save the changes to the room module. I'm going to finish it now.

--- In Crestron@..., Heath Volmer <hvolmer@...> wrote:

Are you saying that when you switch crosspoints, that the "previous" room's volume feedback sets the volume in the "new" room?

Maybe if you pass the press associated with the slider through the crosspoint to an ABUF in the zone's logic, then the interface's logic won't force through that value unless it's being pressed. Let the zone or audio device decide when its volume should be changing, (when it's being pressed) and the interface provide presses and feedback only.

I like to send the user interactions as far down the chain as makes sense, as to keep things as abstract as possible. Do the operations as close as possible to the things being operated on, and let the interface merely reflect what the device is doing.

Heath

On May 2, 2013, at 11:25 AM, Jason Andersen <jandersen@...> wrote:

So my problem with the abuf solution is related to the output side of the abuf, it holds it value. So when that interface connects to another audio zone, the output of that abuf sets the volume for the next room it connected to through the crosspoints.

--- In Crestron@..., "jac777888" <jchelton@> wrote:

Or you can use an abuf driven by the digital press join of the slider.

--- In Crestron@..., Nick Mitchell <nick@> wrote:

I just fixed this issue today. Here is what I did.

Analog equate driven off econnect room id that triggers an abuf for each
room that sets tp's analog fb to vol out of that room.

I have 3 sets of xpoints
TP -> Room -> Device

Hope that helps
Nick




Sent from my eMail.

On May 1, 2013, at 7:17 PM, Jason Andersen <jandersen@> wrote:



I attempted this several times and I still can't come up with a viable
solution. I am going to do my best to explain this and if anyone wants to
help it would be appreciated.

I want to use a slider for volume and I use crosspoints for the interfaces
and room modules, like I'm suppose too.

When I use the slider on interface A it sends the volume to the room A
module correctly but that slider value is held in memory.

When I change to room B, interface A still holds the slider value and
changes the volume of Room B to whatever the slider was left at.

My brain hurts.







[Non-text portions of this message have been removed]
 

Hi Jason,

My solution to this (it's buried deep inside our framework, but it's used in lots of places) is to pass each analog value (from the user interaction side) into an AOS, with say a 1 second pulse width. The output of each AOS then goes into a digital on the x-point.

On the x-point destination ("equipment"), the digital enables an analog buffer for each "managed" signal.

Since AOS's are retriggerable, any *changing* analog value will propagate, but switching x-points doesn't propagate a new value (unless you happen to switch the x-point while the AOS is still high.)

The AOS/buffer stuff is all encapsulated within the x-point framework wrappers, so you don't even notice it's there. We use the technique for anything that has a slider/analog control - lights, treble/bass/balance, heating dials, etc.

Hope that helps,
Ol

--- In Crestron@..., "Jason Andersen" <jandersen@...> wrote:

When I switch crosspoints the slider input value which ends up sitting on the output side of the abuf gets sent to the set volume input of my room module.

Thanks Heath. That is actually an idea I came up with last night and when I compiled I forgot to save the changes to the room module. I'm going to finish it now.
Jason Andersen
 

Thank you for all the help everyone. These last two examples really helped by moving the abuf or aos, whatever is needed from the interface side to the room side of the x-point. Previously I had it in the interface side and sent the out of the abuf to the x-point which is where my problem was. It works great now. Really solved my problem. I am still mastering x-points.

--- In Crestron@..., "olly_penguin" <oliver.hall@...> wrote:

Hi Jason,

My solution to this (it's buried deep inside our framework, but it's used in lots of places) is to pass each analog value (from the user interaction side) into an AOS, with say a 1 second pulse width. The output of each AOS then goes into a digital on the x-point.

On the x-point destination ("equipment"), the digital enables an analog buffer for each "managed" signal.

Since AOS's are retriggerable, any *changing* analog value will propagate, but switching x-points doesn't propagate a new value (unless you happen to switch the x-point while the AOS is still high.)

The AOS/buffer stuff is all encapsulated within the x-point framework wrappers, so you don't even notice it's there. We use the technique for anything that has a slider/analog control - lights, treble/bass/balance, heating dials, etc.

Hope that helps,
Ol

--- In Crestron@..., "Jason Andersen" <jandersen@> wrote:

When I switch crosspoints the slider input value which ends up sitting on the output side of the abuf gets sent to the set volume input of my room module.

Thanks Heath. That is actually an idea I came up with last night and when I compiled I forgot to save the changes to the room module. I'm going to finish it now.
 

Agreed, this conversation was great, have been mulling how to do this for a lighting module the last few evenings and this really helped to eliminate a lot of over-complicated options.

--- In Crestron@..., "Jason Andersen" <jandersen@...> wrote:

Thank you for all the help everyone. These last two examples really helped by moving the abuf or aos, whatever is needed from the interface side to the room side of the x-point. Previously I had it in the interface side and sent the out of the abuf to the x-point which is where my problem was. It works great now. Really solved my problem. I am still mastering x-points.

--- In Crestron@..., "olly_penguin" <oliver.hall@> wrote:

Hi Jason,

My solution to this (it's buried deep inside our framework, but it's used in lots of places) is to pass each analog value (from the user interaction side) into an AOS, with say a 1 second pulse width. The output of each AOS then goes into a digital on the x-point.

On the x-point destination ("equipment"), the digital enables an analog buffer for each "managed" signal.

Since AOS's are retriggerable, any *changing* analog value will propagate, but switching x-points doesn't propagate a new value (unless you happen to switch the x-point while the AOS is still high.)

The AOS/buffer stuff is all encapsulated within the x-point framework wrappers, so you don't even notice it's there. We use the technique for anything that has a slider/analog control - lights, treble/bass/balance, heating dials, etc.

Hope that helps,
Ol

--- In Crestron@..., "Jason Andersen" <jandersen@> wrote:

When I switch crosspoints the slider input value which ends up sitting on the output side of the abuf gets sent to the set volume input of my room module.

Thanks Heath. That is actually an idea I came up with last night and when I compiled I forgot to save the changes to the room module. I'm going to finish it now.
 

This is a basic concept to be aware of when using crosspoints (and
sometimes EISCs) in the upon connection to an ECROSS, a CCROSS propegates
all of it's values from the input side to the output side of the ECROSS and
vice versa. Any values, such as a value from a slider) that you want to
maintain on the ECROSS side need to be gated. Using the press join from a
slider to enable an abuf is a good example of this. It also helps if you
allow the slider fb value from the ECROSS input side to propegate to the
slider on the interface unhindered. This way, when the CCROSS disconnects
from one ECROSS and connects to another, the new value for the slider will
be updated and upon next press, the user modified value will propegate to
the device being controlled (audio volume, lighting level, etc.)




On Thu, May 2, 2013 at 5:35 PM, weddellkw <weddellkw@...> wrote:

**


Agreed, this conversation was great, have been mulling how to do this for
a lighting module the last few evenings and this really helped to eliminate
a lot of over-complicated options.


--- In Crestron@..., "Jason Andersen" <jandersen@...> wrote:

Thank you for all the help everyone. These last two examples really
helped by moving the abuf or aos, whatever is needed from the interface
side to the room side of the x-point. Previously I had it in the interface
side and sent the out of the abuf to the x-point which is where my problem
was. It works great now. Really solved my problem. I am still mastering
x-points.

--- In Crestron@..., "olly_penguin" <oliver.hall@> wrote:

Hi Jason,

My solution to this (it's buried deep inside our framework, but it's
used in lots of places) is to pass each analog value (from the user
interaction side) into an AOS, with say a 1 second pulse width. The output
of each AOS then goes into a digital on the x-point.

On the x-point destination ("equipment"), the digital enables an
analog buffer for each "managed" signal.

Since AOS's are retriggerable, any *changing* analog value will
propagate, but switching x-points doesn't propagate a new value (unless you
happen to switch the x-point while the AOS is still high.)

The AOS/buffer stuff is all encapsulated within the x-point framework
wrappers, so you don't even notice it's there. We use the technique for
anything that has a slider/analog control - lights, treble/bass/balance,
heating dials, etc.

Hope that helps,
Ol

--- In Crestron@..., "Jason Andersen" <jandersen@> wrote:

When I switch crosspoints the slider input value which ends up
sitting on the output side of the abuf gets sent to the set volume input of
my room module.

Thanks Heath. That is actually an idea I came up with last night and
when I compiled I forgot to save the changes to the room module. I'm going
to finish it now.




[Non-text portions of this message have been removed]
[email protected]
 

Hi Neil,

Your explanation is good and probably the best way. ?

One way I'm experimenting with, that seems to work so far, is on the TP and Control Cross symbols use the same name for both sides of the symbols. ?So TP_1_Volume is on the analog out and feedback on both TP and Control Cros.

On the Equipment Cross side you'd use Zone_1_Volume on the in (right) side and Zone_1_Volume_F on the out (left side).

I *think* what happens is when the cross point connection is made, the Zone_1_Volume_F signal gets passed to the control crosspoint and updates the touch and fb together.?

Anyone else tried this??

In the end probably better to just use digital ups and downs with AINCF to avoid accidental jumps etc. I suppose.
 

You need to very careful with analog signals on crosspoint symbols because it's VERY easy to create a logic loop that will bring your program to it's knees.

You should NEVER have a crosspoint symbol with the same signal on the same in_x and out_x line.? Doing so creates a loop so that any value that propagates from the out_x line automatically gets fed back into the in_x line.

This will typically trigger a logic wave error (either 1000 or 1500 waves for 2/3 series) and crash your program.? Check your processor's error log for these errors.

What you need to do to solve your problem is to use an analog buffer to "Gate" the fb value of the slider so that it propagates after the cross point connection is made and the slider then updates it's value from whatever room/device it is now controlling.

On Mon, Mar 2, 2015 at 4:00 PM, charlie@... [Crestron] <Crestron@...> wrote:
?

Hi Neil,


Your explanation is good and probably the best way. ?

One way I'm experimenting with, that seems to work so far, is on the TP and Control Cross symbols use the same name for both sides of the symbols.? So TP_1_Volume is on the analog out and feedback on both TP and Control Cros.

On the Equipment Cross side you'd use Zone_1_Volume on the in (right) side and Zone_1_Volume_F on the out (left side).

I *think* what happens is when the cross point connection is made, the Zone_1_Volume_F signal gets passed to the control crosspoint and updates the touch and fb together.?

Anyone else tried this??

In the end probably better to just use digital ups and downs with AINCF to avoid accidental jumps etc. I suppose.
 

My typical way of handling these is to have the slider analog out's from the touchpanel running into an XSIG, which outputs the data as serial when ever it changes (whenever the slider is operated).? The serial then goes through the crosspoint, and since it's serial data it doesn't get re-transmitted when the crosspoint is changed (so don't put a Make String Perminant on it).? The the equipment side of the crosspoint has another XSIG which operates in the reverse direction, taking the serial and converting it back to analogs.? The bar feedback just goes analog through the crosspoint like it normally would.

This has the advantage of being one sigal/two symbol solution for multiple analogs, cleanly separating the UI logic and the device control logic, and having very little to change on the device side.

There will probably be a dedicated group of analogs setup this way in the next UI crosspoint modules I make.
Mike Jobson
 

Easiest way is probably to take the digital touch feedback from a slider and pass that to the equipment side of the crosspoint where it would activate an analogue buffer. This should pass the feedback back on the crosspoint connect to make sure the UI shows the current level for that room / area.

Mike Jobson
Director
?

Control Designs Software Ltd
AV Software Solutions

?
Email: ?mike@...
DDI: ?+44 (0) 1753 668931
Mobile: ?+44 (0) 7875 020894
Skype

Control Designs Software Ltd??| ?Company?Registration No. 07507642
Registered?Office: 16 Grassingham End, Chalfont St Peter, Gerrards Cross, Buckinghamshire SL9 0BP


On 4 March 2015 at 01:14, astingen@... [Crestron] <Crestron@...> wrote:
?

My typical way of handling these is to have the slider analog out's from the touchpanel running into an XSIG, which outputs the data as serial when ever it changes (whenever the slider is operated).? The serial then goes through the crosspoint, and since it's serial data it doesn't get re-transmitted when the crosspoint is changed (so don't put a Make String Perminant on it).? The the equipment side of the crosspoint has another XSIG which operates in the reverse direction, taking the serial and converting it back to analogs.? The bar feedback just goes analog through the crosspoint like it normally would.

This has the advantage of being one sigal/two symbol solution for multiple analogs, cleanly separating the UI logic and the device control logic, and having very little to change on the device side.

There will probably be a dedicated group of analogs setup this way in the next UI crosspoint modules I make.
[email protected]
 


Using this method, when the digital slider join goes high, through the ECROSS to the analog buffer, the value on the output of the ABUF gets passed briefly before the current value passes. ?Using volume as an example: I'm connected to room A and the volume is at 50%. ?I switch to room B and the volume is at 25%. ?The fb signal connects unhindered and updates correctly, but when I touch the slider, the volume briefly jumps to the value of room A before updating to the correct value. ?I must be missing something, the ABUF is on the equipment side off the ECROSS...Should I be using a serial buffer instead?
 

Thanks for sharing this method.? This is a very nice and clean way to do it.? I had used various methods to make this happen but this is by far the cleanest way using the fewest symbols, I really like that I can put all the analogs that I need to make sure don't propagate their values from the interface to the equipment on each new cross-point connect.? I had use the AOS method prior but it was signal by signal which can turn into a lot of extra symbols to manage.

1 - 16 of 16