Anyone used/using the SoundStructure COMM module?
Chip Moody
Posts: 727
Short of hooking up a SS unit and trying to bash out my own answers, thought I might check here first...
Is there a relation between the VIRTUAL_CHANNEL command and defined virtual devices that's not immediately apparent? The demo program shows identical index numbers being passed to multiple VIRTUAL_CHANNEL calls, which has me scratching my head a bit.
Thanks,
- Chip
Is there a relation between the VIRTUAL_CHANNEL command and defined virtual devices that's not immediately apparent? The demo program shows identical index numbers being passed to multiple VIRTUAL_CHANNEL calls, which has me scratching my head a bit.
Thanks,
- Chip
0
Comments
You have a bunch of virtual devices which get put into an array of virtual devices. Then you have an array of input virtual channels and an array of output virtual channels. The first input virtual channel gets manipulated by commands, channel events, level events etc sent to the first virtual device in the array of virtual devices (in the sample program that's vdvDev[1]). The second input virtual channel is manipulated through vdvDev[2]. etc. IAW the sample program, the elements of InArray[] are mapped to the elements of vdvDev[]. Likewise with the outputs. the first element in OutArray[] is the virtual channel name that gets operated on through vdvDev[1], etc. The loop in the data_event online: handler loads the VIRTUAL_CHANNEL with the virtual channel names from the sound structure GUI.
I've recently done a couple of these using the AMX duet comm module and find that it works pretty much as you would expect. I think there is a little bit of weirdness with terminology with gain, level, etc and I think there might be a bit of oddness with mute and privacy, but you should be able to figure this out easily. Of course, you'll actually need the device to see what I'm talking about.
If it doesn't become apparent how it works, I can edit and post some code from a working job -- let me know. I didn't use any of the provided UI modules or create a UI module.
What's confusing in the demo is that:
for(i=1;i<=LENGTH_ARRAY(InArray);i++) { send_command vdvPolycomSoundStructure,"'VIRTUAL_CHANNEL-',InArray[i][1],',',InArray[i][2],',',itoa(i)" send_command dvPolycomSoundStructureTp,"'^TXT-',itoa(280+i),',0,',InArray[i][1]" } for(i=1;i<=LENGTH_ARRAY(OutArray);i++) { send_command vdvPolycomSoundStructure,"'VIRTUAL_CHANNEL-',OutArray[i][1],',',OutArray[i][2],',',itoa(i)" send_command dvPolycomSoundStructureTp,"'^TXT-',itoa(300+i),',0,',OutArray[i][1]" }Re-uses the same indexes - so the first element from "InArray" and the first element from "OutArray" both get sent to index 1 - which ain't clicking with me. I would think the elements of OutArray would have to be registered using VIRTUAL_CHANNEL starting with the next sequential unused index. I.E., if there were 5 elements in "InArray", the elements of "OutArray" would be registered using indexes 6 and beyond... No?
They also list input and output channel types to be called with VIRTUAL_CHANNEL, but what about the bus channels you can create in SS?
Thanks,
- Chip
I can't remember the last time I used an AMX-provided module for anything, but Soundstructure's 232 protocol doesn't actually have "types" for channels, so I'm not sure why this matters. I would start out trying the submix channel as an Input as far as the AMX module is concerned. Or you could whip up your own "module" for faders and mutes in about 5 minutes, the 232 protocol is a piece of cake.
Yeah, I'm just rusty with this AMX stuff, y'know?
- Chip
Each device port serves two virtual channels, an input virtual channel, as specified in the InArray, and an output virtual channel, as specified in the OutArray. Of course, you don't need to use these arrays at all, you can do anything to get the VIRTUAL_CHANNEL commands, which match either an input or an output to a virtual device port number.
Perhaps the way to look at it: Each port on the virtual device (e.g. 41001:n:0) allows for control of two SoundStructure virtual channels, an input and an output. The number of ports defined must be equal to (or greater) than the maximum number of either virtual input channels or virtual output channels. If the number of virtual input channels exceeds the number of virtual output channels (which seems likely) then there will be virtual device ports which have the unused ability to manipulate output channels.
So, let's say that I have a SS installation which has virtual channels:
'PhoneIn' -- this is the dialer input
'PhoneOut'--this is the dialer output
'LineIn' -- a mono line input
'MicIn' -- single mic
'ProgramAudio'--mono audio output.
how all this stuff gets matrixed within the SS is in the SS and we don't have to worry about it.
You see that we have three input virtual channels and two output virtual channels so we need three ports on the virtual device. eg:
41001:1:0
41001:2:0
41001:3:0
To use the AMX module, you need five send_commands to index the channels to the device ports:
send_command 41001:1:0,"'VIRTUAL_CHANNEL-PhoneIn,PHONEIN,1'"
send_command 41001:1:0,"'VIRTUAL_CHANNEL-LineIn,INPUT,2'"
send_command 41001:1:0,"'VIRTUAL_CHANNEL-MicIn,INPUT,3'"
send_command 41001:1:0,"'VIRTUAL_CHANNEL-PhoneOut,PHONEOUT,1'"
send_command 41001:1:0,"'VIRTUAL_CHANNEL-ProgramAudio,MONO,2'"
Now, both the dialer input and output can be controlled through port 1.
to ramp input dialer volume:
on[41001:1:0,140] for up or on[41001:1:0,141] for down.
to ramp output dialer volume:
on[41001:1:0,24] for up or on[41001:1:0,25] for down.
See? You use the same port for both the input and the output and the module takes care of constructing the appropriate string.
Likewise,
on[41001:2:0,140]
would ramp up the volume for the SS 'LineIn' virtual channel and:
on[41001:2:0,24]
would ramp up the volume for the SS 'ProgramAudio' virtual channel.
Looking at the woefully inadequate documentation on the module you see that each virtual device port allows for the control of input characteristics (gain, mute, etc) and output characteristics. Each virtual device port can have an input mapped to it and an output mapped to it.
As for types, according to the SS documentation, each virtual channel has a virtual channel type and a physical channel type. These types are important, for example, in that you can't send an off hook command to a cr_mic_in channel.
Normally, I don't use the AMX provided modules. In this case, however, I decided to look at the module and see if I could easily modify some dialer code to make it work with the module -- it was pretty easy and when I tried it out, it all worked pretty well. Just a couple little fixes to handle two dialers simultaneously and a bunch of audio stuff for two different rooms. Several physical sound structure devices were hooked together and it isn't even necessary to worry about which physical channels are on which device -- the naming of the virtual channels takes care of all that.
I'm not a fan of the SS control paradigm -- I much prefer the way ClearOne or the Vortex stuff gets handled. This virtual channel thing is like the exciting game without any rules -- can't plan for what the SS designer is going to name the virtual channels.
It's really not that hard to use the module and if you do, you can manipulate a whole lot of stuff quite easily just by turning channels on and off. The SoundStructure protocol is not that hard to figure, but the documentation, in my opinion, sucks.
I program Cre$tron as well as AMX and using this comm module is not that tough as compared to using a Cre$tron supplied module -- just different. I prefer AMX personally, you seem to favor the other and that's ok with me. Part of it is that programming in Cre$tron is like getting stuck in a time warp having to program that god-awful analog computer in EE class back in 1972.
Do you mean the grouping facility that is available in the SS? The group of channels gets assigned a virtual channel name by the SS designer just like any other virtual channel. Then, you can index that just like any other virtual channel and control it through the virtual device port. A mute or unmute string sent to the SS for group of input channels is indistinguishable from one sent to an individual input channel, so just define it in the module like an individual channel. In the installation we did, there were groups of mic channels and the program did just that: muted and unmuted all the mics in the group by strings that the Comm module created and sent to the SS.
I agree that it's not a difficult protocol to figure out, but I know I couldn't do it in five minutes. The Polycom documentation that I have(SoundStructure_Design_Guide_D) has 572 pages of which maybe 120 are dedicated to the RS232 protocol. It is, in my opinion, poorly organized in that in order to figure out how to do a single thing requires paging back and forth through a significant portion of those pages. But yes, it's not hard to figure out how to raise and lower a gain/level/fader or how to control the dialer or how to mute a channel etc -- all the typical things that need to be done to control a conferencing mixer. I guess that what I mean is that in my opinion, the protocol is not hard, but determining what it is is not nearly as easy as it should be.
Looks like I'm going to wind up rolling my own for this project, especially since it seems on the "I" side of things that the module only affects the input gain rather than the fader...
- Chip
It's funny - I started on AMX, but Cre$tron coding (among other aspects) just comes easier to me, so it's become a preference. With their modules, I can drop one into a program and pretty much get it going just by looking at the symbol and dropping some "wires" on it to hook it to other logic. With these AMX modules, I gotta read a whole freakin' manual to figure out what I can do with the module and what commands it features/supports. Then I have to go back and forth between the editor and said manual to keep track of the channels/command syntax.
And oh yeah - if a Cre$tron module falls a little short of what I want it to do - I can edit it.
Apples & oranges I guess!
- Chip
P.S. - I missed out on the analog computer!
That's why I made a comment early on about how the module actually works. I believe that the input "gain" channel manipulation actually results in "fader" changes being sent to the SoundStructure. I was looking for strings to the SS that change "gain" but found strings that changed "fader" values. That's my recollection, anyway.
Writing code from scratch shouldn't be too tough -- return string parsing is pretty straight forward, the presets seem to be easy to implement, etc. For other conferencing mixers that we've used (ClearOne, Biamp, Lectrosonics) I've always found it practical to write my own code and the SS doesn't look any tougher -- just a bit odd.
Ah - I missed that.
I'm going to wait until I can actually get my hands on a mixer and test that before going any further then. If the "gain" functions actually affect the "fader" elements, then I'll be happy.
- Chip
The bad news is that while the module handles ?VOLUME_MIN and MAX no problem, it doesn't handle ?GAIN_MIN / MAX as expected. I can see the module poll the SS and the SS reply - but the module never parses the response into the COMMAND reply message the way VOLUME_MIN does.
- Chip
I wanted responses to GAIN_MIN and GAIN_MAX so that in an instance where the associated fader in the mixer was constrained to a range narrower than -100 to 20db, I could take the fader level reported by the module and scale it before sending it to a bargraph on the touch panel. Since neither of these commands return responses from the module as I mentioned yesterday, I figured I was screwed.
But...
What I found out after poking a bit is that as long as you make those two calls for a given fader, the module scales the level for you automatically!
I'm glad, because that saves me work and keeps my code neater, but I'm PISSED because that feature is documented nowhere. That's a cool feature, and if I had written this module, I sure as hell would have made sure that was pointed out in the docs.
So, I'm at a point where I'm getting the control/results I want by making calls to/from the module and letting it deal with all the coms and parsing - so overall that's a win in my book. I am using the PASSTHRU for ramping channels though - using the native SS inc/dec commands - because using the module channels to ramp is just...too...slow. (Even on a fader constrained to a 40db range)
Could I have spent the same amount of time I took sussing out the module behavior and written my own code from scratch that interacts with the mixer directly? Maybe, or maybe I'd still be tweaking it at this point. Despite crappy documentation, I'm happy with what I've got...
I know a lot of this probably seems like a rant, but I also believe/hope there's some info in there that will be helpful for anyone else that wants to use the comm module and wants to interact with it directly, without using the supplied UI code or sample program...
- Chip
I didn't use the supplied UI modules but did use the sample .axs file, probably because the only way I could figure out how to use the module was to study the sample and then it was easier to cut and paste rather than duplicate it.
The module's levels work both ways, I think. You can send a level to the appropriate virtual device which will cause the proper fader string to be sent to the mixer. Likewise, a fader string to the mixer will update the virtual device level. That's my recollection but I haven't looked at my code for a while.
That's funny, because my experience has always been the exact opposite with AMX's sample programs. It's always been easier for me to read the doc several times and experiment with the COMM module than to reverse-engineer the sample. And don't even get me started on the UI modules!
Thanks again for your input, Hedberg!
- Chip
Just curious...would anyone be willing to pay for a well written module with well written documentation? The reason I mention this is that our modules are provided at no charged to be used as is, although we do provide some level of support.
It is my observation that we have be "conditioned" to expect free software that works well. Some of you indicated that you prefer to develop your own code blocks.
Comments?
There are already a handful of companies that provide device control modules (with support) for sale, so there is obviously a market for it. With regards to AMX and modules, I would think it should be one way or the other - all free or all..."fee". I'd imagine having some of each would just incite people to complain - "why is >that< module free, but this other one costs something?!?" - might not make the idea worthwhile.
Free modules "as-is" are great, but to me, "as-is" includes functionality claimed by the documentation to exist and work. I.E., if a free module is posted and has documented function "xyz" that produces result "abc" - it better damn well do just that, OR it should be fixed without charge and in a timely basis.
I prefer to write my own code, but time allotted for projects doesn't always allow for that. If I find that there isn't already a module available for a piece of gear, and the functionality is fairly complex, (such as for a DSP or VTC unit) I will let those in charge of the project know that it's going to either A) take longer than they've allotted for, or
Now if a programmer takes one of your modules and says "I wish it supported this device's 'pdq' feature in addition to everything else it does", I would absolutely expect AMX to charge for that addition... What to do when the NEXT person comes along asking for the same feature - that's the tricky part.
- Chip
Generally only if open access to the source code was provided and it was written in a language that we were able to alter and recompile. Currently for most dealers that's not Duet.
Source code is often the best documentation as to what a block of code's actually doing and we don't get access to that with AMX modules. We do with modules from the manufacturer beginning with C. While I wouldn't claim that these are well written, dealers have the ability to troubleshoot problems and add additional functionality if required.
We would certainly avoid paying for modules from control system manufacturers when competitors provide their modules free of charge.
If AMX wants to increase the uptake of Duet they should release the source code for their device modules to the dealer community. There would then be a perceived benefit to purchasing Duet licenses for programming staff.
I am yet to have a good experience with an AMX provided module, mainly because I can't see under the hood for diagnostic purposes and fix small issues. As a resulting rule I avoid them like the plague. The worst example of this I have encountered is having had an AMX device in a job and not being able to control it with the AMX provided module. I had to roll my own code from scratch instead of being able to start with the contents of the AMX module. (Even then the device was uncontrollable and had to get swapped out for another manufacturer's product, but that's beside the point in this particular case.)
I can't seem to get it to work with multiple SoundStructures connected on the OBAM. It all works fine from with SS Studio and if I send the Property command with just 16 channels those work fine but I can't get it to work with channels 17+.
If I send the property command with more than 16 channels the module doesn't ever come back alive after the REINIT command.