AMX Developer's Conference 2017 - Report
ericmedley
Posts: 4,177
Just got back from Dallas and DevCon 17. I'm pretty tired and I'm sure my report will reflect that.
SVSi JavaScript class
I did also go to the 2/3 day newly minted SVSi JavaScript class taught and developed by Caroline Bjorkquist and Ian Craigie. (our vary own I_caragie here on the forum) The class was mainly populated with AMX VIPs. How the class went probably had a lot to do with how familiar to JS you happen to be. If you were familiar with it the general feeling was excitement at all the things that will be possible with a more 'off-the-shelf' modern language. But, if you've only done Netlinx programming, it might be quite a paradigm shift. I'll touch on that more later. Suffice it to say that Caroline and Ian have cobbled together a really good class and I do encourage everyone to take it.
DevCon 17 started on Thursday and went through mid Friday. This years conference was a bit more inward gazing - focusing a lot on very VIP-centric issues and not really what I'd consider more general things AMX. For that reason I'll not really speak much about it. Not that it's all secret and whatnot. It's just stuff that most folks on the forum won't find very usedful IMHO.
Samsung/Harman/AMX
We got to see a glimpse of the future of Harman/AMX under Samsung. The feeling (though not confirmed data) is that not a whole lot will change as Samsung will probably not get overly involved in the minutia of what AMX does. The continued alignment of AMX with Harnam continues as it moves pieces and parts of the various technologies around to bolster various technologies inside other brands.You will see more products in the other verticals featuring something akin to a "power by <brand>" sticker on it.
AMX Software/Hardware Engineering
We got to hear from the various equipment and software engineering department heads. However, this year Chris decided to make sure they were all in the same room at the same time, thus eliminating the often used response, "you have to ask that question to <inert department> ' question only to have the same question come careening back from the other department. The end result is the product development manager did most the talking. The long asked question about TP4 and TP5 being able to select multiple pages/popups at once and deleting/copying/etc... was repeated with the same response of "we can't do it. It's highly electrical and dangerous to explain why..." response. However, there appears to be a comprise that might show up. They can apparently create a 'wizard-like' window that can accomplish the same thing. The feeling was that if we had the ability to select more than one page/popup and delete/copy/etc them en masse' that would be acceptable. So, we shall see if this happens.
SVSi Native Netlinx implimentation:
As many of us know SVSi's being brought into Native Netlinx was a bit half-baked. There are some things that can be done native Netlinx but there are also some very key things left out. (such as active status feedback. The limited Netlinx Native command/controls are essentially akin to IR commands in that you can only do a very select few things and there is no feedback.
So, for those of us who've dealt with SVSi prior to coming on board with AMX, we know that you can get a bevvy of information from teh box via it's serial port and API. This does work still by sending/receiving strings via the Netlinx Device number. So, SEND_COMMQAND is for the Netlinx Native stuff. SEND_STRING is for the old SVSi API. So, if you have older code utilizing the SVSi API, most, if not all, of that code will work just fine. Now, most of this same crowd will also know that the SVSi did not volunteer asyncrhronous info. You had to poll and/or ask for it.
For those of you disappointed in this news - wait one second. Ian Craigie chimed in with some other good news. There has been for a short while the ability to set up the SVSi box via its web interface in such a way to indeed volunteer asyncronous status through what is essentially a hard-coded subscribe method. You essentially go in and tell the box which parameters you want it to be chatty about and it will tattle-tale on whatever your ask it to do - hence making it totally two-way asyncronous without all the messy polling.
New BSS AMX Module
We got to hear a presentation about the new AMX Module for the BSS BLU-xyz. I have much to say on this as I've been embroiled in a project where this module sits front-and-center. That has yet to be resolved and I will await that resolution to report (if needed) So, with that in mind, the public details are that AMX has released new modules to control the various BSS devices presently being pushed out by AMX Engineering and the sales engineers. Of note to all us programmers is that while the modules are DUET like they are not necessarily following SNAPI and are not probably what you're used to in a DUET module. Some of you might be cheering right now. It would be my advice to hold your applause until you've had a chance to play with them.
I'm not trying to be coy here. But, suffice it to say that you'll be learning how to do marshalling on commands you send soon. These are not your father's old AMX send_commands. As I've said, I'm not trying to make any issues with this right now but I did post my own moudle for the BSS (sans the BLU-102 POTS phone dialer) in the Mopedia. (Just sayin...) AND Thanks to our very own John Michener at Rocking M I'll have the POTS dailer soon. he's graciously loaning me a BLU-102 for testing for which he'll receive my undying love and a free beer.
But, the AMX modules are there and you all should download them and check them out. We can certainly use all the help we can with that BSS API.
Future of our beloved Mother Tongue - NETLINX
Some of the more 30,000 ft discussion: These are more-or-less paraphrased official statement. If Chris wants to correct me - I'm sure he will.
1) (and this is very strongly advised) It would be a really good idea to learn JavaScript. it will soon become very important to do so.
2) Netlinx is not going away any time soon.
Details beyond this were pretty scarce (perhaps there needed to be no more details)
The following statements are my personal thoughts on this and are to be taken as such. This is not official in any way. Consider the source when contemplating them.
With the coming of SVSi and the fact that we've all been kinda looking around at our industry - realizing we're working on a language that is coming up close to being 20 years old; I've been wondering what the future of our IDE (Netlinx Studio/TP4/5/IREdit/etc...) There has been much discussion on this both in the programmers/engineers party as well as the dealer/sales engineers party. In short - who long can we protect our phoney-baloney jobs? Personally, I was trying to be patient and await the official announcemtn one way or another promised at this years DevCon17.
My initial reaction to the above official paraphrases was confusion. Personally, I had attended the SVSi offered class just prior to AMX snatching them up. (it was underway while I was in Huntsville) And now I've taken the official AMX version of the class. For those of you who arent' aware of what all SVSi does: here's the deal. A very short and oversimplified way of saying this is you don't need a control system when you pop in an SVSi system. It's entirely possible to control almost anything we currently do with AXM from SVSi and it also has tools to create really good user interfaces. (I know the current implementation is pretty awful - but remember: it's HTML5 and we know that has tons of potential we currently don't have in standard AMX TPs.)
Now, before you all do a spit-take at that last paragraph, I know - I know... My statement is way over simplified and I'm not in any way saying it's a replacement for NX masters. nor is it even close to the same thing. They are radically different concepts and approaches to doing control. A very short description might be AMX is based upon centralized control. SVSi is more of an edge controlled environment. (essentially - the UI is the processor)
I do not wish to go down the rabbit hole on this whole discussion. Trust me - it's would take many cold nights and a lot of beer to truly plumb the depths of this whole discussion.
For this discussion I would, however, like to comment on what I see as an odd apparent paradox of the 2 official paraphrases. ("you'd better learn JS" and "Netlinx ain't going away") It is my feeling that what we're going to see in the next several cycles is a bit of cage match between the two platforms. I think we're going to see how the two things perform and which will win out. I honestly don't think the two things can coexist for long as they are really radically different approaches to creating a control system. Netlinx is very simple and powerful (inside it's little world) and does enough to get the job done on 90 percent of all the things we do. It's pretty light-weight and easy to learn. It's downside is it's becoming a dead language that can move no further. It can't keep up with current web-based or SQL things where encryption comes into play and a whole host of other issues where we have to shake our heads at the client and say, "Netlinx can't do that"
JS is a lot more modern and has a whole host of uses that are much more mainstream. It gives us access to so much that was out of reach as well as tons of "Open Source-iness" that has been clamored for for a long time even on this forum. I could see many more real computer programmer types coming over to the odd world of AV programming. I don't know if that's a good thing or not. But, it's something we've just not seen much of.
I'm feeling like the official word is we're going to keep feeding both these piggies and see which one grows up to be the big hog. It's my opinion that we will see Netlinx fade away over a few to several years and it will become the haunt of some of independents who make a living doing legacy coding. (heck - I still have 3 clients who have Accent systems running and viable.)
That's my report. If you don't like it - I have others.
Thanks to Chris Backus and everyone at AMX for yet another great meeting! I know he was worried how it would all come off and if he was keeping it vital and alive. Trust me, my friend. It was indeed! great work!
E
SVSi JavaScript class
I did also go to the 2/3 day newly minted SVSi JavaScript class taught and developed by Caroline Bjorkquist and Ian Craigie. (our vary own I_caragie here on the forum) The class was mainly populated with AMX VIPs. How the class went probably had a lot to do with how familiar to JS you happen to be. If you were familiar with it the general feeling was excitement at all the things that will be possible with a more 'off-the-shelf' modern language. But, if you've only done Netlinx programming, it might be quite a paradigm shift. I'll touch on that more later. Suffice it to say that Caroline and Ian have cobbled together a really good class and I do encourage everyone to take it.
DevCon 17 started on Thursday and went through mid Friday. This years conference was a bit more inward gazing - focusing a lot on very VIP-centric issues and not really what I'd consider more general things AMX. For that reason I'll not really speak much about it. Not that it's all secret and whatnot. It's just stuff that most folks on the forum won't find very usedful IMHO.
Samsung/Harman/AMX
We got to see a glimpse of the future of Harman/AMX under Samsung. The feeling (though not confirmed data) is that not a whole lot will change as Samsung will probably not get overly involved in the minutia of what AMX does. The continued alignment of AMX with Harnam continues as it moves pieces and parts of the various technologies around to bolster various technologies inside other brands.You will see more products in the other verticals featuring something akin to a "power by <brand>" sticker on it.
AMX Software/Hardware Engineering
We got to hear from the various equipment and software engineering department heads. However, this year Chris decided to make sure they were all in the same room at the same time, thus eliminating the often used response, "you have to ask that question to <inert department> ' question only to have the same question come careening back from the other department. The end result is the product development manager did most the talking. The long asked question about TP4 and TP5 being able to select multiple pages/popups at once and deleting/copying/etc... was repeated with the same response of "we can't do it. It's highly electrical and dangerous to explain why..." response. However, there appears to be a comprise that might show up. They can apparently create a 'wizard-like' window that can accomplish the same thing. The feeling was that if we had the ability to select more than one page/popup and delete/copy/etc them en masse' that would be acceptable. So, we shall see if this happens.
SVSi Native Netlinx implimentation:
As many of us know SVSi's being brought into Native Netlinx was a bit half-baked. There are some things that can be done native Netlinx but there are also some very key things left out. (such as active status feedback. The limited Netlinx Native command/controls are essentially akin to IR commands in that you can only do a very select few things and there is no feedback.
So, for those of us who've dealt with SVSi prior to coming on board with AMX, we know that you can get a bevvy of information from teh box via it's serial port and API. This does work still by sending/receiving strings via the Netlinx Device number. So, SEND_COMMQAND is for the Netlinx Native stuff. SEND_STRING is for the old SVSi API. So, if you have older code utilizing the SVSi API, most, if not all, of that code will work just fine. Now, most of this same crowd will also know that the SVSi did not volunteer asyncrhronous info. You had to poll and/or ask for it.
For those of you disappointed in this news - wait one second. Ian Craigie chimed in with some other good news. There has been for a short while the ability to set up the SVSi box via its web interface in such a way to indeed volunteer asyncronous status through what is essentially a hard-coded subscribe method. You essentially go in and tell the box which parameters you want it to be chatty about and it will tattle-tale on whatever your ask it to do - hence making it totally two-way asyncronous without all the messy polling.
New BSS AMX Module
We got to hear a presentation about the new AMX Module for the BSS BLU-xyz. I have much to say on this as I've been embroiled in a project where this module sits front-and-center. That has yet to be resolved and I will await that resolution to report (if needed) So, with that in mind, the public details are that AMX has released new modules to control the various BSS devices presently being pushed out by AMX Engineering and the sales engineers. Of note to all us programmers is that while the modules are DUET like they are not necessarily following SNAPI and are not probably what you're used to in a DUET module. Some of you might be cheering right now. It would be my advice to hold your applause until you've had a chance to play with them.
I'm not trying to be coy here. But, suffice it to say that you'll be learning how to do marshalling on commands you send soon. These are not your father's old AMX send_commands. As I've said, I'm not trying to make any issues with this right now but I did post my own moudle for the BSS (sans the BLU-102 POTS phone dialer) in the Mopedia. (Just sayin...) AND Thanks to our very own John Michener at Rocking M I'll have the POTS dailer soon. he's graciously loaning me a BLU-102 for testing for which he'll receive my undying love and a free beer.
But, the AMX modules are there and you all should download them and check them out. We can certainly use all the help we can with that BSS API.
Future of our beloved Mother Tongue - NETLINX
Some of the more 30,000 ft discussion: These are more-or-less paraphrased official statement. If Chris wants to correct me - I'm sure he will.
1) (and this is very strongly advised) It would be a really good idea to learn JavaScript. it will soon become very important to do so.
2) Netlinx is not going away any time soon.
Details beyond this were pretty scarce (perhaps there needed to be no more details)
The following statements are my personal thoughts on this and are to be taken as such. This is not official in any way. Consider the source when contemplating them.
With the coming of SVSi and the fact that we've all been kinda looking around at our industry - realizing we're working on a language that is coming up close to being 20 years old; I've been wondering what the future of our IDE (Netlinx Studio/TP4/5/IREdit/etc...) There has been much discussion on this both in the programmers/engineers party as well as the dealer/sales engineers party. In short - who long can we protect our phoney-baloney jobs? Personally, I was trying to be patient and await the official announcemtn one way or another promised at this years DevCon17.
My initial reaction to the above official paraphrases was confusion. Personally, I had attended the SVSi offered class just prior to AMX snatching them up. (it was underway while I was in Huntsville) And now I've taken the official AMX version of the class. For those of you who arent' aware of what all SVSi does: here's the deal. A very short and oversimplified way of saying this is you don't need a control system when you pop in an SVSi system. It's entirely possible to control almost anything we currently do with AXM from SVSi and it also has tools to create really good user interfaces. (I know the current implementation is pretty awful - but remember: it's HTML5 and we know that has tons of potential we currently don't have in standard AMX TPs.)
Now, before you all do a spit-take at that last paragraph, I know - I know... My statement is way over simplified and I'm not in any way saying it's a replacement for NX masters. nor is it even close to the same thing. They are radically different concepts and approaches to doing control. A very short description might be AMX is based upon centralized control. SVSi is more of an edge controlled environment. (essentially - the UI is the processor)
I do not wish to go down the rabbit hole on this whole discussion. Trust me - it's would take many cold nights and a lot of beer to truly plumb the depths of this whole discussion.
For this discussion I would, however, like to comment on what I see as an odd apparent paradox of the 2 official paraphrases. ("you'd better learn JS" and "Netlinx ain't going away") It is my feeling that what we're going to see in the next several cycles is a bit of cage match between the two platforms. I think we're going to see how the two things perform and which will win out. I honestly don't think the two things can coexist for long as they are really radically different approaches to creating a control system. Netlinx is very simple and powerful (inside it's little world) and does enough to get the job done on 90 percent of all the things we do. It's pretty light-weight and easy to learn. It's downside is it's becoming a dead language that can move no further. It can't keep up with current web-based or SQL things where encryption comes into play and a whole host of other issues where we have to shake our heads at the client and say, "Netlinx can't do that"
JS is a lot more modern and has a whole host of uses that are much more mainstream. It gives us access to so much that was out of reach as well as tons of "Open Source-iness" that has been clamored for for a long time even on this forum. I could see many more real computer programmer types coming over to the odd world of AV programming. I don't know if that's a good thing or not. But, it's something we've just not seen much of.
I'm feeling like the official word is we're going to keep feeding both these piggies and see which one grows up to be the big hog. It's my opinion that we will see Netlinx fade away over a few to several years and it will become the haunt of some of independents who make a living doing legacy coding. (heck - I still have 3 clients who have Accent systems running and viable.)
That's my report. If you don't like it - I have others.
Thanks to Chris Backus and everyone at AMX for yet another great meeting! I know he was worried how it would all come off and if he was keeping it vital and alive. Trust me, my friend. It was indeed! great work!
E
0
Comments
There is some discussion along those lines. I think the name of the event kinda takes you down a wrong path. We really do spend most our time on things very specific to the world of VIPs. We are not dealers, nor are we integrators. So, a lot of the discussion tends to be focused on things that would probably not really excite most folks. But, obviously, the exposure to new tech and programming theory would and that is what everyone thinks should be opened up. I've thought we should do the event over an extra day where we start off with VIP-centric stuff and then the last day bring in programmers-at-large and talk about the fun programmer wonk stuff. We could have some fun and we wouldn't have to share the secret hand shake. (Smiley Face)
My personal opinion is like yours. I was trying to stay neutral in my report. I don't hate Netlinx at all. But, I do think we need to move on.
Paul
I think the progression makes more sense in an historic sense than a logical one. They tried to move to JAVA but ran into all sorts of challenges bringing that about; things like licensing, having to run out-of-date versions, the fact that while manufacturers had JAVA programmers, they did not have AV programmers, etc... And then the whole JS framework more-or-less dropped in their laps through the acquisition of SVSi. But, I agree that it doesn't make a lot of sense from the programming viewpoint.
There was considerable discussion on what you bring up too. Some of us who do programming in the Govt./Military Top Secret spaces brought up that not being able to compile down to a binary might be a deal breaker in some cases. One issue is that we cannot put any text in our source code that shows any IP Addresses. (Think IP_ADDRESSS='123.123.123.123' There are many ways around this such as requiring the user to enter in IP addresses manually and storing them in persistent vars. I wrote my own method of creating an encrypted file to store sensitive data. But, If I cannot hid my encryption method - what good is that?
Since the official word is that Netlinx is not dead and not going anywhere soon, the discussion is academic for the moment. But, I alsoo know better than to rely on that totally.
E
This answer is my opinion and not official. I feel like the distinction is not meant to be one of capability per se. I agree wholeheartedly with your feelings. I know that all the VIPs are really good and experienced programmers. They don't just let any old person in. But, the distinction has much more to do with how we interact with businesses and how we're set up as companies. One might think there's some special sauce to being a VIP. But, it's really more to do with organization. Firstly, we do not act like dealers nor are we allowed to in any way. I cannot sell anything but my time. Quite often end users contact us wanting a side door to buying AMX gear which we must refuse. Also, we're not supposed to pretend we're integrators. I can't contract out a bunch of labor and make money selling a system to anyone. I do offer project management services if the dealer needs that help. But, most don't.
We tend to offer mainly programming only as well as commissioning help. My clientele tends to be one of the following: A new AMX dealer trying to get their feet wet on AMX. They have newly trained staff and programmers who just need a guiding hand. A programmer attached to a dealer wouldn't want to do this as they already have a gig and no time for such tings.
Or perhaps the dealer is established, but new to some area of business. (Like they just got a new government/military contract and are not versed in all the regulations and so forth. A lot of us also may have specific security clearance that they won't be able to get right away.
Or the client might be needing some really tweaky high-end skill that they won't find in the wild so-to-speak. I do a lot of military stuff due to my experience with those networks and work environments. Same with Enterprise level stuff. A AV firm might not be able to staff up with those kinds of people and keep them busy. They only have one or two jobs and just need temp help.
We also can work for AMX via an NDA agreement on certain things where a dealer wouldn't be able to do so.
It's not that we're any better at programming. We're just set up to do things a little differently to fill a gap that a dealer cannot do.
Does that make sense?
While I prefer other languages to Javascript, I also understand wanting to use a single language rather then using something like python on the backend and still having to use javascript on the front end.
Matt, this event started as an exclusive event to members of AMX VIP. After hosting that event for several years, we sought ways to expand the event to include other top members of the programming community. Short of opening it up to anyone with an active certification, we started with holders of the AMX Solutions Master rating. For the last two years, those individuals have been invited and several have attended.
I agree! Regulars to this forum tend to fall more along the lines of full-time daily coders and are very capable AV programmers. Members of AMX VIP are part of a group that I head up. I started the event as a way of driving value to members of that program. Now that I am also responsible for training, I wanted to expand the event and drive value towards achieving the ASM. Make sense?