Overhead for Send_Level?

Comments

• Options

  ericmedley Posts: 4,177

  May 2009

  If you think about it, the other rooms not getting the feedback for, as you say, 6 seconds woujld not, in my opinion, be the end of the world. (sorry about all the sub clauses.)
  
  Yes, it's not truly real time. But probably in most cases the other rooms would not even be within hearing distance to think, "Hey! the volume in that room went dead and it took 5 seconds for the fader to update. What's up with that?"

  0
• Options

  kbeattyAMX Posts: 358

  May 2009

  John Gonzales wrote: »

  I have a project where I've got 32 room volumes being monitored on 20 touchpanels. The touchpanels are attached to different masters. I'm concerned that if I connect the room volume levels to bargraphs on all of the touchpanels I'll bog down the system big time during a group level change. For instance If I zero out the volume in all rooms under an 'all off' situation, then all 32 levels will be updated pretty quickly which will try to update 640 levels across the network (32 levels x 20 panels).
  
  I can space the send_level commands to do group volume changes, but if I even do 5 per second it will still take over 6 seconds to effect all rooms.
  
  Does anyone have a recommendation for how fast I can update that many levels? Is a Send_level a lot less overhead than I'm thinking? Should I just go ahead and shoot them all at one time like Send_Level dvDevice,1,0 where dvDevice is an array?
  
  Thanks, my head is spinning -- maybe it's that Influenze TypeA (H1N1) virus....
  
  
  
  -- John

  
  Have you thought about sending the level to a virtualDevice on the local system then just do a define_connect_level to the virtualDevices from the remote systems. In this way, you wouldn't need to do send level to the 20 different panels.

  0
• Options

  ericmedley Posts: 4,177

  May 2009

  kbeattyAMX wrote: »

  Have you thought about sending the level to a virtualDevice on the local system then just do a define_connect_level to the virtualDevices from the remote systems. In this way, you wouldn't need to do send level to the 20 different panels.

  
  
  I think that would still result in the same amount of network traffic as the messages still need to get sent to all the panels. It would certainly make the programming end of it simpler.

  0
• Options

  kbeattyAMX Posts: 358

  May 2009

  ericmedley wrote: »

  I think that would still result in the same amount of network traffic as the messages still need to get sent to all the panels. It would certainly make the programming end of it simpler.

  
  I think network traffic may have been an issue with 10baseT. That was in a world where we could only dream of VOIP. But today with modern routers, switches and Giga speed Ethernet, I believe AMX contributes very little to network traffic when you compare it to watching a video clip off of YouTube and realtime Skype video calls.

  0
• Options

  jweather Posts: 320

  May 2009

  Make sure you're not updating the levels unless they can actually be seen on the panel.

  0
• Options

  ericmedley Posts: 4,177

  May 2009

  jweather wrote: »

  Make sure you're not updating the levels unless they can actually be seen on the panel.

  
  
  That's what I do

  0
• Options

  John Gonzales Posts: 609

  May 2009

  Thanks guys. Sorry if I didn't explain it better in my first post, but I was considering connecting the NXC-Vol4 levels to the bargraph levels on the touchpanels using define_connect_level as was mentioned by Ken to reduce the amount of programming (as was mentioned by Eric). If I do that, and I do a send_level to all of the volume controls to go to 0, that should cause the connected bargraph levels to update automatically.
  
  If I create a devlev array and do a send_level dvlvVolumeControlArray, 1, 0 where dvlvVolumeControlArray is an array of 32 levels on the volume controls (or virtual devices), all of those levels would try to update all of those touchpanels at once. Is that likely to bog down the system? I was considering shooting the send_levels to the volume controls in a spaced fashion so that it didn't flood the system with level updates to 640 levels (32 levels x 20 panels).
  
  Or would I be better off going the other route which would be to send feedback to the panels that are actually displaying the levels? The second is more programming work. If the first one won't bog down the system, I think that would be easier, and I'm all for easier.
  
  --John

  0
• Options

  kbeattyAMX Posts: 358

  May 2009

  Try the simpler one first. That one of the reasons AMX gave us devArrays. So we can send command to all of them at once. Now I don't think the Ethernet would get bogged down but possible internal cues may have to work a little.

  0
• Options

  John Gonzales Posts: 609

  May 2009

  Try the simpler one first.

  Instead of trying the simpler way first, I cranked up the complexity on the TP design and am using a slightly different approach.
  
  Sending too many send_strings or send_commands to panels can have an adverse effect on system speed, and that's what I'm trying to avoid here. Now my TP pages show several different room volumes at one time, and each panel can be on a different set of rooms. I've got the tracking set up so that I know which panels are looking at which rooms and what VT buttons are displayed on each panel. Updating the Room names and Source Playing buttons is pretty simple, since those don't change often once they're displayed, but in order to update the volume levels, I need to make sure I don't flood the panels when someone holds the volume up or down buttons.
  
  Here are the questions:
  
  1) Is a send_level dvTP,x,xx command just as apt to slow down the system as send_command, dvTP,"'^TXT-101,',ITOA(_RoomInfo[nPanelIndex].nRoomVolume)"?
  
  2) Is combining the level on the TP with the Volume Control less apt to slow down the system compared to having to use a send_level dvTP,x,xx command?
  
  3) If I have to dynamically combine the levels to the levels being displayed, I recall that it's supposed to be done on a release: event which is how I've done it in the past. In this case I'd prefer to do it on the push event instead, will it work? And if not, I've always wondered why it can't be done on the push: event.
  
  In the TP Image below, this is a popup page and the volumes are multi-state bargraphs with level codes 1-4.
  
  Thanks,
  
  John
  
  -

  RoomVolDisplay.jpg 53.4K

  0
• Options

  vining Posts: 4,368

  May 2009

  1) Is a send_level dvTP,x,xx command just as apt to slow down the system as send_command, dvTP,"'^TXT-101,',ITOA(_RoomInfo[nPanelIndex].nRoomVolume)"?

  1st levels are tracked by the master so even if the send_level commands run in a loop or define_program it will only get sent when the level value changes. Sending text isn't tracked and will be sent again & again & again. Besides that I think there is more work invlovled for the master to send text and the TP to process and display text than there is to process levels.
  

  2) Is combining the level on the TP with the Volume Control less apt to slow down the system compared to having to use a send_level dvTP,x,xx command?

  I don't know if it makes enough difference to worry about but having the master handle the process is probably more efficient but I don't think I'd want to lose the control of putting the send_level where I want it and use it when I wanted.
  

  3) If I have to dynamically combine the levels to the levels being displayed, I recall that it's supposed to be done on a release: event which is how I've done it in the past. In this case I'd prefer to do it on the push event instead, will it work? And if not, I've always wondered why it can't be done on the push: event.

  My brains a little foggy now but I cna't think of any reason to do it on the release unless there's a hold event that would change the outcome.

  0