Home AMX User Forum AMX Control Products

Volume Level Control Best Practices

I am a new programmer who just recently attended Programmer 2. I am currently on my first large residential system. There is a Tango 16 zone setup and a media room with a 232 controlled Marantz receiver. I have tried 3 or 4 different methods seeking consistent, predictable volume level control on the touch panels. I am curious what some of the more experienced programmers suggest as a best practice for volume level control and feedback on a touch panel.

Thanks in advance for any and all advice.
«1

Comments

  • DHawthorneDHawthorne Posts: 4,584
    I don't know that there really is a "best practice," so much as "preferred practice."

    My preference is to use volume up and down buttons, and have a bargraph display for feedback only. I generally use the hardware buttons on a panel for this and a very simple hold with repeat on the button event. The feedback level gets updated as the receiver sends it.
  • ColzieColzie Posts: 470
    I only send volume up/down commands (versus incrementing the value in code and sending absolute values to the hardware) and display the level on the TP based on the feedback from the device. Both Tango and Marantz work well this way. This way no matter what the current volume of the hardware (perhaps it was very high but someone turned the knob on the front panel) the up/down will not jump to some other value.

    For the repeat portion, I've gotten in the habit of giving each TP its own timeline to use as needed for "press and hold" operations. This is because button.input.channel does not always work as expected in the HOLD event when you have arrays of TPs and buttons. Also, it is easy to limit the number of repeats to prevent runaway volume in case the RELEASE is not seen by the processor.

    For Mute I give the user a toggle button. In code I track the mute state and send the proper discrete command. My mute button flashes red when mute is on.
  • kbeattyAMXkbeattyAMX Posts: 358
    If you have to tell a device what discreet volume to go to and you don't care about feedback. Just have the Volume UP and DOWN control the level on the TP (all internal to the Modero) and program a level event to control the device.

    level_event[TP,1]
    {
    send_string device,"'vol',itoa(level.value)"
    }

    You could event set the range in the TP.
  • kbeattyAMX wrote: »
    If you have to tell a device what discreet volume to go to and you don't care about feedback. Just have the Volume UP and DOWN control the level on the TP (all internal to the Modero) and program a level event to control the device.

    level_event[TP,1]
    {
    send_string device,"'vol',itoa(level.value)"
    }

    You could event set the range in the TP.

    Should have prefaced that with a "Don't Try This At Home...".

    There are a lot of devices that even though have direct volume setting commands don't like receiving more than one or two per second. Try it in the shop before you send it out in the field.
  • ericmedleyericmedley Posts: 4,177
    I typically use volume up and down buttons. There is the probability of data feedback issues if you use the same fader for displaying and changing the volume levels. Aother thig I will do if the device is pretty fast on the draw is put a 'send level' fader over the 'display fader'. This breaks the loop and the user really doesn't notice the difference. It does double the amount of faders you use. But most times, it's not big deal.
  • viningvining Posts: 4,368
    I use up & down buttons for volume control, buttons and sliders for lights.

    I never use sliders for vol control cuz it's so easy to acidentially touch the top of the bargraph and blast the speakers. Some folks use the slide drag feature to avoid this but I've never tried it.

    Any bargraph I make that is both control and display is actually made up of 2 bargraphs. An invisible bargraph on top for control of the 2nd bargraph beneath (visible) for display on different level channels. I guess this is the same thing Eric just said.

    If I recall I send absolute values on auto patch switchers since it echos the command I sent which I use to acknowledge receipt and parse for feedback. That way I don't need to query.

    You can also put DO_RELEASE in your volume buttons hold event handler to break the hold after a certain wait time or button.holdtime. That's a trick that someone else here on the forum uses which is a good way to prevent run away ramping from a stuck buttons or some kid sitting on or placing something on the panel or remote.
  • kbeattyAMXkbeattyAMX Posts: 358
    icraigie wrote: »
    Should have prefaced that with a "Don't Try This At Home...".

    There are a lot of devices that even though have direct volume setting commands don't like receiving more than one or two per second. Try it in the shop before you send it out in the field.

    It depends on how fast the ramp is on the TP. What do you mean try it before you send it out? It works perfectly with Vortex and Clearone's. If you set the range on the TP to 100 and it takes 10 seconds to ramp then you are sending out 10 commands per second. And you can set the range to 50 and half the commands to 5 per second. It works with volumes for Sharps and Extrons.

    If the device only takes 1 to 2 commands per second, it not worth ramping this way.
  • dthorsondthorson Posts: 103
    kbeattyAMX wrote: »
    If you have to tell a device what discreet volume to go to and you don't care about feedback. Just have the Volume UP and DOWN control the level on the TP (all internal to the Modero) and program a level event to control the device.

    level_event[TP,1]
    {
    send_string device,"'vol',itoa(level.value)"
    }

    You could event set the range in the TP.

    I like this method also. Just have to be sure you LEVEL_EVENT is coming from a Virtual Device, because an offline event will set the level to zero and could cause your program to change the volume level unintentionally.
  • a_riot42a_riot42 Posts: 1,624
    dthorson wrote: »
    I like this method also. Just have to be sure you LEVEL_EVENT is coming from a Virtual Device, because an offline event will set the level to zero and could cause your program to change the volume level unintentionally.


    If the panel is offline, how would it change the volume of a device unintentionally?
    Paul
  • yuriyuri Posts: 861
    a_riot42 wrote: »
    If the panel is offline, how would it change the volume of a device unintentionally?
    Paul

    It's not a problem if the panel is offline, it becomes a problem when the panel goes offline.
    It then sends all levels to 0, which sucks...
  • kbeattyAMXkbeattyAMX Posts: 358
    dthorson wrote: »
    I like this method also. Just have to be sure you LEVEL_EVENT is coming from a Virtual Device, because an offline event will set the level to zero and could cause your program to change the volume level unintentionally.

    I just mentioned this as a viable option to control volume because AMX gave the ability to ramp levels within a Modero TP. The Range and Range Time can be adjust. The Value and Repeat can be adjusted and all you would need to do in the code is write a level event. As mentioned the level event should be from a VirtPanel that is combined with the Real Panel Thanks Paul!

    If the device has a problem of receiving commands to fast, just modify the ramp in the TP.
  • a_riot42a_riot42 Posts: 1,624
    yuri wrote: »
    It's not a problem if the panel is offline, it becomes a problem when the panel goes offline.
    It then sends all levels to 0, which sucks...

    I still don't understand. If the panel goes offline, how can it send any levels to the controller. Maybe I am missing something obvious.
    Paul
  • PhreaKPhreaK Posts: 966
    a_riot42 wrote: »
    I still don't understand. If the panel goes offline, how can it send any levels to the controller. Maybe I am missing something obvious.
    Paul

    When a panel goes offline it drops the value of all it's levels which triggers a level event with data.level = 0.
  • a_riot42a_riot42 Posts: 1,624
    PhreaK wrote: »
    When a panel goes offline it drops the value of all it's levels which triggers a level event with data.level = 0.

    I know the level bargraph on the TP will go to 0 but I have never seen it actually affect a device. Learn something new every year!
    Paul
  • viningvining Posts: 4,368
    I beleive it's a problem when the TP comes back online after going offline or even after a program upload to the master. When the panel comes online after either of either these events it will send its bargraph levels which now will be 0. That's why you combine it to a virtual device since they never go offline or do what yuri does and posted earlier, tie the send_level to a bargraph button push.
  • Level (non-) Events

    When the TP goes offline (either through an upload to the TP or thru unplugging it) the Master sees it as all Levels on the Panel going to 0. If you are uploading to the master it seems to be ok.

    If you have 2 or more TPs linked with the same levels on each this can be a massive problem, as any change (due to the Offline Event) will not reflect on the panels (unless they are combined...but more on that later), and you don't realise until you either have lots of noise coming out of a speaker, or none. I had this problem with a DSP controlled via two NXD500i's and a NXD700Vi - it wasn't too bad when the levels for the DSPs internal Matrix Mixer went to 0, as this was 0dB on any input so not too noticable if set up correctly in any previous gain control...the problem came with the Master Volumes, as 0 was, well, Zero!

    Virtual Levels/Devices are fine BUT if your levels have negative numbers this will not work.

    As a workaround (after 2 days of hair pulling and some input from Trav at AMX AU...I say some input, it was his idea!) I stuck a flag in the online and offline events and then put an IF statement in the Level event based on the flags. This works fine, though is a little long winded. With more time I could simplify it.

    If I get a chance I'll put up the code this w/end.



    There are 10 kinds of people in the world....those who understand Binary, those who understand Hex, and the rest are probably installers :-)
  • AuserAuser Posts: 506
    trustworthy's explanation is correct.

    In general, try to use a consistent (non-negative) feedback range for touch panel levels where possible (eg. 0 - 100 or 0 - 255). It is then possible to avoid any issue with volume feedback when panels go offline by including TP devices in dev arrays with a virtual device and referencing the dev array when invoking or handling level events. Even though individual TP's may go offline the virtual device is always online and thus the master doesn't "lose track" of the the level and set it back to 0 when a panel goes offline.

    Benefits
    - There's no requirement to edit volume feedback bargraphs on your touch panel layout from job to job
    - It's easier to drop in a different volume control device.
    - It's easier to copy bargraphs around the place for different purposes.

    Drawbacks
    - A minute amount of additional coding has to be done to map the level on the TP side onto the range of the bargraph.


    As far as best practices go, I would consider the following good policy:

    * Avoid active bargraphs if users are likely to inadvertently overrun the volume and prove a danger to themselves and the equipment. Use bargraphs for feedback only and allow the volume to be adjusted through up, down and mute buttons.

    * Use a consistent range for TP levels and perform a mapping in code to the actual value being dealt with in the master for the reasons outlined above.

    * Choose a sensible period for a full ramp. This may be slightly different for mic controls with ~5dB range and program controls with ~60db range. (Of course this may also be dictated by the device if it doesn't accept discrete levels). In most cases about 5 seconds would be long enough.

    * Handle push and push+hold scenarios in an appropriate manner. A push might adjust the level by 1dB for a mic or 1/15'th of the range for a program control. Hold behaviour depends a little on the device you're dealing with and your personal coding style (whether you're generating the ramp from the touch panel or in code).

    * If you're generating the volume ramp in code, commands can be sent out to the device at given time intervals (eg. every third of a second) while ramping, or at given volume levels (eg. 1dB increments). Each has it's place.
  • a_riot42a_riot42 Posts: 1,624
    Auser wrote: »
    * Avoid active bargraphs. Use bargraphs for feedback only and allow the volume to be adjusted through up, down and mute buttons.


    I use bargraphs for volume on almost every job and people seem to like to be able to instantly get to whatever volume they like without the delay of ramping. Not sure why you would suggest to avoid them.
    Paul
  • DHawthorneDHawthorne Posts: 4,584
    a_riot42 wrote: »
    I use bargraphs for volume on almost every job and people seem to like to be able to instantly get to whatever volume they like without the delay of ramping. Not sure why you would suggest to avoid them.
    Paul

    Many devices don't support discrete volume commands, and a lot of people will just ramp from 0 to 80 in a second, with no regard to eardrums or driver health. I generally avoid the active bargraphs too, but I will also usually put volume presets that can learn a setting (as long as the device and protocol support it) so you can jump to a specific volume without the delay.
  • a_riot42a_riot42 Posts: 1,624
    DHawthorne wrote: »
    Many devices don't support discrete volume commands, and a lot of people will just ramp from 0 to 80 in a second, with no regard to eardrums or driver health. I generally avoid the active bargraphs too, but I will also usually put volume presets that can learn a setting (as long as the device and protocol support it) so you can jump to a specific volume without the delay.

    Devices that don't have discrete volume can't have this feature, but for those that can, I always implement it. I guess I am not understanding the issues of which you speak. I have no control over what volume the client sets it to, so if they want to destroy their hearing there is nothing I can do to stop it. Not sure how that relates to the use of a bargraph though.
    Paul
  • AuserAuser Posts: 506
    As I work mainly in the commercial/education sectors, I deal with spaces which any number of users use - infrequently. Consequently it's necessary to try to save the users from themselves :) I could see how it would be different in a residential environment where there are a limited number of users who will become familiar with the system in a short space of time.
  • Bargraphs

    Dont use active bargraphs - use drags. That way you can drag it fast if you want, or not.
  • yuriyuri Posts: 861
    Dont use active bargraphs - use drags. That way you can drag it fast if you want, or not.

    Use an active bargraph, but set the "range up" "range down" time to 10 for example :)
  • PhreaKPhreaK Posts: 966
    yuri wrote: »
    Use an active bargraph, but set the "range up" "range down" time to 10 for example :)

    Agreed. It's the best of all worlds - users can just point to where they want the volume to go rather than having to hold a 'volume up/down' button and waiting for it to get there, you can remove said volume buttons giving you more screen realestate and a less cluttered interface and by using the range times you ensure that they're not going to suddenly jump from cocktail bar to rock concert levels. It tends to work especially nicely if you set a slower range up and a relatively quick range down time so that if the audio source was changed say from an unmasted cd to a 'commercial level' one they can quickly attenuate the levels. It allows you to shape the way the user can interact with the system without making them feel restricted in their actions.
  • viningvining Posts: 4,368
    I'd have to agree w/ Dave on this one. Active bargraphs are for lighting control not volume control. Using them for volume control is an accident waiting to happen. An unitended accidental tap, simply picking up a portable, kids screwing around or the guests who simply don't know that touching the top of the bargraph will increase volume to the max permitted level.

    I've never tried the dragging bargraph but that seems reasonably safe. In my AutoPatch module I always reset to a fixed turn on value which is slightly below a normal listening level. Ramping up from that point takes only a few seconds but if that's not quick enough then allow learned presets or something.

    I can't think of anything that would piss off a customer more then blowing their speakers or their eardrums. Imagine if this were to happen during a party. Yes, I know we're not responsible for our customer's stupidity but I wouldn't leave a loaded gun on their coffee table either.

    Logic dictates that we anticipate how the product should be used, will be used and might be used and applyiing a logical design to our systems is our job which includes anticpating the actions of idiots,the uninformed and the unaware.
  • yuriyuri Posts: 861
    vining wrote: »
    I'd have to agree w/ Dave on this one. Active bargraphs are for lighting control not volume control. Using them for volume control is an accident waiting to happen. An unitended accidental tap, simply picking up a portable, kids screwing around or the guests who simply don't know that touching the top of the bargraph will increase volume to the max permitted level.

    I've never tried the dragging bargraph but that seems reasonably safe. In my AutoPatch module I always reset to a fixed turn on value which is slightly below a normal listening level. Ramping up from that point takes only a few seconds but if that's not quick enough then allow learned presets or something.

    I can't think of anything that would piss off a customer more then blowing their speakers or their eardrums. Imagine if this were to happen during a party. Yes, I know we're not responsible for our customer's stupidity but I wouldn't leave a loaded gun on their coffee table either.

    Logic dictates that we anticipate how the product should be used, will be used and might be used and applyiing a logical design to our systems is our job which includes anticpating the actions of idiots,the uninformed and the unaware.

    what would you suggest? Drag? Up/Down buttons?

    If you set the range up time to something high, and you don't get the problems you describe :)
  • viningvining Posts: 4,368
    yuri wrote:
    If you set the range up time to something high, and you don't get the problems you describe
    That just adjusts the time it takes to go from point A to point B. If someone mistakenly touches the top of the bargraph it's still going to go to that level, just a bit slower. So now we're not immediately scaring the crap out of people and if the person who accidentially hit the bargraph is somewhat aware of what they just did they might think fast enough to correct their mistake. But why give them a chance to make a mistake when there are safer alternative?
  • PhreaKPhreaK Posts: 966
    vining wrote: »
    That just adjusts the time it takes to go from point A to point B. If someone mistakenly touches the top of the bargraph it's still going to go to that level, just a bit slower. So now we're not immediately scaring the crap out of people and if the person who accidentially hit the bargraph is somewhat aware of what they just did they might think fast enough to correct their mistake. But why give them a chance to make a mistake when there are safer alternative?

    Thats the same as saying that if someone accidently touches the volume up button it will eventually go to the max volume.
  • ericmedleyericmedley Posts: 4,177
    One thing to remember is that percieved lighting levels are linear. (twice as bright roughly equals twice as much power) Perception of sound pressure is logarithmic. Twice as much power does not equal a perception of twice as loud.

    People tend to try and be more precise in their changes since the power curve is moving logarithmically. Think about it if you use a fader to indicate the volume of something from its lowest to highest setting. The volume sweet spot is relatively small. But you can move a light fader from 90% to 100% and not see a substantial change in the light level.

    That's why I don't give fader-to-level control. Clients usually find them fussy in my experience.
  • bcirrisibcirrisi Posts: 148
    I'm a residental/Autopatch guy exclusively. The best way I handle it is to use a up/down buttons that raise and lower a bar graph internally on the touch screen. The bargraph is active, but I have a blank button over it, so you can't adjust it manually. I do all the programming based off of the level event (that was modified by the up/down buttons). Like discussed above, I have a flag variable that tracks if the touch screen is on online and I also check the current volume vs the old volume before I send a string out to the Autopatch.

    I'd like to take credit for it, but I stole it from an AMX demo file. The really beneficial thing for me is that if I get an Autopatch switcher that doesn't respond to the volume commands rapidly (Optima with DVC vs a Precis DSP) I just adjust the rate on the TP that is raises/lowers the bargraph. The other thing is that if the system is a little bogged down for some reason, the user can adjust the level to where they want it and it will go there once everything catches up.
Sign In or Register to comment.