Vol Bar

Thomas Hayes

In the quest to make a more universal template for my TP's I'm often faced with tweaking the volume feedback bar depending on what the output data from the different devices are. I'd like to leave the bargraph at 254 level and just have a math fomula that would take the referance level and convert it over to always be based on the 254(max) level. What and how have others done this or do you just change the bar graph variables all the time?

ericmedley

Thomas Hayes wrote: »

In the quest to make a more universal template for my TP's I'm often faced with tweaking the volume feedback bar depending on what the output data from the different devices are. I'd like to leave the bargraph at 254 level and just have a math fomula that would take the referance level and convert it over to always be based on the 254(max) level. What and how have others done this or do you just change the bar graph variables all the time?

I just do the math. I create modules for each device and it's done there and sent as a level change to the virt device.

annuello

There is a lovely chunk of sample code in the AMX Epson 811 UI.axi module which I use over and over for this sort of thing. Here is a sample of it. You basically put in the actual value that you have, then the range that it come from, and the range that you would like to scale it to.

define_function slong Scale_Range(slong Num_In, slong Min_In, slong Max_In, slong Min_Out, slong Max_Out){
 stack_var
 slong Val_In
 slong Range_In
 slong Range_Out
 slong Whole_Num
 float Num_Out

 Val_In = Num_In                 // Get input value
 if(Val_In == Min_In)            // Handle endpoints
  Num_Out = Min_Out
 else if(Val_In == Max_In)
  Num_Out = Max_Out
 else{                            // Otherwise scale...
  Range_In = Max_In - Min_In      // Establish input range
  Range_Out = Max_Out - Min_Out   // Establish output range
  Val_In = Val_In - Min_In        // Remove input offset
  Num_Out = Val_In * Range_Out    // Multiply by output range
  Num_Out = Num_Out / Range_In    // Then divide by input range
  Num_Out = Num_Out + Min_Out     // Add in minimum output value
  Whole_Num = type_cast(Num_Out)  // Store the whole number only of the result
  if(((Num_Out - Whole_Num)* 100.0) >= 50.0)
   Num_Out++    // round up
 }
 return type_cast(Num_Out)
}

So if you want to convert say, 15 from a scale of 0 - 20 to a scale of 0 to 255 you would do the following:

char myNewValue
myNewValue = Scale_Range(15,0,20,0,255)

I tend to update all my levels using a timeline every 250mSec to reduce network traffic, so I don't see the above maths causing any latency. Hope this is useful.

Roger McLean
Swinburne University

DHawthorne

I use to convert my values, but I have found that rounding discrepancies often make problems, and have taken to simply adjusting the range on the bargraph instead. Besides teh rounding issue, I tend to lose track of when and where I have to convert, and when to end it raw, and found it better just to leave the value in its native form (where possible ... some devices use a funky -db to +db scheme that doesn't lend itself well to that) for simplicity's sake. The more complex the program, the more I appreciate one less thing to have to keep track of.

Thomas Hayes

Thank's that's a pretty neat little piece of code.
Like Dave I use the panel to setup the bargraph levels but was interested if this was the common practice or if there's a better way. I've talked to AMX staff and have heard them recomand both ways(depends on who you ask as to which way is best. thanks for all the input.

ericmedley

Thomas Hayes wrote: »

Thank's that's a pretty neat little piece of code.
Like Dave I use the panel to setup the bargraph levels but was interested if this was the common practice or if there's a better way. I've talked to AMX staff and have heard them recoomand both ways(depends on who you ask as to which way is best. thanks for all the input.

In my case we tend to have clients who like to change out gear a lot. For me it's just easier to change out a line or two of code rather than alter the TP file..

I can load a program file much quicker than I can 10-20 TPs remotely.

Either was is perfectly legit.

annuello

Just a few more thoughts on how I use the above code:

To avoid rounding issues I tend to make my ramping code increment/decrement the values in the scale that has the least resolution. For me this is typically the device. (E.g. Projector with volume range from 0 to 20.) I then use the Scale_Range() for updating the 0-255 level of the virtual. The virtual level does not pass through every value from 0 to 255 while ramping, but the hardware doesn't have such fine grain control anyway. When updating TP levels every quarter of a second it doesn't seem to be an issue.

If you are ramping some hardware that has a resolution greater than 255 it may be prudent to apply the increments/decrements to the 0-255 range, though you will lose the fine-grain control of the hardware. I haven't used Scale_Range() in this context.

If you are using Scale_Range() for ranges that span either side of 0 (e.g. -60dB to +16dB) I found that it is not too reliable, possibly due to rounding issues with the negative values. (Or perhaps I was doing something wrong?) In those situations I offset the range (and "raw" value) so that it becomes a 0 to XX value. Just add the ABS() of your lowest negative value. My context was a Marantz amp that was locked away in a cupboard. I also wanted to limit how loud the users could push it to prevent them from blowing up some small speakers. Rather than hard code absolute values I used a variable to hold the "harware max" value and was able to adjust it on site.

Roger McLean
Swinburne University