Controlling a Gain N-Input (BSS) with Netlinx
Zachj
Posts: 12
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.
0
Comments
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.
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...
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
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.
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.
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.
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.
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.