Home AMX User Forum AMX General Discussion

Biamp AudiaFlex

Just wondering if anyone has a sample code they have used for this type of equipment. Someone decided to use it for the audio without telling anyone else in the project and I myself have never used this brand of equipment.

Comments

  • DiogoDiogo Posts: 65
    I used a couple times, it's a wonderful equipement
    The biggest problem in programming the biamp is that you need program in both sides
    the AMX and the Biamp.

    Do you already have the protocol rs232 protocol, or you going to use the TCP/IP?
    If you have a question feel free to ask
  • VLCNCRZRVLCNCRZR Posts: 216
    .... I myself have never used this brand of equipment.

    I just got dumped into this same situation for a divisible meeting room project.

    I dont know the first thing about CobraNet, and this Biamp is
    being programmed by another local audio vendor.

    I have looked at the system drawings, but I dont see a way to know what individual channels
    are doing. I am too used to using the ClearIOne devices programmed in-house.

    I am anticipating control via RS232 serial strings.
  • PhreaKPhreaK Posts: 966
    The biamp units are open architecture, as opposed to products like the clear ones which have a fixed layout. This basically means that you have inputs, outputs and a bunch of various signal processing and routing modules, how all of these are connected is entirely up to the DSP programmer. As such you will need to work closely with them or have them supply you with a list of controllable components and their function within the system. I'd recommend grabbing the Audia software from the Biamp site, if you have a look in the help file the control protocol is very well documented as well as tons of information about the functions of the different signal processing objects. You can then also request the layout file from the programmer (or connect to the box and grab it) so that you can see whats going on. This will also allow you to connect on site and verify that everything is being controlled correctly.
  • Thomas HayesThomas Hayes Posts: 1,164
    I had the department that programmed the system in today and were unable to get it to work, (I don't feel as bad now). They want to look further into the code to see how their designer programmed the system. Once they get it working manually I'll be able to test my code.
  • They really aren't bad to control. A year or so ago, the AMX programmer had to specify a randomly assigned "Instance ID" of the level controller. Now the person programming the Biamp can assign a "Tag" to that level. (Like program_volume).

    We do almost 100% Biamp in our installations. I know the engineers probably prefer ClearOne, but controlling either is just as easy.

    If you need more help, email me directly. I'd be more than happy to help.

    gcummins@sensorytechnologies.com
  • PhreaKPhreaK Posts: 966
    They really aren't bad to control. A year or so ago, the AMX programmer had to specify a randomly assigned "Instance ID" of the level controller. Now the person programming the Biamp can assign a "Tag" to that level. (Like program_volume).

    Agreed, its quite a nice protocol and the open architecture allows you to do some much more funky stuff.

    That tag thing is awesome, is it only for level controls or any object?
  • AuserAuser Posts: 506
    PhreaK wrote: »
    That tag thing is awesome, is it only for level controls or any object?

    Any DSP block. If used wisely, you can use instance tags to make your code much more portable from job to job, by using the same tags for common controls such as far end levels, program audio levels, etc in each Biamp file.

    Thomas, make sure you grab a copy of the protocol manual from the Biamp website if you haven't already. The protocol's pretty straightforward, but the manual is essential to have on hand to refer to.
  • Okay, got the code to work finally. Turns out that someone had unplugged the cobra-net switch.
  • bargraph

    HI I have almost the same situation with the Audia Flex but finally all is working. Im still working on how to display the volume from the device on a bargraph.
    Any light on this ???
  • I'm still working on the volume bar graph, if I get the code working right I'll post it.
  • chillchill Posts: 186
    I've been using Biamp for a few years now, and I can offer a couple of hints.

    First, as previously mentioned, instance tags rule. Use them always and life will be better.

    Second, your life will be further improved if you use the 'D' form of the commands, i.e. 'SETD', 'INCD, 'DECD'... This will give you a verbose, easily-parsable response to the commands you send.

    Finally, if your Biamp has a telephone interface, RS232 control is hugely preferred over IP. With RS232, you can use 'command string' symbols in the Biamp program, which can notify you of things like telephone hook state and incoming calls. In principle you can poll for these things using IP control, but I find things run much more smoothly and reliably if you don't have to poll. The other thing about the 'command string' symbol is that it only sends out the COM port of the box (unit) in which it resides, so be aware of that in multi-box Flex systems.

    If you're still having trouble with level feedback, speak up and I'll post how I do it.

    Hope this helps.
  • Biamp AudiaFlex Panel Bargraph

    Yes, still need some help with this.

    Thanks
  • chillchill Posts: 186
    To do Biamp volume control, I use the push: section to unmute the audio
    and (optionally) send one volume command, then do further volume commands
    in the hold: section.

    Let's assume you're controlling program volume with a Biamp fader object
    (with multiple ganged channels if you like), and its instance tag is
    pgm_vol. Or you could use an instance number, but I like tags better.

    Here's a sample, parts of which are left as an exercise :^)
    volatile integer vol_b[] =
    {
      24,25  // up, down
    }
     
    button_event[tp,vol_b]
    {  
      push :
      {
        send_string biamp,"'SETD 2 MUTE pgm_vol 1 0',lf"  // unmute
      }
      hold[3,repeat] :
      {
        local_var char cmd[4]  
         
        switch(get_last(vol_b))
        {
          case 1 :  // vol up  
            cmd = 'INCD'
          case 2 :  // vol down
            cmd = 'DECD'
        }
        send_string biamp,"cmd,' 2 FDRLVL pgm_vol 1 3',lf"
        // ...2 is the Biamp unit number for this fader, 1 is
        // the fader channel, and 3 is the step size in dB
      }
    }
    

    This should work as-is for volume control.

    To drive a bargraph, I look at what comes back from the Biamp, parsing out
    the instance tag in order to know which bargraph to update. After each
    successful volume adjustment, it will come back with a string like the
    above, ending with a number representing the actual dB level of the fader.
    Since this number is to six decimal places, I store my volumes in an array
    of floats and drive the bargraphs via a function that converts the <-100.0
    to +12.0> range into <0 to 255> for my bargraphs. Alternatively, you could
    define your bargraphs to have a range of <-100 to +12> in tpd4 and drive
    them directly.

    You can experiment with different values of repeat time and step size to
    get a speed + smoothness combination that looks good to you.

    In real life I will generally have arrays of unit IDs, instance tags and
    bargraph addresses as well as the float array for volumes (all in the same
    order of course). I also queue my commands rather than do immediate
    send_strings as shown, but you get the idea.

    Hope this helps.
  • Biamp AudiaFlex Panel Bargraph

    I'm very new on this, but I'll try to figured out.

    Thanks!!!
Sign In or Register to comment.