SVSI programming
champ
Posts: 261
Hi all
Are there any resources for programming SVSI keypads beyond the couple of pages of pdf you get with n-able?
I just don't see how this can be a viable product with no support libraries and would like somebody to prove me wrong.
Here is my experience and opinion:
- I have done huddle style project which controlled a Samsung display, figuring out enough Javascript to handle hex strings with a checksum and create timers for ramping volume that didn't lock up the device took a couple of days.
- I now have another small room project with a BSS and an Epson projector via IP that will need authentication so I am guessing around 4 days to write from scratch.
Both of the above systems should take half a day with established products so it is reasonable to expect the same development time.
To be able to charge half a day for a room like the above I would need a project with at least a dozen identical rooms, although a dozen rooms in other products would then take only 2 hours each so I need to go up to at least 20 identical systems to cover development. If I did deploy over 20 identical systems the client is no doubt going to want advanced functions like resource management and more, I then hit the limitations described in https://www.amxforums.com/forum/tech...si-experiences and https://www.amxforums.com/forum/tech...paradigm-shift. I pretty much need to make this my core market before it really becomes a viable.
I know that Javascript is awesome, there are lots of resources on Javascript but if all I want to do is control a small space competitively then how do I go about that with this product?
Are there any resources for programming SVSI keypads beyond the couple of pages of pdf you get with n-able?
I just don't see how this can be a viable product with no support libraries and would like somebody to prove me wrong.
Here is my experience and opinion:
- I have done huddle style project which controlled a Samsung display, figuring out enough Javascript to handle hex strings with a checksum and create timers for ramping volume that didn't lock up the device took a couple of days.
- I now have another small room project with a BSS and an Epson projector via IP that will need authentication so I am guessing around 4 days to write from scratch.
Both of the above systems should take half a day with established products so it is reasonable to expect the same development time.
To be able to charge half a day for a room like the above I would need a project with at least a dozen identical rooms, although a dozen rooms in other products would then take only 2 hours each so I need to go up to at least 20 identical systems to cover development. If I did deploy over 20 identical systems the client is no doubt going to want advanced functions like resource management and more, I then hit the limitations described in https://www.amxforums.com/forum/tech...si-experiences and https://www.amxforums.com/forum/tech...paradigm-shift. I pretty much need to make this my core market before it really becomes a viable.
I know that Javascript is awesome, there are lots of resources on Javascript but if all I want to do is control a small space competitively then how do I go about that with this product?
0
Comments
So, if I were in your shoes I'd get on the AMX University website and see about taking the course.
As to whether or not it's a viable product - that remains to be seen. I have done several projects with it and cannot say they all went swimmingly. The issues had more to do with things that are not necessarily anything to do with SVSi in and of itself. Mainly it was issues with the client network and some issues with how the system was designed (in many cases by AMX itself) In a vacuum the system works fine. but in the hurly-burley of real world spaces, things like the fact that many times the isloated AV network design is just not a possiblity, huge issues occur due to the bandwidth requirements of the SVSi system and the other things that tend to live in the same space on the network like PBX phone systems and some manufacturing control systems for machinery and so forth. I think there's still a bit of a blind spot there from our side of the fence that our own stubborness is hurting us.
To date I can also say that the best implementations of SVSi have been to keep them as a big AV switch and let Netlinx do the controlling. Creating UI in SVSi is frankly painful and their IDE for writing/developing code feels like I'm working on a Coommodore 64. Whatever your thoughts about Netlinx as a language, the development environment is hands down much better and thought-through.
It is my opinion (and nothing close to fact mind you) that AMX is essentially running both the JS and Netlinx flags up the pole to see who salutes. The loser will fade away. I also should share that we were told in no uncertain terms to learn JS. I honestly have no pony in that race. There's no argument that JS will bring us up to the world of 'real programming' But, I do also think if they try to ram the current awful JS development environment down our throats they're going to lose the last remnant of die-hard AMX evangelists.
In the end most of us are pragmatists. For me using the SVSi development environment is so inefficient that It's hard for me to bill for time. And this is not time programming. It's time working around the clunkiness of the web-based IDE. Debugging is nightmarish. A lot of this might be my inexperience with the coding. But, in many cases it has nothing to do with it.
So, to recap: I'd say take the class.
Agreed - From what I keep hearing from our reps(both for AMX and cr@ptron), the av over IP is where both of them are focusing their efforts. That and the low end 'HDBT-Lite' to capture the lower cost market. The DX/D-MightNotWork world seems to be stalled for the moment while the manufacturers play with new toys.
All in all, I've been pretty impressed with the capabilities of SVSI, but treat it like a video matrix system, not an integrated network device. We sometimes even go as far as to call our network switches for this purpose 'Video Switches' just to mask what it really is to the pesky IT folks
I feel you are exactly correct. Within the scope of SVSi being a networked AV Switch - it is a fantastic product and really good add to the AMX universe. Even the networking issues have much more to do with the design human beings that the design of the product itself. In fact my free advice to completely fix the problems I've seen on 6 projects now. If AMX engineering would simply dedicate and configure one single port on the AV switch as "Uplink to the outside network for control only and internet access for NTS" every problem I've had wouuld go away.
But, the programming side is a whole other banana. It has taken over a decade to really get Netlinx as a language and IDE to the point it is at. I'm not ashamed to say they've done one helluva job. I work in many other IDE's and I consider Netlinx Studio et al to be one of the best implementations hands down. I also realize that getting to that point has not been an easy task.
AMX has long been criticized for the fact that Netlinx is not a 'real' language and it's not keeping up with the the world of IT and so forth - that they needed to 'get with the times' and bring in a real language. I get that and agree with it. I also acknowledge that doing so is no easy task. I can completely understand the siren song of buying a technology that has sorta already done a lot of the heavy lifting of moving everything to a modern language.
My feeling is, however, they're buying into the Sirens a bit too much in not taking into account that, while the new technology 'technically' get's them to their goal, it in and of itself is not actually very good. Yes, developing it on your own is time / resource consuming and all that - and buying a ready-made package seems a better idea. But, building and maintaining a reputation of excellence is also time consuming and resource intensive. The integration firms and engineers out there don't live in a world of devotion to a thing like we do. they think about which solution to use for about 2 seconds. And at the slightest hint of trouble - they bail. There is almost never a chance to get it right the next time. it's usually one project cycle and if it causes any heartburn, they're done.
In all cases - the only integration firms I'm working with that are looking at SVSi for their next round of projects are ones that have only put in SVSi with Netlinx control and also ones that have never tried to use the built-in SVSi controllers. In all cases of the latter, they are sworn off it and bringing it up again only seems to make them angry.
I've been doing some work with Extrons new Scripter, and while I prefer python to netlinx, like you said, AMXs software tools are great, and far ahead of what Extron is currently offering.
And the IDE in SVSi is a joke. It's not an IDE. It's... like a web form? It's terrible.
SVSI switching as a big standalone switcher is great and can be estimated reasonably easily but putting it into an existing client network is a whole different thing that requires exponentially more planning, risk analysis and documentation that should not be attempted unless your company is already in the game of deploying enterprise software on third party client systems.
As for as programming the keypads in JS they must think we are fools with no resources and a crappy IDE that looks like someone at Harman created in his lunch break! You can buy a Raspberry Pi with 7" touch screen and a tidy wall mount for barely a tenth of the price and create the exact same thing in exactly the same development time using a raw text editor (probably better than the IDE) and the developer tools built into most web browsers; then you could pick whatever language you like and leverage the world of open source micro-services.
To one point you made: "a crappy IDE that looks like someone at Harman created in his lunch break!" It so happens I went to take the SVSi just prior to AMX buying them out. I'm sure someone at SVSi knew of the process - but it's safe to say our instructor was not yet aware. The IDE was there at the time. Part of the course was using panel builder. At the time I was the one of two programmers in the room of 14. I was AMX, the other Craptron. It was pretty clear to both us that Panel Builder was not created by someone who's done a whole lot of AV work. It reminded us of what happens when a computer programmer ventures over to the world of AV. They come in thinking they're going to set the AV world on fire and quickly find out it's a very weird and crazy animal that defies any attempt at being 'normalized' (Please don't read what I just said to mean I don't think it should go that way. I dream of a day when it is normalized)
So, all this to say that, to your statement, the scary thing in my mind is that the IDE and your notion of the lack of thought from AMX is even worse in that it came to them ready-made. And it just passed hands from SVSi to us.
I'm sure the thinking (and very logical thinking) at SVSi at the time was something along the lines of, "Heck - we're already in the room - let create a control system to operate all our stuff. and then someone asked the engineers, "While we're controlling all our stuff, can we control other things too?" which the obvious answer was "sure!" But, this control concept was in its infancy development-wise. SVSi basically glommed onto the already existing JS utilization in HTML-5 hoping to leverage that. So, now we're three layers away from the core development.
This kind of thing is one of the big problem I see with moving toward the open-source concept in AV. If you step back and look - Open Source basically makes for easier (dare I say lazier) programming. Why spend the time and trouble figuring out a piece of gear when I can just drag in someone else's code and be done with it in 5 minutes? After doing this enough times your programming chops fro sussing out oddball gear get atrophied.
The world in which Open Source as a concept lives operates with a completely different set of rules. it is run by a large group of engineering types who follow protocols and rules. when you thinik about what we do - what drives our world's innovation are a bunch of manufacturers who pay way more attention to sales and a really short product life-span. There's no interest in conformity or standardization. As a result - AV programmers are always operating in a "wild West: world where we're constantly trying to out-guess the manufacturer. Open Source is just to klunky to keep up since most programmers operating in that realm are not seeking to write new code, they're trying to search for already existing code. If no one's written any - the whole thing breaks down.
I really don't think AV wants open source as much as it says it does. Sorry for the novel. My coffee was extra good this morning.
While I do agree with a lot of your points regarding what?s I believe is a lot of beginners and yes the lazier members of the FOSS community and respect your opinions/input very highly I do have to disagree with thinking the entire community is this way.
As an OS dev that?s spent a lot of time developing with languages like JS, PHP, Lua and Python this is definitely not the approach or mindset I take with projects but sometimes there are existing platforms way more advanced and stable with industry standardization around or at least highly supported, such as NodeJS and Apache, than either you?d be able to develop yourself/in-house or would take way longer to do than the projects time constraints/budget allows for. Netlinx isn?t exempt from this either with the fantastic contributions of many great developers on this forum have gifted the AMX dev community that are used almost religiously such as the Common Libraries, Log Library, etc.
This said I do have to agree 100% regarding SVSi?s programming interface lacking a lot more than it provides considering there exists many fantastic IDEs written in JS such as Atom which could provide a major improvement in developer productivity which someone has even contributed Netlinx plugins for.
My hopes for AMX?s prospects with introducing JS into the Netlinx environment is it will enable higher levels of TP customization and hopefully allow AMX to release more affordable hardware. Irregardless I don?t see why there should be a divide between the AV and CS development communities as I?ve applied lessons and best practices learned from both areas to the other.
Cheers,
DWT
Thanks for that response. I don't think we are really far off of each other's opinions really. I pick on the straight-up programming world a lot. But, anyone who's worked with me also knows I pick on us a lot more. I'm even still amazed that our industry hasn't picked up on versioning yet. I'm slowly getting some people to use Git or SVN or Mercurial - anything other than date-time stamping files/folders.
I have no inside track on this at all. And AMX has really stuck to their "If it's not ready to go in 3 months from now - we're not talking about it at all" policy. but I really didn't get the impression from anyone there either at InfoComm or Developers Conference that there were any plans or notions that Netlinx an JS were gonig to somehow merge into one environment. What I heard was the two things were going to pretty much run in parallel. Plus - my inquireies about things like "is there going to be a method in Netlinx to talk to an SVSi control system was silence. I will say Ian Cragie did send me a really helpful JS code chunk that set up a communication portal on the SVSi side. You still had to write all your own hooks going both ways. But it is a start.
And basing any thoughts on this on past histroy, AMX doesn't have a long track record of pulling these kinds of desperate technologies together. usually one just winds out and the other goes to The Island Of Misfit Toys.
I'm sounding like I'm arguing with you which is not my intention. So, I'll stop. We really are very close.
TBH my excitement of any movement towards any level of JS support is highly personal as JS (especially NodeJS) has become my primary language and have quit using NS entirely for coding as it?s highly awkward to use multiple IDEs. It?s been very interesting as I learned Node, even tho it can be multithreaded, how similar the event loop is with the mindset needed to be highly efficient with Netlinx development.
I'm with you on moving towards JS. My vote is to move the Netlinx processor to it. keep the central controller. So what if in reality it's just running an HTML-5 web page on steroids. Just keep the central controller concept.
JS provides the gateway to libraries where I don't need to write my own JSON parser, MQTT client or digest authentication; however there is no stepping stones for writing decent pro AV systems.
Getting into AMX programming originally was easy because there was a stepping stone platform provided with existing modules to help and this forum which was very active back then, and over time expectations went up as I could provide code developed over years. Now I am being thrown into the JS world where all the online resources are focused on making web pages and there is nothing on making modules for pro AV gear, meanwhile my clients expect me to instantly provide software with the same quality and features in a new language that has taken years to develop in NetLinx, all without allowing (or charging) for the development time.
As for the open source concerns, the professionalism of some of the open source projects available makes most of us all look like monkeys (myself included). Open source has taught me that I was doing so much wrong and was completely ignorant, like proper testing, proper revisioning, GIT work flows in parallel development branches, logging, architecture paradigms like MVC and micro-services, advanced tooling, build management, leveraging standard APIs and more.
Here is an example of the awesomeness of using open source: In a couple of hours using some home automation open source software I recently managed to turn on my CBUS lights using my iPhone via Homekit and turned on my LG TV via WebOS, if you asked me to quote on doing the same in NetLinx I'd guess it would take over a month of labour and would probably straight up say I'm not even interested in trying, so obviously JS compared to NetLinx in the long term is a no brainer. If Harman wants us to do the transition to JS and do it on their platform then they need to provide the path of least resistance which would be resources for controlling pro AV products in JS and a way to reqister an SVSI keypad as an RMS control system!
dsp1 = new bssDevice('192.168.2.233', 1023, 0x7980);
dsp1.connect();
gains[];
vols[];
mutes = [];
matrix = [];
// Source Matrix - bigger matrix; add more button references
inputButtons = ;
outputButtons = ;
for(i = 0; i < inputButtons.length; i++) {
gains.push(new bssDsp(dsp1, '0x3', '0.1.'+(i+12).toString(16).toUpperCase(),, '0x0', BSS_PARAM_GAIN));
gains.subscribe();
vols.push(new bssDsp(dsp1, '0x3', '0.1.'+(i+2).toString(16).toUpperCase(),, '0x0', BSS_PARAM_GAIN));
vols.subscribe('%');
mutes.push(new bssDsp(dsp1, 0x3, '0.1.'+(i+2).toString(16).toUpperCase(), 0x1, BSS_PARAM_TOGGLE));
mutes.subscribe();
matrix.push(new bssDsp(dsp1, 0x3, '0.1.0', i, BSS_PARAM_SELECTOR));
matrix.subscribe();
}
// Inputs
for (i = 0; i < inputButtons.length; i++) {
get(inputButtons).core.states[0].script = 'setSelectedInput(0); updateSelectedInput();';
get(inputButtons).core.states[1].script = 'setSelectedInput('+(i+1)+'); updateSelectedInput();';
}
var selectedInput = 0;
// Need these because of var selectedInput
setSelectedInput = function (input) {
selectedInput = input;
};
getSelectedInput = function () {
return selectedInput;
};
updateSelectedInput = function () {
for(i = 0; i < inputButtons.length; i++) {
get(inputButtons).setState(2-(selectedInput === i+1));
}
};
updateSelectedInput();
// Outputs
for (i = 0; i < outputButtons.length; i++) {
get(outputButtons).core.states[0].script = 'sourcematrix.set(getSelectedInput());setSelectedInput(0);updateSelectedInput();setTimeout(function() {setOutputButtonText('+i+');}, 100);';
get(outputButtons).core.conditional = 'setOutputButtonText('+i+')';
}
setOutputButtonText = function (out) {
get(outputButtons[out]).setText(sourcematrix[out].status.value);
};
Hey look - no f'n button script code!
... And yes, that's referencing a real (functioning) BSS Audio JS project :-)
This is how I even have my own home setup since I use Rock64?s as my media streamers on every TV anyways which are fed from my local server that has the tuner cards, coordinates streaming platforms, manages bandwidth allocation and network monitoring/management so I just threw another VM on it with a logging DB and my analytics platform which I started building before RMS was what it is today.
I was working on something similar for my job at the time doing energy management and building automation systems so my personal platform started as my personal testbed to allow me to work on my off time since our EMS platforms where from almost every manufacturer on the market so I wasn?t about to scrap it when our office was outsourced and the project scrapped!
Nowadays I?ve worked to expand the system to integrate with a lot of the other platforms/services my clients uselike Planning Center Online, Slack, etc which has been quite nice to be able to know who?s doing what/when so the system can automatically communicate to the correct person over their preferred platform and automatically adjust to accommodate problems for example limiting power consumption of the stage lights and projectors if the HVAC system going down and have even gone as far as tying physical access control into network access control so your RFID access card has to be scanned at the entry doors to enable network access.
All of that and a lot more I haven?t mentioned was donewith NodeJS so there is definitely a lot of potential if the JS ecosystem will be fully supported natively on the hardware with an easier process to communicate it with Netlinx code than Duet modules currently has.
Not saying JS is the perfect choice by any means but allowing it to talk/work with Netlinx code will be a huge step forward to making projects a lot faster on the development side and enable the systems to be used a lot easier in a lot more applications than currently as it took me forever to get Netlinx to interface and share data with a couple different PLCs without just going the lazy analog IO route for statuses.
I just really hope Samsung?s existing use and support of JS has been pushed into HARMAN as it is a great opportunity to advance the AMX presence in multiple markets/verticals like resi so we can take advantages of JS frameworks like Cordova and Electron to further advance our clients systems towards truly connected and immersive experiences.
OK enough preaching because my feet hurt from standing on this soapbox!
DWT
I so agree with your statement on HTML5 because it almost feels like HTML runs the panels now plus there is so much that can be done within HTML5 ALONE so being able to tightly tie HTML into Netlinx using another crazy versatile language to extend both to places they can?t easily reach would be the bees knees especially for resi work where people expect mobile access.
Sorry, I?m a huge fan of JS due to the versatility and ability to run on almost everything front to backend! Again, not saying it?s a perfect language as there are a lot of great options out there but few that can run so easily across such a wide array of devices.
Did you write the bssDevice and bssDsp modules yourself?
The BSS protocol is difficult, not having a delimter or set length, requiring a length and checksum byte, and every time there should be a byte equal to $02,$03,$06 or $0F then replace it with a "$1B,$8x". You also need to convert log to linear volume levels to make ramping smooth.
The core problem is not that I can't do the programming, it is that without having sufficient resources the labour cost is too high to justify for any less than 20 or so identical systems.
While JS is the right decision, if Harman wants these products to sell then they need to supply resources that will make the development costs cheaper than developing our own solutions on any old device with a web server.
I knew you couldn?t resist this thread Ian.
Wrote it all by my lonesome - took about a week or so over the holidays. Still finessing it but well enough beyond a minimally viable amount to be deployed. Its the 4th or 5th platform I have written a BSS driver on... that API is a piece of work.
Also using its development to explore some of the deeper reaches of what JS can do on the Panel Builder platform as well as how to minimize the amount of work done within that lovely IDE.
:wave :-)