Controlling Biamp Audiaflex through TCP/IP for the first time

Pan AVCO

Hello all, I'm still new to the programming world and currently working on a system with a NI-900, and going to be controlling a Biamp Audiaflex through TCP/IP. My question is, how do I find the server port number on the Biamp for the AMX controller to connect to ? any help is appreciated, thanks in advance !

regallion

It's 23 - standard telnet!

Andrew G Welker

Pan AVCO wrote: »

Hello all, I'm still new to the programming world and currently working on a system with a NI-900, and going to be controlling a Biamp Audiaflex through TCP/IP. My question is, how do I find the server port number on the Biamp for the AMX controller to connect to ? any help is appreciated, thanks in advance !

If you download the Audia DSP program from Biamp's website, the help file explains everything for you, including commands and other things.

Pan AVCO

regallion wrote: »

It's 23 - standard telnet!

I couldn't find what port to use in the Biamp manual. For my future reference, if it isn't the standard port, would it usually listed in the device's manual ? and if it doesn't say, would it be safe to say it's using the standard port ? How can I check to see if the connection was made ? Sorry for so many questions. Like I mentioned earlier, I'm new to all of this, thanks for the quick response.

Pan AVCO

Andrew G Welker wrote: »

If you download the Audia DSP program from Biamp's website, the help file explains everything for you, including commands and other things.

Thanks, I'll go take a look right now

PhreaK

Pan AVCO wrote: »

For my future reference, if it isn't the standard port, would it usually listed in the device's manual ?

Yep. The vast majority of controllable devices you will come across though expose a telnet interface (that, again for the most part, mirrors their serial control protocol) on port 23 and/or a XML based API on port 80.

Pan AVCO

Thanks for the help, everyone. I got a successful connection to the Biamp, now just have to figure out the strings to control the unit.

Andrew G Welker

Pan AVCO wrote: »

Thanks for the help, everyone. I got a successful connection to the Biamp, now just have to figure out the strings to control the unit.

Those are in the help file for the Audia software as well. Typically, if you are controlling a fader level in a volume control block, the command is SETD 1 FADERLVL 2 3 4$0D. This should set the level for the third fader in a volume control block with instance ID 2 in Unit 1 to +4 dB. The SETD part will tell the unit to give you a verbose response,
basically echoing the command back to you. Otherwise the AudiaFLEX will respond with an ok.

There are is one thing that will make your life easier as you program these units more. If you have access to the DSP file, which you should since you need at least the instance ID's for the blocks you want to control, it would be a good idea to use the instance ID tag field. This field is found on the property sheet under the DSP attributes tab. In this field, you can essentially name the block you want to control.

For instance, if you have a volume block that is going to be controlling the microphone volume, you would put something like MicVolume in the Instance ID tag field in the DSP file. Then, in the command above, you would replace the 2 after FADERLVL with MicVolume. This will make the command easier to read, as well as help to prevent possible issues if someone selects the 'reassign instance ID numbers' command in the Audia software. This will also allow you to make your code a little more portable, as you can then use the same instance Id Tag everywhere and not worry about the actual instance Id number.

If you are using the Duet module, I believe you can still use the Instance ID tags, but I haven't tried that out yet, as it's been awhile since I've used the module.

AMXJeff

Biamp Duet Module?

Why would anyone want to re-invent controlling the biamp. The Biamp Duet Module does a good job at it, and it is really easy to use.

DEFINE_DEVICE

dvBiamp = 0:3:0
vdvBiamp = 41001:1:0;

vdvBiampFader = 41001:2:0; // ADDRESS 1.18.8.0

dvTP = 10001:1:0

DEFINE_CONSTANT

VOLUME_UP 	= 24;
VOLUME_DN 	= 25;
VOLUME_MT = 26;
VOLUME_MT_FB  = 199;

DEFINE_START

// comm module
DEFINE_MODULE 'Biamp_AudiaFlex_Comm_dr1_0_0' modBiampComm1(vdvBiamp,dvBiamp);

DEFINE_EVENT

