In TPD4 - how about having a "group" function? This way, if we have a keypad (10 buttons), that we want to move as a group, we don't need to lasso them; also this could allow us to align two groups (i.e. transport group centered horizontally with the keypad group.)
This would also be helpful when layering buttons, we could just move the entire grouped button.
Think Adobe Fireworks' groups where you can have groups withing groups . . . CTRL+G = group, CTRL+SHIFT+G = ungroup top layer (continue to ungroup lower layers.)
I'd like a more scalable/flexable mechanism for firmware transfers. I'm mentioning it here since NLS is currently the only way of managing firmware. My following suggestions may be better implemented in something like RMS (which I guess counts as an AMX tool), or a new stand-alone firmware tool, so here goes anyway:
1) We retain a local/server-side firmware repository where our preferred versions of firmware sit for all our hardware. The repository should allow for multiple versions, so we can roll back in those few rare instances where we may need to do so, and for each product type we can select one version to be the "preferred version". (This allows us to test newer versions before rolling it out in bulk.)
2) We build a list of comm settings for all our masters. (Already done in RMS.)
3) A "firmware-meister/manager" (FM) program audits each system for firmware versions for all masters/devices. (Already done in RMS, to some extent.)
4) The FM program then highlights all whose version does not match our "preferred version" from our repository. Older versions are marked as red, newer versions are marked as yellow, matching versions are marked as green. (Perhaps some form of RMS-like exception highlighting would be good, where "okay" results are collapsed.)
5) For each master/device we can then specify what version we want (via a dropdown populated with the available versions in our repository), and a time/date when to push the firmware out to the master/device. The FM then pushes out the firmware at the specified time/date. It the solution was a standalone app, we would have to leave it running 24/7. RMS is already doing this anyway.
I don't ask for much, do I! We could upload the firmware into RMS via the web interface, where it manages it's own repo of versions. (You could even supply an easy "update repo" button where RMS automatically pulls down the latest versions from the AMX site!) Given that RMS has/had it's own internal scheduling engine, that could be reused to initiate the FW updates. My idea is mostly inspired by the Tandberg Management Suite where (from what I saw several years ago) it can also control firmware for all the various video conference endpoints. Another good one to look at is the AXIS Camera Management app. It can push firmware out either in parallel, or sequentially. It also gives you options of what to do if a failure occurs (skip to next, halt, etc.) It also allows you to build config templates and push them out to which ever cameras you like. This could be useful to manage, say, Duet Memory Allocations where you want to ensure that the memory in the older units are not fully allocated to Duet, which results in you non-duet program not launching.
Trying to keep more than 20 masters current with the same firmware version becomes unwieldy, particularly when you work the same hours that the systems are in use. (Many of our classrooms are used from 8am to 10pm.) It becomes even more fun when you have a mix of 32Mb & 64Mb NI-700s (which have different firmware for each type), NI-3000s, NI-2100s and NI-3100s, CV7s, 700vi, MVP8400, and the occasional Vol3. Thankfully the firmware update mechanism is smart enough to know what firmware package it should be using, so this could be leveraged to select the correct .kit. It sounds like the new R4 updates are very order-specific. A managed mechanism could check to ensure that the appropriate order it followed, where such firmware dependencies exits.
I know my suggestion may cause discussion along the lines of "If it ain't broke, don't fix it." My approach is that if ever I need to contact tech support, their first question is often "Are you running the latest firmware? If not, update it, since your issue may already be addressed." When running large quantities of masters and AMX devices it helps to maintain the same firmware version across the entire fleet. This reduces the possible variations from room to room, which makes fault-finding much easier.
This function might already exist but tonight I ran into a TP4 design where I wanted to swap the position of 2 buttons with each other. A swap button would of been handy and I'm still waiting for that 'group' button so I can tie 2 or more buttons together as 1.
I'd like a more scalable/flexable mechanism for firmware transfers. I'm mentioning it here since NLS is currently the only way of managing firmware. My following suggestions may be better implemented in something like RMS (which I guess counts as an AMX tool), or a new stand-alone firmware tool, so here goes anyway:
1) We retain a local/server-side firmware repository where our preferred versions of firmware sit for all our hardware. The repository should allow for multiple versions, so we can roll back in those few rare instances where we may need to do so, and for each product type we can select one version to be the "preferred version". (This allows us to test newer versions before rolling it out in bulk.)
2) We build a list of comm settings for all our masters. (Already done in RMS.)
3) A "firmware-meister/manager" (FM) program audits each system for firmware versions for all masters/devices. (Already done in RMS, to some extent.)
4) The FM program then highlights all whose version does not match our "preferred version" from our repository. Older versions are marked as red, newer versions are marked as yellow, matching versions are marked as green. (Perhaps some form of RMS-like exception highlighting would be good, where "okay" results are collapsed.)
5) For each master/device we can then specify what version we want (via a dropdown populated with the available versions in our repository), and a time/date when to push the firmware out to the master/device. The FM then pushes out the firmware at the specified time/date. It the solution was a standalone app, we would have to leave it running 24/7. RMS is already doing this anyway.
I don't ask for much, do I! We could upload the firmware into RMS via the web interface, where it manages it's own repo of versions. (You could even supply an easy "update repo" button where RMS automatically pulls down the latest versions from the AMX site!) Given that RMS has/had it's own internal scheduling engine, that could be reused to initiate the FW updates. My idea is mostly inspired by the Tandberg Management Suite where (from what I saw several years ago) it can also control firmware for all the various video conference endpoints. Another good one to look at is the AXIS Camera Management app. It can push firmware out either in parallel, or sequentially. It also gives you options of what to do if a failure occurs (skip to next, halt, etc.) It also allows you to build config templates and push them out to which ever cameras you like. This could be useful to manage, say, Duet Memory Allocations where you want to ensure that the memory in the older units are not fully allocated to Duet, which results in you non-duet program not launching.
Trying to keep more than 20 masters current with the same firmware version becomes unwieldy, particularly when you work the same hours that the systems are in use. (Many of our classrooms are used from 8am to 10pm.) It becomes even more fun when you have a mix of 32Mb & 64Mb NI-700s (which have different firmware for each type), NI-3000s, NI-2100s and NI-3100s, CV7s, 700vi, MVP8400, and the occasional Vol3. Thankfully the firmware update mechanism is smart enough to know what firmware package it should be using, so this could be leveraged to select the correct .kit. It sounds like the new R4 updates are very order-specific. A managed mechanism could check to ensure that the appropriate order it followed, where such firmware dependencies exits.
I know my suggestion may cause discussion along the lines of "If it ain't broke, don't fix it." My approach is that if ever I need to contact tech support, their first question is often "Are you running the latest firmware? If not, update it, since your issue may already be addressed." When running large quantities of masters and AMX devices it helps to maintain the same firmware version across the entire fleet. This reduces the possible variations from room to room, which makes fault-finding much easier.
Roger McLean
Swinburne University
Just got back from the Brisbane tech talk. Almost excatly what you desribed there has been implimented and is awaiting release. Oh yeah, and it will integrate with RMS.
It would be nice to have help on various touch panel commands in studio. It should be something similar to the little info popup that displays when using functions. Even if this was limited to only the ^ commands, it would be helpful.
Some very great ideas so far. I like them. Some I've thought of before, most I haven't. I was expecting sarcasm so very glad to see you guys are taking these suggestions seriously.
Just got back from the Brisbane tech talk. Almost excatly what you desribed there has been implimented and is awaiting release. Oh yeah, and it will integrate with RMS.
Hurray! I mentioned my suggestion at the Melbourne roadshow, where I was told there is something under way. (I think I mentioned it at the one 6 months ago as well.) It sounds like you may have got a little more detail than me, but I guess we shall just have to wait an see. I wanted to put my ideas out there for all to see, especially when AMX are asking "publicly" for suggestions.
Rick - It's encouraging that you/AMX are actively listening to your customers. I know that you may not be able to produce every suggestion we come up with, but the fact that you ask and listen is awesome.
Some very great ideas so far. I like them. Some I've thought of before, most I haven't. I was expecting sarcasm so very glad to see you guys are taking these suggestions seriously.
Rick,
Thanks for coming back for assurance that our opinions are being heard. Something I've felt extremely strong about is that the core tools (TPD, NLS, KeypadBuilder) need to be improved upon, and there's no better way of improving them than by asking its core users what they need (or want.) I also feel that to test these possible new features is to have more beta testers, and a wider spectrum of testers (light users and heavy users).
I can describe how I saw a sunset and ask you to paint it - and it will most likely look nothing like how I saw it; however if I stood there and guided you on how I saw it - the result would be much better. Same applies to any kind of development.
Kudos to you & AMX for taking a serious approach on the development of the core tools. It is long overdue, but can see (since Studio 3.0) that there's a real concern on getting us the tools and features we need.
Just got back from the Brisbane tech talk. Almost excatly what you desribed there has been implimented and is awaiting release. Oh yeah, and it will integrate with RMS.
Update: One of the tech's from AMX just got back to me. Looks as though it's not going to be released, it's only intended for AMX internal use.
Rick, can another request be added to get a similar tool brought out for the greater unwashed?
Update: One of the tech's from AMX just got back to me. Looks as though it's not going to be released, it's only intended for AMX internal use.
Rick, can another request be added to get a similar tool brought out for the greater unwashed?
**sigh** I guess that's why I take the "wait and see" approach.
As for deploying such a mechanism for controlling firmware, I'm quite happy for it to be a RMS-only feature. I know that not everyone uses RMS, but I sort of expect RMS to be used in large AMX deployments, which is precisely where it becomes difficult to manage firmware versions. Given that RMS has user authentication & management it would also provide a layer of protection against people who don't quite know what they are doing, which would not be the case for a stand-alone application. Obviously you would need rather "high" RMS credentials (e.g. admin) to have access to such a firmware updating section.
Perhaps one day... Please! Otherwise I may have to write my own... If only NLS had some form of scripting interface...
Update: One of the tech's from AMX just got back to me. Looks as though it's not going to be released, it's only intended for AMX internal use.
Rick, can another request be added to get a similar tool brought out for the greater unwashed?
We had a meeting on this a week or two ago. The tool was designed for internal use and is not ready for any kind of deployment. There are still bugs in it and you can do more harm than good. To turn this into a supportable product would require further development work and testing, something we are considering.
That's completely understandable, firmware upgrades are one place you really don't want to be using buggy software.
As Roger said, if AMX were to make something similar available in the future integration with RMS would be ideal. Especially for situations such as Roger's and mine where there are a large number of AMX systems, running standardised, or very similar code bases. It would allow us to do our own quick testbench of the firmware to make sure it's not going to suddenly kill every system and then perform a managed rollout from a central location, rather than manually push out updates one box at a time.
For TP4
I would like to see something that animates the button which you dont need to have a special animation done on third party software. Like to have a hide and show effect. I would also like to see similar that TP3 which you can save as html and load to master as your stand alone tp.
There is a built-in tweener used for animation. You may want to check it out if you haven't already.
I have checked that one, there should be a selection with the transition of image. I want to create a different images such as brand names and I want to have an effect whenever it changes
Okay guys, don't let this thread die yet! AMX has a few more tools that we'd like your feedback on. How do you feel about IREdit and KeypadBuilder? Does anybody have any strong feelings about NetLinx Diagnostics and File Transfer?
IREdit - good for what it's for. I would however, love a way to do a batch import of HEX codes. Perhaps import a CSV file and it'll do what it needs to do. Also, we can import HEX codes, but we can't export them - is there a particular reason why? (It'd be SUPER slick if we could import other manufacturer's codes into an AMX IRN / IRL file, i.e. the RTI library - though this probably creates a sticky situation - so until then, I'll keep working on an RTI library importer program. )
KeypadBuilder . . . again, fine for what it's for - but a bad piece of software. It's not intuitive whatsoever; I hit "ENTER" and it takes me out of screens - and uhh . . . where's the "Undo" button? "Copy" button? To me, it's a product that's never gotten out of beta, and hasn't been touched. For keyboard shortcut guys like myself, there's WAY too much mouse-clicking - just my opinion.
Personally, I don't see - aside from improving / fixing some of the things I mentioned - anything else that could be added to make these programs any better. I am a light user on these two programs - so I'm not sure what else I *need*. Regarding NL Diagnostics and File transfer - I've *never* used them in my 5 years of doing AMX. I could see the value for the non-programmer, or for a company who doesn't want their techs mucking around with code or touch panel files - but to me as a programmer they are of no value.
Also, thanks for asking for our opinions. To me, it means A LOT!! Thank you.
Seeing as its seems to have been abandoned in favor of the VA template machine, how about opening up G4 Panel Builder beyond the strict conventions currently imposed on the users (ie, the programming model locked in there sucks).
...how about opening up G4 Panel Builder beyond the strict conventions currently imposed on the users (ie, the programming model locked in there sucks).
Could you explain? From what I understand, you can still create your own templates in TPD4 - and use them in G4PB. Painful? In a way. Very useful in the long-run? You betcha!
Could you explain? From what I understand, you can still create your own templates in TPD4 - and use them in G4PB. Painful? In a way. Very useful in the long-run? You betcha!
Start with being able to show more than one navigation element at a time and being able to link to navigation elements from sub-navigation elements.
IREdit - good for what it's for. I would however, love a way to do a batch import of HEX codes. Perhaps import a CSV file and it'll do what it needs to do. Also, we can import HEX codes, but we can't export them - is there a particular reason why? (It'd be SUPER slick if we could import other manufacturer's codes into an AMX IRN / IRL file, i.e. the RTI library - though this probably creates a sticky situation - so until then, I'll keep working on an RTI library importer program. )
+1 to that. The AMX IR database lags way behind various internet lists / resources. I would rather AMX spent R&D time on being able to harness those resources rather than trying to maintain an upto date IR database. There are utilities to covert between various other IR files so why not between RTI and AMX...
In IREdit I would like the ability to open a new IR file and pre load this with the command titles to match the various device functions standardised by AMX, and then be prompted command by command to paste the HEX values, hit enter, next command hex value, enter etc
I'd also like to be able to view the hex values for each command and or to compare them with another command...
The AMX IR database lags way behind various internet lists / resources. I would rather AMX spent R&D time on being able to harness those resources rather than trying to maintain an upto date IR database. There are utilities to covert between various other IR files so why not between RTI and AMX...
Not to drift off too far from topic, but I think the answers would be this (as I understand it.) One, AMX & RTI are competitors (sort of - though I don't consider them to be), I doubt they'll open up communication on the sharing of IR files. I believe RTI's IR library is nothing more than a password protected SQLite database (oddly, their string library is not password protected and can be edited - CAREFULLY!!!) I'm currently working on the exportation process of an RTI IR library - it's coming along slowly though.
I think AMX is so far behind in the game on IR, that I agree they should focus more on making it easier for us to create our "ultimate" IR library.
In IREdit I would like the ability to open a new IR file and pre load this with the command titles to match the various device functions standardised by AMX, and then be prompted command by command to paste the HEX values, hit enter, next command hex value, enter etc
+1 on the custom template and importation process of HEX like you described. Half of it can be achieved by creating your own template - again, CAREFULLY. The templates are nothing more than an Access database that you can add & remove your own. I did this onCe for quickly learning 8 command sets from a Dish Network remote. Unfortunately though, it took longer to make the template (cuz I wasn't quite sure what I was doing) than it did learn in the remote - but . . . if I saved some time somewhere in the process, it was completely worth it!
To sort of put a spin on what you're asking with there being a continuation once you put in a hex code, I'd like to be able to define my own IR templates. Let's face it, we all do things a little bit different, and when learning in remotes, it's a pain to have to type in every single name.
Not to drift off too far from topic, but I think the answers would be this (as I understand it.) One, AMX & RTI are competitors (sort of - though I don't consider them to be), I doubt they'll open up communication on the sharing of IR files.
Sorry I was not intending to suggest that any such collaberation would be possible, more that there are plenty of applications available to convert from one sort of IR db file to another, some complex freeware, others with manufacturers support.
To get back on track I think the general point would be as you say to simplify / automate some of the detail when capturing / importing IR data from any source. Various things are possible by directly editing files in db apps but this should be integral to the program if possible.
UEI licenses their database out from my understanding. They manufacture a bunch of oem remotes too, so they probably have one of the most extensive IR code databases available. Might be possible to ink a deal with them if AMX doesn't want to deal with it on their own. The AMX IR database in IREdit isn't very good at all in my experience.
Also, not sure if it's an issue with my installation, but the IREdit splash screen is modal and sits on top of all of my other windows until IREdit has fully launched. It tends to sit there for a while too, so if that can be fixed it would be helpful.
Also, since I end up having to add something to every IR file that I try to use from AMX or create something from scratch completely, it would be nice to be able to edit the functions once the code is entered. In other words, if I enter hex code for a discrete power function, I'd like to be able to see the actual hex for that function if I come back to it later on. As far as I know, you can't do that now.
In IREdit I would like the ability to open a new IR file and pre load this with the command titles to match the various device functions standardised by AMX, and then be prompted command by command to paste the HEX values, hit enter, next command hex value, enter etc
Forgot to +2 that one. Also, I realize that I asked for the same thing as Jim as far as being able to see the hex code, so I'll just +2 that one too.
And I'll +1 JJames' reititeration of thanks for asking for our opinions. Thanks!
Another thought: When using the NLS Device Notification Options to debug many "cookie-cutter" rooms (the only difference being system numbers), I have to manually look up the system number and create a new entry in the Device Notification Options list to match the new system number. This leads to a lot of repetitive delete/create for me. It would be nice/convenient if DNO worked when we specified a system number of '0'. (Interpreting '0' to be the-master-that-NLS-is-currently-connected-to). I would expect that notification would still have their real system number.
If this is not possible, a useful alternative would be to allow us to edit the DPS details for the entries in the Device Notification Options list. At least we can leave all our notification options set up for what we are interested in, and just edit/change the system number. If you were really kind, a button which auto-assigns the system number to the current system (derived from current master connection) would be sweet.
On top of what Roger is saying - I have to say that for Device Notifications, it'd be nice if there was a list of the defined device's name - rather than a manual input of D:P:S. When wanting to debug a large system, I have to find the D:P:S of the device I want to watch, a bit annoying sometimes in my opinion.
Fortunately, I don't need to use this program often, so I have learned to just accept it. I do have some problems with the program crashing when I am doing a complete remote learn using the IRIS. I'm not sure what causes this, but I have learned to save often and I just keep trying. Eventually I get the whole thing learned, but not before 2 or 3 crashes.
I also have to occasionally add a couple of HEX commands to a file. This works well (as it seems that AMX has no ability to find the discrete power and input commands for anything) when it is only a couple of codes I need to enter, but the process is a little cumbersome when I need to create an entire file from HEX codes. So, I have to support the previous statements regarding this. I would also like to say that as often as I use this (maybe 3-5 times per year), I would rather resources be devoted to improving TPD4, adding more graphic capabilities to touch panels, or improving the documentation of Duet.
KeypadBuilder:
Where do I begin... I personally don't care what is done with this app. We did use the Mio Keypads in a commercial job a few years ago, but that was when they were first released. We had some issues with them and although we eventually got them to function, we have not had the inclination to spec them in new jobs. They are easy to use, and of the devices configured with KeypadBuilder, this is about the only one I could see us ever using in the future. That being the case, the very limited capabilities of KpB would be acceptable.
As far as configuring the R1, R2, and R3, with the new pricing on the R4, I don't see any reason we would spec anything else. If we really needed a less expensive option other than the R4, a universal remote would be a better choice because of the ability to add buttons with labels. We are in the business of making our systems easy to use and needing to provide a 10 page guide that includes a channel map for each remote does not translate as easy to use. On a positive note, the new R4 pricing has really made it the only option for a remote in our system as a universal remote with the necessary programming is almost as expensive and not nearly as capable.
Lastly, the MIO DMS. This is, as they might say on the internet, an Epic Fail. A few years ago, I was doing some conversions from old systems using the old DMS keypads. Because of the limited availability of the old keypads, the decision was made to use the new keypads in a couple locations where the existing keypads failed. It was a nightmare! The new keypads were a step DOWN from the old ones and required some creative programming to get their functionality to be even close to the keypads being replaced. Then there was the software. The software was the nail in the coffin. I spent more time messing around with the keypad programming than I did reprogramming the processors. The software was beyond cumbersome. In fact, because of the lack of functionality on the keypad and the horrible software required to program them, they are forever on our DO NOT SPEC list. Given the new pricing on the smaller touch panels, I don't know why anyone would use a MIO DMS instead of a 4" touch panel.
I apologize if this wasn't the most constructive of criticisms, but I had to get that off my chest
Comments
This would also be helpful when layering buttons, we could just move the entire grouped button.
Think Adobe Fireworks' groups where you can have groups withing groups . . . CTRL+G = group, CTRL+SHIFT+G = ungroup top layer (continue to ungroup lower layers.)
1) We retain a local/server-side firmware repository where our preferred versions of firmware sit for all our hardware. The repository should allow for multiple versions, so we can roll back in those few rare instances where we may need to do so, and for each product type we can select one version to be the "preferred version". (This allows us to test newer versions before rolling it out in bulk.)
2) We build a list of comm settings for all our masters. (Already done in RMS.)
3) A "firmware-meister/manager" (FM) program audits each system for firmware versions for all masters/devices. (Already done in RMS, to some extent.)
4) The FM program then highlights all whose version does not match our "preferred version" from our repository. Older versions are marked as red, newer versions are marked as yellow, matching versions are marked as green. (Perhaps some form of RMS-like exception highlighting would be good, where "okay" results are collapsed.)
5) For each master/device we can then specify what version we want (via a dropdown populated with the available versions in our repository), and a time/date when to push the firmware out to the master/device. The FM then pushes out the firmware at the specified time/date. It the solution was a standalone app, we would have to leave it running 24/7. RMS is already doing this anyway.
I don't ask for much, do I! We could upload the firmware into RMS via the web interface, where it manages it's own repo of versions. (You could even supply an easy "update repo" button where RMS automatically pulls down the latest versions from the AMX site!) Given that RMS has/had it's own internal scheduling engine, that could be reused to initiate the FW updates. My idea is mostly inspired by the Tandberg Management Suite where (from what I saw several years ago) it can also control firmware for all the various video conference endpoints. Another good one to look at is the AXIS Camera Management app. It can push firmware out either in parallel, or sequentially. It also gives you options of what to do if a failure occurs (skip to next, halt, etc.) It also allows you to build config templates and push them out to which ever cameras you like. This could be useful to manage, say, Duet Memory Allocations where you want to ensure that the memory in the older units are not fully allocated to Duet, which results in you non-duet program not launching.
Trying to keep more than 20 masters current with the same firmware version becomes unwieldy, particularly when you work the same hours that the systems are in use. (Many of our classrooms are used from 8am to 10pm.) It becomes even more fun when you have a mix of 32Mb & 64Mb NI-700s (which have different firmware for each type), NI-3000s, NI-2100s and NI-3100s, CV7s, 700vi, MVP8400, and the occasional Vol3. Thankfully the firmware update mechanism is smart enough to know what firmware package it should be using, so this could be leveraged to select the correct .kit. It sounds like the new R4 updates are very order-specific. A managed mechanism could check to ensure that the appropriate order it followed, where such firmware dependencies exits.
I know my suggestion may cause discussion along the lines of "If it ain't broke, don't fix it." My approach is that if ever I need to contact tech support, their first question is often "Are you running the latest firmware? If not, update it, since your issue may already be addressed." When running large quantities of masters and AMX devices it helps to maintain the same firmware version across the entire fleet. This reduces the possible variations from room to room, which makes fault-finding much easier.
Roger McLean
Swinburne University
Just got back from the Brisbane tech talk. Almost excatly what you desribed there has been implimented and is awaiting release. Oh yeah, and it will integrate with RMS.
Jeff
Hurray! I mentioned my suggestion at the Melbourne roadshow, where I was told there is something under way. (I think I mentioned it at the one 6 months ago as well.) It sounds like you may have got a little more detail than me, but I guess we shall just have to wait an see. I wanted to put my ideas out there for all to see, especially when AMX are asking "publicly" for suggestions.
Rick - It's encouraging that you/AMX are actively listening to your customers. I know that you may not be able to produce every suggestion we come up with, but the fact that you ask and listen is awesome.
Roger McLean
Swinburne University
Rick,
Thanks for coming back for assurance that our opinions are being heard. Something I've felt extremely strong about is that the core tools (TPD, NLS, KeypadBuilder) need to be improved upon, and there's no better way of improving them than by asking its core users what they need (or want.) I also feel that to test these possible new features is to have more beta testers, and a wider spectrum of testers (light users and heavy users).
I can describe how I saw a sunset and ask you to paint it - and it will most likely look nothing like how I saw it; however if I stood there and guided you on how I saw it - the result would be much better. Same applies to any kind of development.
Kudos to you & AMX for taking a serious approach on the development of the core tools. It is long overdue, but can see (since Studio 3.0) that there's a real concern on getting us the tools and features we need.
Update: One of the tech's from AMX just got back to me. Looks as though it's not going to be released, it's only intended for AMX internal use.
Rick, can another request be added to get a similar tool brought out for the greater unwashed?
**sigh** I guess that's why I take the "wait and see" approach.
As for deploying such a mechanism for controlling firmware, I'm quite happy for it to be a RMS-only feature. I know that not everyone uses RMS, but I sort of expect RMS to be used in large AMX deployments, which is precisely where it becomes difficult to manage firmware versions. Given that RMS has user authentication & management it would also provide a layer of protection against people who don't quite know what they are doing, which would not be the case for a stand-alone application. Obviously you would need rather "high" RMS credentials (e.g. admin) to have access to such a firmware updating section.
Perhaps one day... Please!
Roger McLean
Swinburne University
We had a meeting on this a week or two ago. The tool was designed for internal use and is not ready for any kind of deployment. There are still bugs in it and you can do more harm than good. To turn this into a supportable product would require further development work and testing, something we are considering.
As Roger said, if AMX were to make something similar available in the future integration with RMS would be ideal. Especially for situations such as Roger's and mine where there are a large number of AMX systems, running standardised, or very similar code bases. It would allow us to do our own quick testbench of the firmware to make sure it's not going to suddenly kill every system and then perform a managed rollout from a central location, rather than manually push out updates one box at a time.
I would like to see something that animates the button which you dont need to have a special animation done on third party software. Like to have a hide and show effect. I would also like to see similar that TP3 which you can save as html and load to master as your stand alone tp.
I have checked that one, there should be a selection with the transition of image. I want to create a different images such as brand names and I want to have an effect whenever it changes
Okay guys, don't let this thread die yet! AMX has a few more tools that we'd like your feedback on. How do you feel about IREdit and KeypadBuilder? Does anybody have any strong feelings about NetLinx Diagnostics and File Transfer?
IREdit - good for what it's for. I would however, love a way to do a batch import of HEX codes. Perhaps import a CSV file and it'll do what it needs to do. Also, we can import HEX codes, but we can't export them - is there a particular reason why? (It'd be SUPER slick if we could import other manufacturer's codes into an AMX IRN / IRL file, i.e. the RTI library - though this probably creates a sticky situation - so until then, I'll keep working on an RTI library importer program.
KeypadBuilder . . . again, fine for what it's for - but a bad piece of software. It's not intuitive whatsoever; I hit "ENTER" and it takes me out of screens - and uhh . . . where's the "Undo" button? "Copy" button? To me, it's a product that's never gotten out of beta, and hasn't been touched. For keyboard shortcut guys like myself, there's WAY too much mouse-clicking - just my opinion.
Personally, I don't see - aside from improving / fixing some of the things I mentioned - anything else that could be added to make these programs any better. I am a light user on these two programs - so I'm not sure what else I *need*. Regarding NL Diagnostics and File transfer - I've *never* used them in my 5 years of doing AMX. I could see the value for the non-programmer, or for a company who doesn't want their techs mucking around with code or touch panel files - but to me as a programmer they are of no value.
Also, thanks for asking for our opinions. To me, it means A LOT!! Thank you.
Seeing as its seems to have been abandoned in favor of the VA template machine, how about opening up G4 Panel Builder beyond the strict conventions currently imposed on the users (ie, the programming model locked in there sucks).
Start with being able to show more than one navigation element at a time and being able to link to navigation elements from sub-navigation elements.
+1 to that. The AMX IR database lags way behind various internet lists / resources. I would rather AMX spent R&D time on being able to harness those resources rather than trying to maintain an upto date IR database. There are utilities to covert between various other IR files so why not between RTI and AMX...
In IREdit I would like the ability to open a new IR file and pre load this with the command titles to match the various device functions standardised by AMX, and then be prompted command by command to paste the HEX values, hit enter, next command hex value, enter etc
I'd also like to be able to view the hex values for each command and or to compare them with another command...
Not to drift off too far from topic, but I think the answers would be this (as I understand it.) One, AMX & RTI are competitors (sort of - though I don't consider them to be), I doubt they'll open up communication on the sharing of IR files. I believe RTI's IR library is nothing more than a password protected SQLite database (oddly, their string library is not password protected and can be edited - CAREFULLY!!!) I'm currently working on the exportation process of an RTI IR library - it's coming along slowly though.
I think AMX is so far behind in the game on IR, that I agree they should focus more on making it easier for us to create our "ultimate" IR library.
+1 on the custom template and importation process of HEX like you described. Half of it can be achieved by creating your own template - again, CAREFULLY. The templates are nothing more than an Access database that you can add & remove your own. I did this onCe for quickly learning 8 command sets from a Dish Network remote. Unfortunately though, it took longer to make the template (cuz I wasn't quite sure what I was doing) than it did learn in the remote - but . . . if I saved some time somewhere in the process, it was completely worth it!
To sort of put a spin on what you're asking with there being a continuation once you put in a hex code, I'd like to be able to define my own IR templates. Let's face it, we all do things a little bit different, and when learning in remotes, it's a pain to have to type in every single name.
Sorry I was not intending to suggest that any such collaberation would be possible, more that there are plenty of applications available to convert from one sort of IR db file to another, some complex freeware, others with manufacturers support.
To get back on track I think the general point would be as you say to simplify / automate some of the detail when capturing / importing IR data from any source. Various things are possible by directly editing files in db apps but this should be integral to the program if possible.
Also, not sure if it's an issue with my installation, but the IREdit splash screen is modal and sits on top of all of my other windows until IREdit has fully launched. It tends to sit there for a while too, so if that can be fixed it would be helpful.
Also, since I end up having to add something to every IR file that I try to use from AMX or create something from scratch completely, it would be nice to be able to edit the functions once the code is entered. In other words, if I enter hex code for a discrete power function, I'd like to be able to see the actual hex for that function if I come back to it later on. As far as I know, you can't do that now.
--John
Forgot to +2 that one. Also, I realize that I asked for the same thing as Jim as far as being able to see the hex code, so I'll just +2 that one too.
And I'll +1 JJames' reititeration of thanks for asking for our opinions. Thanks!
--John
If this is not possible, a useful alternative would be to allow us to edit the DPS details for the entries in the Device Notification Options list. At least we can leave all our notification options set up for what we are interested in, and just edit/change the system number. If you were really kind, a button which auto-assigns the system number to the current system (derived from current master connection) would be sweet.
Roger McLean
Swinburne University
IREdit:
Fortunately, I don't need to use this program often, so I have learned to just accept it. I do have some problems with the program crashing when I am doing a complete remote learn using the IRIS. I'm not sure what causes this, but I have learned to save often and I just keep trying. Eventually I get the whole thing learned, but not before 2 or 3 crashes.
I also have to occasionally add a couple of HEX commands to a file. This works well (as it seems that AMX has no ability to find the discrete power and input commands for anything) when it is only a couple of codes I need to enter, but the process is a little cumbersome when I need to create an entire file from HEX codes. So, I have to support the previous statements regarding this. I would also like to say that as often as I use this (maybe 3-5 times per year), I would rather resources be devoted to improving TPD4, adding more graphic capabilities to touch panels, or improving the documentation of Duet.
KeypadBuilder:
Where do I begin... I personally don't care what is done with this app. We did use the Mio Keypads in a commercial job a few years ago, but that was when they were first released. We had some issues with them and although we eventually got them to function, we have not had the inclination to spec them in new jobs. They are easy to use, and of the devices configured with KeypadBuilder, this is about the only one I could see us ever using in the future. That being the case, the very limited capabilities of KpB would be acceptable.
As far as configuring the R1, R2, and R3, with the new pricing on the R4, I don't see any reason we would spec anything else. If we really needed a less expensive option other than the R4, a universal remote would be a better choice because of the ability to add buttons with labels. We are in the business of making our systems easy to use and needing to provide a 10 page guide that includes a channel map for each remote does not translate as easy to use. On a positive note, the new R4 pricing has really made it the only option for a remote in our system as a universal remote with the necessary programming is almost as expensive and not nearly as capable.
Lastly, the MIO DMS. This is, as they might say on the internet, an Epic Fail. A few years ago, I was doing some conversions from old systems using the old DMS keypads. Because of the limited availability of the old keypads, the decision was made to use the new keypads in a couple locations where the existing keypads failed. It was a nightmare! The new keypads were a step DOWN from the old ones and required some creative programming to get their functionality to be even close to the keypads being replaced. Then there was the software. The software was the nail in the coffin. I spent more time messing around with the keypad programming than I did reprogramming the processors. The software was beyond cumbersome. In fact, because of the lack of functionality on the keypad and the horrible software required to program them, they are forever on our DO NOT SPEC list. Given the new pricing on the smaller touch panels, I don't know why anyone would use a MIO DMS instead of a 4" touch panel.
I apologize if this wasn't the most constructive of criticisms, but I had to get that off my chest
Jeff