Home AMX User Forum NetLinx Studio
Options

help with volume control ClearOne Converge 840T

So our AMX programmer quit and left me to pick up the pieces and finish up a client's punchlist. The complaint is that the volume bar on the touch panel doesn't give a good reflection of what the perceived room volume is. They also say that the mute button "is not transitioning reliably".


The Range High is set to 100, and the Range Low is set to 30 in TP4 on the volume bar.
Here is the related code.
DEFINE_FUNCTION parseClearResponse (char msg[])
{
	if(find_string(msg,'GAIN',1))	//  SEARCH FOR GAIN MESSAGES	
	    {
		if(find_string(msg,'GAIN 1 O',1))	//  TRACK OUT CHANNEL 1 LEVEL
		    {
			remove_string(msg,'GAIN 1 O',1)
			sPgmVol = ATOI (GET_BUFFER_STRING(msg,4))
			 SEND_LEVEL dvTouch,1,((sPgmVol)+66)
		    }
	    }
	if(find_string(msg,'TE',1))			//TRACK TELEPHONE STATUS
	    {
		if(find_string(msg,'MUTE',1))
		    {
		    remove_string(msg,'MUTE 1',4)
		    }
		else if(find_string(msg,'TE',1))
		    {
		    remove_string(msg,'TE 1',1)
			get_buffer_char(msg)
			sTelResp = ATOI (GET_BUFFER_STRING(msg,1))
		    }
	    }
	if(find_string(msg,'RING 1',1))			//TRACK TELEPHONE STATUS
	    {
		if(find_string(msg,'RING 1',1))
		    {
			SEND_COMMAND dvTouch,"'WAKE'"
			wait 10
			SEND_COMMAND dvTouch,"'@PPN-Dialog - ATC - Incoming Call'"
		    }
	    }
	
}
DATA_EVENT[dvAudio]   					
{
    ONLINE:
	{
	    SEND_COMMAND DATA.DEVICE,"'SET BAUD 38400,N,1 485 DISABLED'"
	    Send_Command DATA.DEVICE, "'HSOFF'"
	}
    STRING:
	{
	    local_var buf[200]
	    char cmd[200]
	    buf = "buf,data.text"				//  THIS PREVENTS PARTIAL MESSAGES
	    WHILE(FIND_STRING(buf,"$0D",1)) 			// WAIT FOR THE CR
		{
			cmd = REMOVE_STRING(buf,"$0D",1)
			parseClearResponse(cmd)
		}
	}
}
BUTTON_EVENT[dvTouch,1]				//  Volume Up
{
    Push:
	{
	    Send_String dvAudio, "'#30 GAIN 1 O +1 R',$0D,$0A"	    
	}
    Hold [2,Repeat]:
	{
	    Send_String dvAudio, "'#30 GAIN 1 O +1 R',$0D"
	}
}
BUTTON_EVENT[dvTouch,2]				//  Volume Down
{
    Push:
	{
	    Send_String dvAudio, "'#30 GAIN 1 O -1 R',$0D"
	}
    Hold [2,Repeat]:
	{
	    Send_String dvAudio, "'#30 GAIN 1 O -1 R',$0D"
	}
}
BUTTON_EVENT[dvTouch,3]				//  Program Volume Mute Toggle
{
    Push:
	{
	Switch(nPgmMute)
	    {
	    Case 0:
		{
		    Send_String dvAudio, "'#30 MUTE 1 O 1',$0D"
		    nPgmMute = 1
		}
	    Case 1:		
		{
		    Send_String dvAudio, "'#30 MUTE 1 O 0',$0D"
		    nPgmMute = 0
		}
	    }
	}
}

Any help will be appreciated.

-Tim

