Home AMX User Forum NetLinx Studio

Controlling a Gain N-Input (BSS) with Netlinx

Hello, I am trying to control a BLU-50 with a NX-2200 using the BSS module from the AMX trade site.. I have several inputs that are going from a matrix mixer to a Gain N-Input object (so that I have a master fader) in the DSP but I have no idea how to control it. There is nothing in the documentation or the example .axs files that mentions Gain N-Inputs and I don't know how else to write the DSP file. Any help would be greatly appreciated.

Comments

  • ericmedleyericmedley Posts: 4,177
    The AMX module is somewhat limited in scope in that regard. The master output of an N-Gain is command-wise no different than any other level. So as long as you have the Object ID and Paramter ID for the gain you want it should be okay. As a shamelss plug for my module (available in the MOPEDIA section) I can tell you that I don't treat any gains differently. A level is a level no matter how small. You just enter in the Object ID and paramter ID and you get control and feedback (if available) I've stopped using the AMX once as it's been pretty buggy and the support (in my case) has been rather problematic. But, that's just me. I use mine.
  • ZachjZachj Posts: 12
    ericmedley wrote: »
    The AMX module is somewhat limited in scope in that regard. The master output of an N-Gain is command-wise no different than any other level. So as long as you have the Object ID and Paramter ID for the gain you want it should be okay. As a shamelss plug for my module (available in the MOPEDIA section) I can tell you that I don't treat any gains differently. A level is a level no matter how small. You just enter in the Object ID and paramter ID and you get control and feedback (if available) I've stopped using the AMX once as it's been pretty buggy and the support (in my case) has been rather problematic. But, that's just me. I use mine.

    Thanks for the response, I could not find the object ID's for the individual levels in the N-Gain at first but I dropped a 3rd-party controller in the Audio Architect file so I could see the ids (I'm new to AMX and BSS). I will check out your module, thank you for sharing that, I did not know there were problems with the official module.
  • ericmedleyericmedley Posts: 4,177
    Zachj wrote: »

    Thanks for the response, I could not find the object ID's for the individual levels in the N-Gain at first but I dropped a 3rd-party controller in the Audio Architect file so I could see the ids (I'm new to AMX and BSS). I will check out your module, thank you for sharing that, I did not know there were problems with the official module.

    just so you know. The Third Party Controller is not a 'thing' per se. It's really just a handy gadget to help you come up with the command structure for a given piece of virtual gear and its attendant knobs. The thing to keep in mind with BSS is there is really no virtualization of things in the API like there is in other DSPs like Biamp. In other words there is no command that says something like "Adjust level X to value Y" where you can create a command on the fly by using text like "Set_Level",itoa(MyLevel_Name),itoa(My_Level_value),

    The way to think about it is sort of like imagining you have a single unique command for every single piece of gear and that command has no human readable components. It's all hex. You identify a 'thing' by it's Object ID. which is a unique number from zero to whatever, which lives in a box (again a unique number from zero to whatever) The indivual parameters are somewhat abritrary too. For examle the mute of a fader might be paramter ID 0 in one object but paramter ID 10 in another.

    Consequently, there's no simple way to create commands on the fly so to speak. The Module is doing a lot of that for you.

    Also, feedback from the device is maddening. For all intents and purposes you can really think of the 'Subscribe" command as really a "GET" with a lot of the feedback you are not in any way promised that you'll get asychornous data back.

  • LOL BSS again. My AMX reps were in here just a few weeks ago, trying to get me to substitute BSS products for Biamp products in a huge project on the horizon. I pretty much chewed them out over the BSS protocol, and told them I refused to fight to place their products, especially when I would also have to fight the products themselves, to complete the project. "You guys give me a sensible, human-readable API for the BSS, and do all the substitution request paperwork for me (it's a huge pre-defined system contract that requires extensive paperwork to request equipment substitutions), and I'll run it up the flagpole for you. Otherwise, no." I've had to deploy and custom-program one BSS system so far (because RPM couldn't handle the job), and I've basically blacklisted the use of additional BSS products, until they fix the API issue.
  • ericmedleyericmedley Posts: 4,177
    LOL BSS again. My AMX reps were in here just a few weeks ago, trying to get me to substitute BSS products for Biamp products in a huge project on the horizon. I pretty much chewed them out over the BSS protocol, and told them I refused to fight to place their products, especially when I would also have to fight the products themselves, to complete the project. "You guys give me a sensible, human-readable API for the BSS, and do all the substitution request paperwork for me (it's a huge pre-defined system contract that requires extensive paperwork to request equipment substitutions), and I'll run it up the flagpole for you. Otherwise, no." I've had to deploy and custom-program one BSS system so far (because RPM couldn't handle the job), and I've basically blacklisted the use of additional BSS products, until they fix the API issue.

    I don't have any insider information on this other than my understanding is that there are no plans to update the API as it would involve way more resource to do so than is practical considering normal product life-span. Talk about survival of the fittest...

  • Yeah the AMX reps were rather tight-lipped about the matter, other than to admit that my proposition was, "OK, fair enough."
  • ZachjZachj Posts: 12
    ericmedley wrote: »

    just so you know. The Third Party Controller is not a 'thing' per se. It's really just a handy gadget to help you come up with the command structure for a given piece of virtual gear and its attendant knobs. The thing to keep in mind with BSS is there is really no virtualization of things in the API like there is in other DSPs like Biamp. In other words there is no command that says something like "Adjust level X to value Y" where you can create a command on the fly by using text like "Set_Level",itoa(MyLevel_Name),itoa(My_Level_value ),

    The way to think about it is sort of like imagining you have a single unique command for every single piece of gear and that command has no human readable components. It's all hex. You identify a 'thing' by it's Object ID. which is a unique number from zero to whatever, which lives in a box (again a unique number from zero to whatever) The indivual parameters are somewhat abritrary too. For examle the mute of a fader might be paramter ID 0 in one object but paramter ID 10 in another.

    Consequently, there's no simple way to create commands on the fly so to speak. The Module is doing a lot of that for you.

    Also, feedback from the device is maddening. For all intents and purposes you can really think of the 'Subscribe" command as really a "GET" with a lot of the feedback you are not in any way promised that you'll get asychornous data back.

    So I essentially cannot set levels without the module because the API is not necessarily predictable? That is a major flaw, Im starting to worry now!

    So if I wanted to say, mute the master fader in the N-Gain by setting it to -∞dB, the 3rd party controller tells me that this string: '$02,$88,$00,$01,$1B,$83,$00,$01,$1B,$86,$00,$60,$ FF,$FB,$B7,$D7,$89,$03' is how to accomplish that. So I can I simply just put this string in a send_command statement in a push event to mute the master? That would be circumventing the module but would it work? It is hardcoded and not created on the fly at runtime.
  • ericmedleyericmedley Posts: 4,177
    Zachj wrote: »

    So I essentially cannot set levels without the module because the API is not necessarily predictable? That is a major flaw, Im starting to worry now!

    So if I wanted to say, mute the master fader in the N-Gain by setting it to -∞dB, the 3rd party controller tells me that this string: '$02,$88,$00,$01,$1B,$83,$00,$01,$1B,$86,$00,$60,$ FF,$FB,$B7,$D7,$89,$03' is how to accomplish that. So I can I simply just put this string in a send_command statement in a push event to mute the master? That would be circumventing the module but would it work? It is hardcoded and not created on the fly at runtime.

    Okay - this is a long answer and it depends upon what module you're talking about (I assume the AMX one) and how your're controlling the unit. (IP or RS232) If it's IP then you have a problem. While the AMX module (and I'm using the term very loosely) does have a PASSTHRU - but it is not your father's PASSTHRU. In previous AMX Modules the idea of the PASSTHRU command was that you wanted to send you own string to the device - thus bypassing the module. The old protocol was understood that when you send the PASSTHRU- command that whatever came after the "-" was up to you. The mdoule was going to just pass that string (regardless of what it was) through the port to the device. It was up to us to make sure that whatever that was worked and didn't horse up the module. Fair enough..

    However, the AMX module is (IMHO) not a pass thorugh. The new module requries you to create a structure, folloing the paramters of the module and format the command into recognizable chunks corresponding to the various parts of the BSS command. It would then do all the charactor replacement and checksum for you. To this day I do not understand the formatting. So, in that regard you're on your own.

    If however, you are doing rs232 then it is possible to bypass the module and send the string right on through. But, you'll want to follow up the command with a "Subscribe" commmand to force the BSS to reply back with it's current mute stat if you're tracking that.

    I spent a lot of time on my module getting this working. My feedback on volume / mute works well as far as I know. I've not had any issues.

    E
  • NZRobNZRob Posts: 70
    On all of my DSP modules (BSS, Nexia, ClearOne, Tesira, QSC, Extron) I gave up continuous polling and now only poll for volume and mute status on connection then force it to my levels/mute states after that.
  • ZachjZachj Posts: 12
    ericmedley wrote: »

    Okay - this is a long answer and it depends upon what module you're talking about (I assume the AMX one) and how your're controlling the unit. (IP or RS232) If it's IP then you have a problem. While the AMX module (and I'm using the term very loosely) does have a PASSTHRU - but it is not your father's PASSTHRU. In previous AMX Modules the idea of the PASSTHRU command was that you wanted to send you own string to the device - thus bypassing the module. The old protocol was understood that when you send the PASSTHRU- command that whatever came after the "-" was up to you. The mdoule was going to just pass that string (regardless of what it was) through the port to the device. It was up to us to make sure that whatever that was worked and didn't horse up the module. Fair enough..

    However, the AMX module is (IMHO) not a pass thorugh. The new module requries you to create a structure, folloing the paramters of the module and format the command into recognizable chunks corresponding to the various parts of the BSS command. It would then do all the charactor replacement and checksum for you. To this day I do not understand the formatting. So, in that regard you're on your own.

    If however, you are doing rs232 then it is possible to bypass the module and send the string right on through. But, you'll want to follow up the command with a "Subscribe" commmand to force the BSS to reply back with it's current mute stat if you're tracking that.

    I spent a lot of time on my module getting this working. My feedback on volume / mute works well as far as I know. I've not had any issues.

    E

    I am controlling it rs232. Thanks for all of your help, I have spent more time trying to understand/implement this BSS module than it would have taken me to finish the entire project if it were another control system. Im not trying to do anything complicated either, I just need to adjust faders and mute and unmute levels, I feel like a moron for spending so much time on this. I will try your module, hopefully it is far less cryptic than AMX's.
  • ericmedleyericmedley Posts: 4,177
    Zachj wrote: »

    I am controlling it rs232. Thanks for all of your help, I have spent more time trying to understand/implement this BSS module than it would have taken me to finish the entire project if it were another control system. Im not trying to do anything complicated either, I just need to adjust faders and mute and unmute levels, I feel like a moron for spending so much time on this. I will try your module, hopefully it is far less cryptic than AMX's.

    My Module: I dunno - while I didn't totally follow the AMX Audio DSP model, It's very much like it. Instead of one device with a bunch of ports being whatever you declare them, I have separate devices for each function. ex: The ports are to deliniate betwen things like Volume Ramp Up/ Volume Ramp odwn/ Volume Mute Toggle, Volume Discrete setting and feedback. The mutes are the same. Mute On,Off,Toggle,feedback.

    In my module - the Channels indicate which processing object your tlaking about. If you declare device 1 as being your N-Gain, for example, you'd pop volume ramp up> channel one to begin ramping the volume up. the feedback would come back on level ID 1. the mute would come back on channel 1 of the Mute FB device, etc...

    I went with this since I quite often find myself needing to control way more things than the 64 port limit on the AMX Duet modules. Since I use channels I can go out to the max of 500 or so.

    My only problem with just 'hard coding' the thing is its not as easily scalable if the client comes back later for more stuff. But you gotta do what you gotta do.
  • MLaletasMLaletas Posts: 226
    Personally on most of my modules I will have a "passthrough" command work similarly. Adding the correct prefix, postfix syntax, whether thats a CR, LF, checksum, start byte whatever. It just take the pertinent data and builds the string as normal. That way you dont need to calculate the checksum manually, or know in detail the exact syntax, just a little less work for me.
  • ericmedleyericmedley Posts: 4,177
    MLaletas wrote: »
    Personally on most of my modules I will have a "passthrough" command work similarly. Adding the correct prefix, postfix syntax, whether thats a CR, LF, checksum, start byte whatever. It just take the pertinent data and builds the string as normal. That way you dont need to calculate the checksum manually, or know in detail the exact syntax, just a little less work for me.

    This is what I typically do as well. I have a "formatted passthrough" and a "raw passthrough" With the BSS it would be especially good if you don't want to deal with all the chractor replacement and checksum crap. It's always good to have options.
  • MLaletasMLaletas Posts: 226
    ericmedley wrote: »
    For examle the mute of a fader might be paramter ID 0 in one object but paramter ID 10 in another.

    Thats the single thing that pissed me off about this protocol. I can deal with the hex, and all the other quirks, but this one for me takes it all. It took me a second to find the pattern for each of the objects that I normally deal with and create an algorithm that tells me the index of the control object. Very annoying I mean come on, one fader starting at 31 and incrementing by 1, makes sense, another one starting at 252 and incrementing at 50? And other random ones, come on man!

  • ericmedleyericmedley Posts: 4,177
    MLaletas wrote: »

    Thats the single thing that pissed me off about this protocol. I can deal with the hex, and all the other quirks, but this one for me takes it all. It took me a second to find the pattern for each of the objects that I normally deal with and create an algorithm that tells me the index of the control object. Very annoying I mean come on, one fader starting at 31 and incrementing by 1, makes sense, another one starting at 252 and incrementing at 50? And other random ones, come on man!

    To me this is one of those curious moments where you scratch your head at how we engineer-types think. This entire protocol is sort of the mental equivalent of an AMX programmer creating a unique button event for every button on a UI. It's like they've never thought of the idea of virtualizing code. they've never thought of something like a button array or a device arra and using the math to simplify the API. Consequently, there are actually holes in the control API. There are things that cannot be controlled that one might think would be obviously controllable. The list goes on and on. But, it's obvious that they've gone waaaaaay to far down that road to ever turn back. Once you've written yourself into a corner this bad, you really cannot come back. You just have to scrap the whole mess and start over.

    I really wonder if they realize how badly Biamp is handing them their a$$ on this. They've gotta know. Right now I don't have a single AMX Integrator I deal with that will spec them in a system. The only time I see them is when the integrator had AMX Engineering design the system for them. One of their first questions to me when we are looking at a project is "Are you okay doing Biamp? 'cause there is no way we're putting a BSS in the system." It's truly an albatross for AMX.

  • In my BSS design I've done, I've abstracted all volume and mute controls to discreet N-Gain components, so I only need one code stack to handle those, all the parameters except the object ID and the level value are the same, and I can store those object ID's and levels in tables, so the code is relatively modular. The only other thing I've needed to conquer is matrix switching. Again, one type of matrix switcher so far, so everything except the actual object ID, and the tie point ID's, need a reference table for.

    Too often, I've tried using modules, only to find it took me as long to figure out and harness the module, as it would to just to write discreet code that handles the 1-3 functions I actually need to control in the device. When I realize I'm using more than half PASSTHRU commands with a module, it usually means I'm not really using the module as intended, I might as well directly program it.
  • NZRobNZRob Posts: 70
    Most of the jobs I see now are QSC, Biamp is good but QSC is better from the programmers perspective. You can emulate the whole DSP program on your laptop and then point a processor at it and test everything without needing the hardware. I see BSS when the AV Contractor is going cheap and doesn't care. (So all the time from one AV contractor)
  • ericmedleyericmedley Posts: 4,177
    NZRob wrote: »
    Most of the jobs I see now are QSC, Biamp is good but QSC is better from the programmers perspective. You can emulate the whole DSP program on your laptop and then point a processor at it and test everything without needing the hardware. I see BSS when the AV Contractor is going cheap and doesn't care. (So all the time from one AV contractor)

    I agree. The QSC is kind of a 'Next Gen' in audio DSP. It's very cool. I have a couple jobs with it and it was pretty powerful stuff.
  • MLaletasMLaletas Posts: 226
    Now with QRC protocol I love integrating with Q-SYS, really wish we did more of them.
Sign In or Register to comment.