The client always seems to wants something the module doesn't offer, or they won't work in a large TP system. You know my feeling on modules, open up the source code and I'll use LOTS of them. It would save me so much time building my own - like so many of us do.
The number one reason I started using Request/Kaleidescape is because they have an open source module which makes it easier to start from when building my own module. I think other companies have to realize there is no Holy Grail inside their modules, just code. They make life easier for us, we in turn recommend and sell their product.
I am worried about Joe programmer...
I agree to a point. I am not sure that completely open source on the modules would be the best thing. I know you and (probably) most of the people on this forum either have the ability to make the changes they need, or at least understand they don't have the ability and avoid making changes. (They might even learn some things about writing code). I am worried about Joe programmer that was thrown into this game by an ambitious owner and he starts making "just a couple changes that couldn't possibly do harm". Then all of a sudden the module is just slightly screwed up and he calls into tech support because the module isn't working right. They ask if he has made any changes and he assures them he hasn't because his changes absolutely could not have messed anything up.
The end results will likely be higher product costs due to increased tech support calls, longer hold times and problem resolution with tech support, and the first trouble shooting step for every module problem will be to download the latest module from the AMX site and run it by itself. (But, I'm a bit of a pessimist )
The other reason that I doubt you will see a lot of open source modules is because the manufacturers of the various devices often times have a nondisclosure on their protocols. Obviously, the most common devices that require this are security related. I doubt you will get those manufacturers to abandon this practice just because I am guessing they don't want ever high tech burglar to have easy access to the protocols in place. (This would make it fairly easy to know how to at least monitor security panel status given access to the comm network) (I'm also a bit paranoid )
I would like to see AMX possibly release module source to highly qualified programmers as long as the nondisclosure thing isn't a problem. The question is how to qualify people. Maybe leave it to the reps, maybe make a separate test, maybe have a lottery
As for modules I avoid, the first one would have to be the Autopatch module. I am fairly sure that the module works to some degree, but it did not offer me anything the last time I tried it other than letting me use a slightly different protocol that the native protocol of the autopatch units. I have since written my own module that handles what I need.
And this leads to another more 'gestalt' comment. I personally think the whole 'AMX writing modules' approach has done damage to AMX as a solution in general.
It promotes a lot of laziness on the part of in-the-field programmers. I don't know how many times I've seen on this forum a new user poke in and and ask if anyone here has writte code for a such-and-so box, and if they wouldn't mind sending it to them. I'd be, quite frankly,embarrased to do this.
I have no problem sharing code and do so quite often here. However, the practice of this is to share ideas and new ways of getting from point A to B. It is not supposed to be a <insert Big-Box store name> where you can go to isle 34 and grab what you need to controll a home theater. C'mon, do we really associate Big Box store with quality?
Autopatch - (this is one I honestly don't know why you'd write a module for it. It's a very simple audio matrix switcher. I just do it in code as an include)
I still don't buy the "we can't have open source modules because you'll mess them up and not tell us about them" excuse.
Problem with doing things this way is what do you do if you have more than one switcher? Now your include needs a lot of variable name modifications to take care of that. If you had used a module then one more line of code takes care of it.
I am surprised so many people are intent on writing their own modules when there are so many out there already written. I love it when I have a prewritten module to use as then I can spend more time on the user experience rather than dealing with the low level stuff.
As for the open source model, there is no reason that it can't exist alongside what AMX does, in fact I think it would be better if they weren't involved. Got a module that you want to share? Post it here and we will critique it and hopefully make it better.http://sourceforge.net/projects/netlinx-modules/
I do use modules and write them for myself too when I want them.
I don't see how it's any more difficult or complicated with an include file and functions as opposed to modules. In either case, you have to have some logic to choose the target switcher and a corresponding target device variable. If it takes a bit more time to code with an include file (and I'm not convinced), this time would be more than recovered as a result of quicker file transfers -- particularly with respect to Duet modules.
I don't think I am following. With an include, all variable names have the same scope. So if you are using a variable named currentOutput and you have 3 of the same switchers, you now have to modify things so that you have currentOutput1 , currentOutput2, currentOutput3. With a module you just declare another module and that variable is local to the module so no scope issues crop up.
What file transfers are you referring to that would be quicker?
I don't see why you would need multiple instances of the same variable. Only one switcher gets switched at a time. Also, arrays are your friend, if you do need multiple instances.
File transfers? Sending the compiled files to the master. Watching a program with a Duet module load is a painful experience, even at 100T.
It doesn't seem at all obvious to me that using multiple instances of modules is significantly more efficient (if at all) than using a well designed include file.
You can't learn or improve, unless you can SEE what they are doing.
Like President Reagan once said "Mr. Gorbachev, unlock the modules"