Comments

  • Options
    HedbergHedberg Posts: 671
    tkroeger wrote: »
    So our AMX programmer quit and left me to pick up the pieces and finish up a client's punchlist. The complaint is that the volume bar on the touch panel doesn't give a good reflection of what the perceived room volume is. They also say that the mute button "is not transitioning reliably".


    The Range High is set to 100, and the Range Low is set to 30 in TP4 on the volume bar.
    Here is the related code.
    DEFINE_FUNCTION parseClearResponse (char msg[])
    {
    	if(find_string(msg,'GAIN',1))	//  SEARCH FOR GAIN MESSAGES	
    	    {
    		if(find_string(msg,'GAIN 1 O',1))	//  TRACK OUT CHANNEL 1 LEVEL
    		    {
    			remove_string(msg,'GAIN 1 O',1)
    			sPgmVol = ATOI (GET_BUFFER_STRING(msg,4))
    			 SEND_LEVEL dvTouch,1,((sPgmVol)+66)
    		    }
    	    }
    	if(find_string(msg,'TE',1))			//TRACK TELEPHONE STATUS
    	    {
    		if(find_string(msg,'MUTE',1))
    		    {
    		    remove_string(msg,'MUTE 1',4)
    		    }
    		else if(find_string(msg,'TE',1))
    		    {
    		    remove_string(msg,'TE 1',1)
    			get_buffer_char(msg)
    			sTelResp = ATOI (GET_BUFFER_STRING(msg,1))
    		    }
    	    }
    	if(find_string(msg,'RING 1',1))			//TRACK TELEPHONE STATUS
    	    {
    		if(find_string(msg,'RING 1',1))
    		    {
    			SEND_COMMAND dvTouch,"'WAKE'"
    			wait 10
    			SEND_COMMAND dvTouch,"'@PPN-Dialog - ATC - Incoming Call'"
    		    }
    	    }
    	
    }
    DATA_EVENT[dvAudio]   					
    {
        ONLINE:
    	{
    	    SEND_COMMAND DATA.DEVICE,"'SET BAUD 38400,N,1 485 DISABLED'"
    	    Send_Command DATA.DEVICE, "'HSOFF'"
    	}
        STRING:
    	{
    	    local_var buf[200]
    	    char cmd[200]
    	    buf = "buf,data.text"				//  THIS PREVENTS PARTIAL MESSAGES
    	    WHILE(FIND_STRING(buf,"$0D",1)) 			// WAIT FOR THE CR
    		{
    			cmd = REMOVE_STRING(buf,"$0D",1)
    			parseClearResponse(cmd)
    		}
    	}
    }
    BUTTON_EVENT[dvTouch,1]				//  Volume Up
    {
        Push:
    	{
    	    Send_String dvAudio, "'#30 GAIN 1 O +1 R',$0D,$0A"	    
    	}
        Hold [2,Repeat]:
    	{
    	    Send_String dvAudio, "'#30 GAIN 1 O +1 R',$0D"
    	}
    }
    BUTTON_EVENT[dvTouch,2]				//  Volume Down
    {
        Push:
    	{
    	    Send_String dvAudio, "'#30 GAIN 1 O -1 R',$0D"
    	}
        Hold [2,Repeat]:
    	{
    	    Send_String dvAudio, "'#30 GAIN 1 O -1 R',$0D"
    	}
    }
    BUTTON_EVENT[dvTouch,3]				//  Program Volume Mute Toggle
    {
        Push:
    	{
    	Switch(nPgmMute)
    	    {
    	    Case 0:
    		{
    		    Send_String dvAudio, "'#30 MUTE 1 O 1',$0D"
    		    nPgmMute = 1
    		}
    	    Case 1:		
    		{
    		    Send_String dvAudio, "'#30 MUTE 1 O 0',$0D"
    		    nPgmMute = 0
    		}
    	    }
    	}
    }
    

    Any help will be appreciated.

    -Tim

    It appears that the programmer has the volume level varying indication from -36db to +34db. You have to decide how you want the actual gain values (which are limited from -65db to 20db) to be mapped to the tp graph and then set your high and low range values accordingly. If the programmer was correct and -36db represents a minimum volume level then something like 0db to 10db might represent a maximum volume level. Changing your high range setting from 100 to 80 would give you a range of about -36db to +16db on your actual output channel gain which might do what you want. Also note that ClearOne provides you the ability to set max and min values for a channel's gain so you could limit the possible values from -35 to 10 (for example) if you wanted.

    As for the mute thing, with ClearOne units I've found that sending a mute toggle command to the unit and then deriving state by parsing the return string works very well. to do that, change the string sent to the ClearOne:

    Send_String dvAudio, "'#30 MUTE 1 O 2',$0D"

    The '2' will cause the channel mute to change state. Then, parse the return string to get your button feedback:
    DEFINE_FUNCTION parseClearResponse (char msg[])
    {
    	if(find_string(msg,'MUTE',1))	//  SEARCH FOR Mute MESSAGES	
    	    {
    		if(find_string(msg,'MUTE 1 O',1))	//  TRACK OUT CHANNEL 1 Mute Status
    		    {
    			remove_string(msg,'MUTE 1 O',1)
    			sPgmMute = ATOI (msg)
    			[dvTouch,3] = sPgmMute 
    
    etc, etc etc
    

    this should work though none of this code is real well designed or pretty. Itt will get the job done, though.

    Note that if you change the way the mute button feedback works you might need to remove the feedback code that the programmer used -- probably in the define_program section.
  • Options
    thank you thank you thank you

    this helps TREMENDOUSLY. I also recently found out that the default baud rate on the ClearOne is actually 57600, I doubt they changed it from that in the DSP interface. That's probably causing some issues too. Lastly, I think there is a comma missing in the baud rate command line separating the bits from the 485 stuff.
  • Options
    HedbergHedberg Posts: 671
    tkroeger wrote: »
    thank you thank you thank you

    this helps TREMENDOUSLY. I also recently found out that the default baud rate on the ClearOne is actually 57600, I doubt they changed it from that in the DSP interface. That's probably causing some issues too. Lastly, I think there is a comma missing in the baud rate command line separating the bits from the 485 stuff.

    If you want to change just the baud rate, you can change just the baud rate. For example:

    send_command dvDevice,'SET BAUD 38400'

    works just fine. If you don't need to change the other stuff, you don't have to include it. For completeness and to avoid confusion, you might like to, but you don't need to. The moral of this story is that an error back there related to 485 disable probably doesn't matter.

    The clear one units seem to work just fine at the default 57600 rate and that's what we've been using. This is nice, particularly if you use presets which can flood the rs232 channel with all sorts of superfluous crap.
  • Options
    Hedberg wrote: »
    If you want to change just the baud rate, you can change just the baud rate. For example:

    send_command dvDevice,'SET BAUD 38400'

    works just fine. If you don't need to change the other stuff, you don't have to include it. For completeness and to avoid confusion, you might like to, but you don't need to. The moral of this story is that an error back there related to 485 disable probably doesn't matter.

    The clear one units seem to work just fine at the default 57600 rate and that's what we've been using. This is nice, particularly if you use presets which can flood the rs232 channel with all sorts of superfluous crap.

    Thanks again. I get back onsite Nov 7th and 8th. I'll check back in with results.
  • Options
    mute itself seems to be more consistent, but button feedback doesn't work.
  • Options
    HedbergHedberg Posts: 671
    tkroeger wrote: »
    mute itself seems to be more consistent, but button feedback doesn't work.


    I don't easily see a reason why the parsing routine doesn't properly set the integer value for sPgmMute (which appears to be defined as an integer) and set the button state accordingly. Does the value for sPgmMute toggle when you push the button [dvtouch,3]?

    If not, are you getting the expected return back from the clear one when you send it the toggle mute instruction?
  • Options
    I ended up putting it back to the way it was initially. I fixed the inconsistency by putting the baud rate back to default. There were some other channels of mute/unmute being used when they shouldn't have been that was causing a majority of the issues.

    I think I got all the bugs worked out and should be getting sign-off momentarily.

    Thanks again for all your help, any new programs I may have to do will be using your method, much cleaner and easier to implement. I just couldn't do it with the code already being written in the time I had to do it on this one.

    -Tim
Sign In or Register to comment.