DATA_EVENT[vdvBiamp]
{
	ONLINE:
	{
		SEND_COMMAND vdvBiamp,'PROPERTY-IP_Address,192.168.30.12'
		
		// ASSIGNS FADER TO "vdvBiampFader"
		SEND_COMMAND vdvBiamp,"'AUDIOPROCADD-',ITOA(vdvBiampFader.PORT),',LEVELFADERS.FADER.SET:1.18.8.0'";
		
		SEND_COMMAND vdvBiamp,'REINIT'
	}
}

BUTTON_EVENT[dvTP,20] // FADER 1.18.8.0 RAISE
{
	PUSH:
	{
		TO[vdvBiampFader,VOLUME_UP]
		TO[BUTTON.INPUT];
	}
}

BUTTON_EVENT[dvTP,22] // FADER 1.18.8.0 LOWER
{
	PUSH:
	{
		TO[vdvBiampFader,VOLUME_DN]
		TO[BUTTON.INPUT];
	}
}

BUTTON_EVENT[dvTP,21] // FADER 1.18.8.0 MUTE
{
	PUSH:
	{
		TO[vdvBiampFader,VOLUME_MT];
	}
}

// FADER LEVEL
LEVEL_EVENT[vdvBiampFader, 1]
{
	SEND_LEVEL dvTP,2,LEVEL.VALUE
}

DEFINE_PROGRAM

[dvTP,21] = [vdvBiampFader, VOLUME_MT_FB];

Andrew G Welker

I would agree, but it might also be a good learning experience the first time.

Pan AVCO

Andrew G Welker wrote: »

Those are in the help file for the Audia software as well. Typically, if you are controlling a fader level in a volume control block, the command is SETD 1 FADERLVL 2 3 4$0D. This should set the level for the third fader in a volume control block with instance ID 2 in Unit 1 to +4 dB. The SETD part will tell the unit to give you a verbose response,
basically echoing the command back to you. Otherwise the AudiaFLEX will respond with an ok.

There are is one thing that will make your life easier as you program these units more. If you have access to the DSP file, which you should since you need at least the instance ID's for the blocks you want to control, it would be a good idea to use the instance ID tag field. This field is found on the property sheet under the DSP attributes tab. In this field, you can essentially name the block you want to control.

For instance, if you have a volume block that is going to be controlling the microphone volume, you would put something like MicVolume in the Instance ID tag field in the DSP file. Then, in the command above, you would replace the 2 after FADERLVL with MicVolume. This will make the command easier to read, as well as help to prevent possible issues if someone selects the 'reassign instance ID numbers' command in the Audia software. This will also allow you to make your code a little more portable, as you can then use the same instance Id Tag everywhere and not worry about the actual instance Id number.

If you are using the Duet module, I believe you can still use the Instance ID tags, but I haven't tried that out yet, as it's been awhile since I've used the module.

Thanks for the tip, giving a name to the blocks that I want to control is something that I'll definitely look in to doing.

Pan AVCO

I started putting together the strings for controlling the Biamp. Is there a way I can monitor the strings being sent to and coming from the unit using the notifications window when controlling through TCP/IP ? I tried adding the DPS 0:3:1 and enabling strings to and from the address, but I don't see anything in the notifications window.

nicholasjames

Pan AVCO wrote: »

I started putting together the strings for controlling the Biamp. Is there a way I can monitor the strings being sent to and coming from the unit using the notifications window when controlling through TCP/IP ? I tried adding the DPS 0:3:1 and enabling strings to and from the address, but I don't see anything in the notifications window.

Unfortunately, No. I've never heard a reason for this, but I've always assumed it had something to do with the IP device being on Device 0 (the master) and you can't receive notifications for messages being passed between masters.

Your best bet is to either forward those strings to a virtual device and monitor those messages, or set up some debugging functions and forwarded it to the console when you need.

Pan AVCO

nicholasjames wrote: »

Unfortunately, No. I've never heard a reason for this, but I've always assumed it had something to do with the IP device being on Device 0 (the master) and you can't receive notifications for messages being passed between masters.

Your best bet is to either forward those strings to a virtual device and monitor those messages, or set up some debugging functions and forwarded it to the console when you need.

Hm, all right. I've been using the notifications windows to view strings being sent out just to make sure I'm sending correct strings to my devices, and to see the responses so that I know exactly what to look for when doing feedback. So, the only way I can do this for devices being controlled through TCP/IP is to create a virtual device and forwarding the strings ?

nicholasjames

Yup.

This message is at least 10 characters.