Volume Level Control Best Practices
wilw410
Posts: 14
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.
Thanks in advance for any and all advice.
0
Comments
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.
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.
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.
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.
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.
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
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 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.
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.
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
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 :-)
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.
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.
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
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
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.
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
Thats the same as saying that if someone accidently touches the volume up button it will eventually go to the max volume.
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.
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.