RS232 matrix audio switcher with volume control
yanbin
Posts: 86
Beside Autopatch, is there any bland make good audio matrix siwtcher with volume control?
0
Comments
Among the ones we have good experience with controlling (some have integral amps or are part of a video switch):
ADA Suite 16 and 8x00 series
Xantech
Sony
Knox
NUVO
Matrix Audio
Niles
Elan
Request
VAUX
ZEKTOR
Biamp (Nexia, Audia)
Clearone (ConvergePro)
MediaMatrix (Nion)
...to name a few.
Check out Avocation. Reasonably priced, easy protocol.
Yeah, but not strong on audio preamp features.
Regarding BCS protocol, it's easy for humans to understand but sucks for machine parsing.
Does anyone see a need for an open easy-to-control and easy-feedback moduleset for Autopatch? Or does one with source available already exist but I didn't find it and duplicated the work?
What's wrong with the AMX Autopatch Duet module? I have been using it without issues for years.
Paul
Didn't Vining post a module for this in modpedia?
I have a comm module that I have been using for years that I would be willing to let you look over. There are definitely some sloppy parts, but it has been working perfectly for our jobs.
It's closed. It (and most AMX modules for that matter) unload the queue very slowly. It's Duet.
I already wrote the module and it works very well. Some of my variable naming is sloppy but search/replace will fix it.
Mainly that it's Duet. If Duet was a worker, having him on the job would be like losing two good men. I don't use Duet modules unless there is no other choice, and in a lot of cases find it easier to write my own NetLinx module than to use Duet. AMX assures me they are aware of the shortcomings of their Duet modules, and are working to fix them, but there are an awful lot of them out there, and it will be a while.
That may be, but I have had no issues with the Autopatch Duet module. Some Duet modules are better than others, so I don't know if you can paint the entire Duet system from how a few buggy modules work. Is there something inherently bad about Duet regardless of how well the module is written? The reason I ask is that I used to hear this a lot about Java programs, but then when you actually look at the code, its no wonder they run so poorly. Once the code is fixed they run great.
I modified a Java program for someone that was taking 45 seconds to start up. After some simple modifications it started in less than 6 seconds. Sometimes I think Java gets a bad rap due to clueless Java programmers rather than the language itself so I am wary of painting all Duet modules as lame without knowing why.
Paul
Java's always had a bad rap because it's been a bit of an intro language for a lot of programmers and early versions of the VM had a few performance issues. In it's current state though its really quite a beautiful language and those performance issues just don't exist (or are at least minimal) now. In fact, for a lot of the work that goes in behind the scenes of a control system it's extremely well suited due to the way it handles heap allocation. No offense to the engineer(s) behind NetLinx but it's a dead language, used by a miniscule number of people and maintained by a handfull of architects. When you look at what you can do now with Duet there is absolutely no reason to still be rolling NetLinx code apart from knowledge constraints. The sooner we can instatiate duet modules without requiring those couple of lines of NetLinx code and do away with the overhead of sending things back to NetLinx land via SNAPI the better.
I'd have to disagree, Netlinx is alive and well and will continue to dominate AMX programming for a very long time.
Netlinx - small fast & ideally suited to IO control tasks
Duet - bloatware, slow to boot, & offers no benefit over Netlinx for control programming.
Don't Agree? Remember you can still load a Netlinx program via Serial, try doing that with Duet! Duet has been around for a long time now and other than AMX Modules I've yet to see anyone use it in place of Netlinx. Maybe it's just my small insular world, but that's how it is!
If you want to program control systems in java, then there is nothing to stop you buying a processor in a box, loading Linux and connecting up any form of IP device / port server you like - what do you need AMX for?
They make quality, reliable and extremely well suited (as you would hope) hardware. They also have a team of people actively working on the device firmware so us lowly programmers implementing these systems don't need to worry about all the low level guff and can just concentrate on creating kick arse user experiences and simple, intuitive, well integrated systems. If something breaks on the hardware side they've got people spread across the globe that know the hardware inside out which can also be swapped out with a replacement without having to source customized components and attempt re-create a standardized config.
As for the 'NetLinx is good enough for control systems' argument I strongly disagree. You only need to look at some of the feature request threads to see I'm not the only one.
Name one (new) installation you've done within the last few years where you've chosen to load the code via serial. That's along the lines of saying "Well yes OS X is a bit better than Classic Mac* but loading it onto my new machine with floppy's just takes to long."
*Alternatively: "Windows 7 is a bit better than DOS..,"
Also, I'm not having a go at you, or anyone else who is not a Duet convert. Everyones situation differs and different tools suite different purposes, it's the outcome that matters.
I can name several, in fact any installation where the AMX system sits on the client network and your called in to carry out an update, or your in the final stages of commissioning and need to make a few changes.
You can either:
1) Goto Clients network security team and request permission to put your laptop on their network. Unlikely
2) Goto Clients Application team and request permission to load NS3 on their desktop. Unlikely
3) Swap all AMX kit to a private LAN to make the changes. Unlikely
4) Bang in a serial cable, download, unplug and go home!
I'd say I go here 2-3 time a month.
Now those busy people actively supporting the firmware don't think Netlinx is dead. Surely in an open source nirvana you could do better??
Why on earth would I want to re-invent the wheel, especially when that wheel already rolls pretty well. Having that mature, and constantly improving underlying system that handles all the low level guff is what makes utilizing an AMX master for the brains of a control system so appealing.
Although it is very true that I have been burnt, repeatedly, by badly written Duet modules, that is not the sum total of my disaffection with them. Just having Duet in a project adds a half-dozen or more files to be loaded, and up to several minutes to the controller start-up time. Ever have a crisis where you needed to load a program remotely over a bad Internet connection? You really appreciate a fast load, and for some reason the Duet support files get loaded every time, whether they got changed or not (why the heck is the SNAPI router loaded every time, for example?). I had a job that was a two hour drive, and an equipment failure forced me to do a remote patch until I could get there and fix it properly ... but the Duet transfer kept failing 2/3 of the way through. If it were pure NetLinx, it would have loaded, because the connection was stable at least that far. I wound up needing to make the run while an irate customer ranted and raved about stuff going haywire while he waited for me to get there. I don't know about you, but remote programming is one of the points I specifically sell ... kind of tough to explain that my selling point was invalid. That kind of thing sticks with you. Ironically, this same job, the two Duet modules that were active broke with the last set of firmware updates, and I had to replace them with NetLinx anyway.
And then there are the times I got burnt.
You specifically mention the Autopatch module. First time I tried to use it, the volume feedback didn't work (this was several years ago, and early version I know for a fact has since been fixed), and it was absolutely required for the job. After fighting with it and getting half-measures passed down to me by whoever it was at AMX handling it at the time, I cobbled my own NetLinx module together, in the customer's sitting room, just to get him running. I've just adjusted it and added to it over the years, and now have no reason to even attempt the Duet one again. My module is far from perfect, and I would never consider distributing it ... but it was better than the one provided by AMX. That really isn't good.
I have been waiting a month now for AMX to update a Sirius tuner module. For some reason, someone felt it was a good idea to force the tuner to channel 184 (the demo station) whenever it reset (which happens every automatic firmware update, or any time the sat connection drops off). Even worse, it would update the feedback to tell you to call Sirius to activate the tuner. And, even if you explicitly changed the station again, it would revert back to 184 within a few minutes. I thought the tuner was losing it's activation. I went through three tuners before I commented out the module and the problem went away (but, of course, so did my tuner control). Sirius doesn't share their protocols anymore, so I have no choice ... I wait, and wait ...
On the evening before my Christmas vacation, at 6PM, sitting in a customer's family room, I had a receiver module fail because of a firmware update. The night before your vacation, with a customer breathing down your back, is not the time to be swapping out modules and replacing all the commands and feedback parameters, but I had no choice. I can't begin to tell you how livid I was.
I can accept there have been mistakes made with Duet, and they are working on them. But I can't have this kind of thing going on either. If I download a module from the manufacturer of the controller, I expect it to work.
Do I think Duet is inherently flawed? No. I think it needs attention to be viable, and though I have been assured otherwise, I don't see it getting that attention. The download-able modules need to be fixed ... I've been told on several occasions they are doing so, but have yet to see a fixed module surface. The performance issues need to be addressed. I can live with longer boot times, but the non-smart file transfer has to go.
[/hyjack]