Home AMX User Forum NetLinx Modules & Duet Modules

Autonomic Controls - MMS module : How to implement?

Has anyone had experience with this module?

We have the MMS-5 model, which has 4 audio outputs.
Each output is run into an autopatch audio matrix, outputs of this go to rooms in a house.

We have 13 touch panels which need to be able to select and control any one of the 4 MMS outputs.

The provide modules, "comm" and "ui" don't come with documentation on how to install for this number of touch panels.

I want to make sure I can "disconnect" each touch panel from the MMS module when not in use, to reduce uneeded communication and data use.

Any help and example code much appreciated.



  • I second this request. We are busy experimenting with an MMS-2 and battling with multiple tp's.
    Anyone with any help really appreciated.. Thanks, Mike
  • viningvining Posts: 4,368
    Don't use it but a quick glance looks like you need to do something like this:
    DEFINE_MODULE 'Autonomic Controls MCS UI' MCEUI10 (vdvMCS, dvTP10, cMCS_SERVER_IP,iMCS_ART_PORT)
    DEFINE_MODULE 'Autonomic Controls MCS UI' MCEUI11 (vdvMCS, dvTP11, cMCS_SERVER_IP,iMCS_ART_PORT)
    DEFINE_MODULE 'Autonomic Controls MCS UI' MCEUI12 (vdvMCS, dvTP12, cMCS_SERVER_IP,iMCS_ART_PORT)
    DEFINE_MODULE 'Autonomic Controls MCS UI' MCEUI13 (vdvMCS, dvTP13, cMCS_SERVER_IP,iMCS_ART_PORT)
    DEFINE_MODULE 'Autonomic Controls MCS UI' MCEUI14 (vdvMCS, dvTP14, cMCS_SERVER_IP,iMCS_ART_PORT)
    DEFINE_MODULE 'Autonomic Controls MCS UI' MCEUI15 (vdvMCS, dvTP15, cMCS_SERVER_IP,iMCS_ART_PORT)
    DEFINE_MODULE 'Autonomic Controls MCS UI' MCEUI16 (vdvMCS, dvTP16, cMCS_SERVER_IP,iMCS_ART_PORT)
    I'm not a big fan of requiring an instance per UI but alot of device modules are written this way. I'd rather use arrays and instantiate the comm modules per device installed not per UI. Imagine this type of coding with multiple devices and multiple TPs and then instantiating NUMBER DEVICES * NUMBER OF TPs.
  • Worse then that. You need an instance of the comm and ui module for each touchpanel. Which also means a separate IP port and separate virtual device for each TP.

    Oh, the way they expect you to use it is have the user choose witch output they want to listen to each time. There's a command to switch outputs, but you have to 'request' what outputs are available at least one time after every reboot in order to be able to be able to switch between them. IE, when a TP comes online you have to enable the comms, send the request for zones, and then close the comms. That way when the user selects output 3, you can enable comes, enable page flips, then send the command to switch to output 3.

    Of course I suppose you could let the user pick the output while on the autonomic page, track witch output they select through the module, and then have the autopatch switch accordingly.

    Don't get me started on all the non-volatile declarations in the module. Better change those, with 13 touchpanels you will run out of memory.

    Also, if you want to have keypads are any hand held remote control track functions, you'll need 4 more declarations of the UI and COMMs, 4 more virtuals, 4 more ports, and 4 fake TPs locked onto the separate outputs that you can Do_pushes on.

    And have fun fixing it after they add features to the unit and neglect to update it themselves. The 2.4 version on their site shows 2.4:

    -Added support for Favorites.

    Sure, you can add a favorite, but the module doesn't support actually viewing those you've saved.

    And just wait until they send an update and the module quits working all together. Then their one and only tech support guy wants to waste three days of your life viewing the AMX 'logs' (he didn't write the module), while eventually declaring it wasn't their problem. Sure, the same code that's worked fine for a year and suddenly quit after your update is AMX's fault.

    Sure, I'm a little bit bitter. We've sold two, took weeks to make the first work well, 6 months to get the updates advertised to the client, and now only one still working. Run away.

    Kevin D.
  • Thanks Kevin

    Not what I wanted to hear, but appreciate the feedback.

    I'll let you know how we get on.
  • TurnipTruckTurnipTruck Posts: 1,485
    I've been reading through the protocol document recently as I have been considering adding the MMS to my arsenal. With all of the time other have spent tweaking the provided module, it seems to me to be a candidate for a write-it-yourself. The protocol seems quite friendly and relatively easy to implement into a UI-array based architecture. I'll let you know if and when I get started.

    My main concern is not the process of module writing, but the longevity of the company. Shortly after I had perfected my own module for Escient Fireball, they went belly-to-the-sun. Hopefully Autonomic sticks around long enough for me to enjoy the fruits of my labor several times over.
  • John NagyJohn Nagy Posts: 1,714
    We started from scratch for our support on the MMS and its sister from NuVo (same box minus one output). While more challenging than most devices because of the range of functions, it was required for the above reasons... we could not use the module for anything but concepts.

    Autonomic has been around for quite a while as perhaps the best Media Center control system, and MMS is built on that experience (and protocols). I think they will be around a while, I really like the MMS. The protocol is intense but consistent.

    We implemented our own favorites mechanism to allow saving the path to anything currently playing... which embodies the playlist filter and/or radio path... so you can save anything you are listening to as a favorite. Mixed radio, Pandora, local music playlist, etc.
  • Yeah, if you rolled your own, you would probably be good. Just using their provided module has some issues. While trying to work through the first go round, I saw they were trying hire an AMX programmer. I guess they all ready have a good ******** guy, because their programmers rave about it.

    Kevin D.
  • I am busy trying to implement an MMS-2 now. I am dealing with Jonathan in their tech support but he's battling with what I have issues with, maybe you guys have seen this...

    I have modified the bog standard module that is available on their site to two seperate modules and have modified
    the 'SET INSTANCE' in each, so that each module points calls a seperate output on the server when connecting. The outputs on the MMS-2 are called MAIN and PLAYER_A.

    We are trying to do this as we are planning on running this through a Tango matrix and want to choose which output of the server we are controlling before opening the pages to control it. ie, ROOMS SOURCES, then choose either MEDIA SERVER A or MEDIA SERVER B.

    Our modified modules seem to be doing the right thing in calling the correct output and controlling the content
    being played on it but we are finding that the cover art is not updating from the two seperate outputs.

    If you choose the Main output and set something playing and then head off to the secondary output and set something else playing, when you go back to the main zone, it is still showing the artwork for the secondary output until the actual album changes on the main zone... The module does not call for a graphics update unless
    you change music which is a problem when switching between the two modules / outputs..

    I cannot see where the module requests an album artwork update for the interface otherwise I could call this when opening up the pages..

    Please guys if you know what I am talking about and can offer any help, it would be hugely appreciated as I am not getting too far on my own =( even though Ive been talking to Autonomics. It seems like someone has written the AMX module for them and left them to it on their own.. (Just my opinion)..
  • A couple of ways of doing it, it seems.

    I disconnect when going back to source selection and reconnect when selecting the new source. That will refresh the data from "define_function MCS_onStart()"

    You can also enable page tracking on the touchpanel. This should refresh the cover art on ANY page change. See "if (find_string(data.text,'PAGE-',1)<>0)" in the command section of data_event(TP).

    Of course you can have your output selection command do it by calling: refreshNowPlayingArt()

    Here's my modified 2.4 module with comments (about the only ones) added by me for what I changed and why.


    Kevin D.
  • Thanks Kevin, im having a look at it now. I am also talking to Mike at Autonomics who has been extremely helpful so I will hopefully be able to post a worker back =)
  • youstrayoustra Posts: 135
    Update on Autonomic

    Anyone have updated experience on the Media Control System? I must say it's been a huge waste of time for us so I'm curious whether others are having better success. We're trying to setup a reference system with 4-6 zones of audio and a 7.1 video zone off of WMC. We've tried 4 (yes four) clean installs. In some cases, we've had problems with multiple sound cards. That's not autonomic's fault but it'd be great if they had support with a reference system/mobo and sound card config for multi-zone. When we did get the hardware working, the software was as erratic as Sean Young two cocktails into the evening. Video and photos worked consistently but movies and audio were consistently unreliable. The instance of iTunes running on the server would suddenly begin playing songs w/o prompting -- this was all just on the standalone system w/o any AMX integration...just testing from the web client.

    So I'm about to give up, but I'm curious if others have had great experiences and I should go back to the well. I've resolved to do movies/video/photos through WMC or plex or vortex and use a one-way display-based UI. I like the My Movies interface on WMC, but I'm not as experienced on the gliziness of plex/vortex.

    For audio, I'm going to probably go w/ squeezeboxes and RocketUI.

    If anyone's got a fresh take on that, let me know as well.
  • a_riot42a_riot42 Posts: 1,619
    I just went through an install, but fortunately it was one touch panel and one server. I found issues with Windows 7, Windows Media Server, the AMX module, although the MMS software seemed to work well. The supplied UI was fine, although I redid the look and feel. I had it all installed correctly and not much was being asked of the system, but after being used to Kaleidescape, I can't say I would be in a hurry to recommend this to a client. Its not particularly cheap, and there are simply too many things to go wrong with no debugging between all the elements. Windows Media Server doesn't seem like it was even tested before it left the building.

    I would agree that a rewrite of the module is the only way I would do this again, but to do all the work and still be left with a lame experience would be disappointing.
  • DHawthorneDHawthorne Posts: 4,584
    shr00m-dew wrote: »
    Worse then that. You need an instance of the comm and ui module for each touchpanel. Which also means a separate IP port and separate virtual device for each TP.

    Oh, the way they expect you to use it is have the user choose witch output they want to listen to each time. There's a command to switch outputs, but you have to 'request' what outputs are available at least one time after every reboot in order to be able to be able to switch between them. IE, when a TP comes online you have to enable the comms, send the request for zones, and then close the comms. That way when the user selects output 3, you can enable comes, enable page flips, then send the command to switch to output 3.

    I've got one of these on my bench, and have begun the painstaking process of adapting it. Of course, everything is on device one on the panel, and they extensively used icons for button images, and are changing the icon for feedback as well ... and, of course, as soon as you copy the pages, all those slots are wrong.

    But is it really necessary to have a separate comm module for each panel? I only have one so far in my mockup, but will eventually have a half-dozen. The tech at autonomic said only one was needed, but I noticed the clunky way they are doing zone changes too, and wondered how that would work. So what is the logic behind having one comm per UI? Wouldn't it be better to adapt it to one comm per zone and flip it in the UI dynamically?
  • TurnipTruckTurnipTruck Posts: 1,485
    The primary reason that one instance per UI is required is for browsing media. During a browsing session, the title list can be narrowed by artist, title, genre, etc. That filtering is done within the Autonomic server. If multiple panels were in an array connected to the MMS by one IP socket, independent browsing could not be acheived.

    The only way to reduce the number of module instances would be to have the Autonomic server manage independent browsing sessions. A browsing request to the server would contain a specific source identifier. Then the browsing result to the UIs would return with a similar identifier allowing us to determine to which UI to send the browsing results. The Autonomic server would have to maintain independent browsing filter stacks for each UI.

    I have mentioned this to Autonomic and they said that it would go on their wish list. However, the impression I get is that they are short on funds and resources, so I'm not holding my breath. I would LOVE to be pleasantly suprised though! I would have a hard time specifying their stuff for a large system with many UIs as it is now.

    The only real progress I made beyond their module was to create a way to programatically swicth the player instance to a particular UI without having to do it from the drop-down menu on their UI. It is helpful in the case of an MMS where you just want to choose a player instance to send to a zone with one step.
  • viningvining Posts: 4,368
    You could still accomplish this with just 1 comm and 1 UI by passing a virtual & dev array to the comm module for the number of sockets needed. Commands sent to a specific virtual get routed to its corresponding dev and when strings are returned from that dev they're sent to it's corresponding virtual after processing. In the UI the virtual receives the data sent from the com and inturns stores that data and sends feedback to the UI's associated with that virtual. The UI only has to change its virtual association and each virtual tracks where it is and what UI's are associated. You still have individual sockets for multiple sessions with different browser filters on the server.

    It really shouldn't be so hard for them to do if that's how they initially went about it but I think they looked at how AMX modules are written and figured that's the way it should be done. Maybe this format has benefits for the auto code generating requirements of VA or some other grand scheme and not so much simple and logical coding design.

    If AMX ran multiple threads seperate instances would be required but since it doesn't they aren't really needed for anything other than organization and/or isolation.
  • DHawthorneDHawthorne Posts: 4,584
    I talked to Mike over at Autonomic, and he admitted they really had no idea how to write an AMX module when it was created. Obviously, they knew how to write code, but some of the quirkier nuances of AMX were unknown and they would do it different now. One of the things he said they are definitely fixing is the liberal use of icon slots in the panel design (which was a nightmare to port to my own panels). They have also learned about the need to declare variables volatile, and the UI module is no longer locked to the panel port 1.

    I get the impression that they are a very small company. But they have been very helpful, and are even sending me some code to run the server in a rather specialized manner that the module was never designed for. We'll see how it goes.
  • Autonomic MMS5

    Has anyone perfected the MMS module implementation yet? They have touted how the Mirage was created for integrator's, but their AMX modules are beyond weak.

    Any tips, warnings, or suggestions appreciated!

  • TurnipTruckTurnipTruck Posts: 1,485
    If every panel was to be able to browse every instance of the player you would need (panel * players) instances of the module. That's the main problem. If Autonomic could (would) make the browse requests and responses able to be instanced in and out of the MMS, AMX implementation would be much easier, especially for larger systems. I asked about it and they said that it doesn't make sense for their product. I no longer specify or recommend MMS.

    My best implemtation was to have a panel connect to a player as needed, at the same time bump off the current panel.

    You can do almost everything that an MMS does and some things that it doesn't with a Yamaha receiver. You'll just lose cover art on the panel.
  • Last time I looked (a few weeks ago) they were looking to hire an AMX programmer.

    Luckily, the largest job I did with a MMS was a MMS-2 which we only used one output and two panels, so I just went with two instances of the modules. It wasn't horrible once I spent a couple days fixing the module and provided TP pages. It's obvious they didn't do any testing with an 800x480 panel.
  • John NagyJohn Nagy Posts: 1,714
    We rolled our own due to the single-ended design of the module. It was a challenge, made worse by a number of commands that are undocumented. Every few weeks we found another thing it couldn't do, called up and got a little more info.... added more code... got it right...

    It's pretty impressive when working right. We centralized the core and vend info to panels as needed, so it supports up to 20 MMS units and 50 panels, any to any, simultaneously. We skip the cover art thumbnails for the reasons discussed elsewhere, AMX panels can't keep up. We show the currently selected and currently playing art. So it can be done...

    The concept of the MMS was to treat each service the same in hierarchies, navigated identically. But the services don't work enough alike, and the kludges break the consistency that was initially hoped for. It's still a good box.
  • trobertstroberts Posts: 228
    Hey all,
    I see there have been some headaches on this device, control wise. Can anyone talk about the reliability of the unit itself? How does it compare to squeezebox? Once the MMSx is programmed how well does it function?
  • TurnipTruckTurnipTruck Posts: 1,485
    We have since tamed the beast.

    With a proper module, the MMS is an excellent device for use in a Netlinx environment.

    We have had no operational issues with the MMS whatsoever. There is an MMS5 here in the office. It is almost always playing music into at least a few zones. Never a hiccup related to its own hardware/software.
  • MMS2

    From what I read here, it looks like implementing the Autonomic product into Netlinx is a very challenging and frustrating experience. I have the task of implementing a MMS2 into a 6 touch panel project and spent yesterday trying to import the UI graphics into my own TP file and found out that they used reference icons instead of images and the whole module is code/page driven, what makes it painful to custom integrate into a larger project. Has anyone successfully imported Autonomic graphics into their own UI? I am looking for an UI/TP4 file that I can copy and past the Autonomic graphics into my project without breaking the icon references and feedback. Any help will be well appreciated. Thanks,

  • ericmedleyericmedley Posts: 4,177
    We rolled our own for this reason. One module, all zones, 100 panels. Wasn't fun but it works.
  • I know it may be asking for too much, but is it possible to share your module? Thanks!
  • trobertstroberts Posts: 228
    I actually used Autonomics module as is. Granted, there are ridiculous requirements to implement it...mainly being a definition for each UI is a little crazy. I have not had any issues with the module or the MMS5a working well. So far as the UI is concerned, I just used my own, similar to the one I used for squeezebox, audio request, or kscape music. All you need is to define the module...you don't need to use all the other stuff in the demo file. I dedicated 1 NI processor to run the autonomics and kscape modules only and dedicated one port on my panels for kscape and autonomics.

    I will mention I did need to modify the module, so the file would run, as it ran out of memory anytime the processor tried to run. All I needed to do was make all variable and constants VOLATILE.
  • DHawthorneDHawthorne Posts: 4,584
    I'm using a modified version of their next-to-most-recent module with my own panel file, and I'm still struggling with some of the inconsistencies and quirks. I am only using the streaming services, and have left out any buttons that refer to the stored music. When a player is called, I "push" the Radio button in code. But I still have the following annoying quirks:

    The top level menu doesn't always populate, and you have to press the Radio button a second time.
    You can't manually flip to the browse page; the list doesn't work if you just flip pages. I've been sending a "back" command to get it going again, and most services this works, but on some it knocks the listing back a level, and some it deosn't. I don't know what command to send that will just let the last used listing work again, at least not consistently.
    They have dramatically improved how they serve cover art to the panels, but still once in a while, the listings that use it populate slowly, or miss one or two, or still show the last used graphic in that slot instead of the correct one.
    Some services flip pages properly to the "Now Playing" page, some do not.
    Frequently, a streaming service gets extremely sluggish, and sometimes non-responsive. Rebooting the MMS fixes it, but that's not a solution I want to offer to my customers.

    I tried their most recent UI module, and it's even worse. It will bounce back and forth between "Now Playing" and the browse page 3-4 times when you select a program.

    I'm going crazy with this. I do not have the resources (ie., time) to play around with it, and every tweak I need to bother with I lose money and customer satisfaction, so I have a lot of little get-it-working band-aids that I am very unhappy with. I am willing to entertain paying for a solid, stable, consistent module that I can comfortably re-skin with my own panel designs. Though I would love to work on development of my own implementation, my company is fast moving away from that kind of work; we need to be able to turn over jobs quicker, and development is no longer in the cards for me.
  • TurnipTruckTurnipTruck Posts: 1,485
    Autonomic's module requires that you open (player instances * panels) to allow all panels to see all players. With an MMS-5 and ten panels, that's 50 IP sockets, which is completely silly.

    There is no other choice but to write your own, which we have done. I cannot share the module publicly, but I can tell you the jist of it. The trick is to make an array of IP sockets that will connect to the MMS. You then connect panels one at a time to the MMS through those sockets as needed. The design of Autonomic's protocol is one socket to one panel. There is no good way to work with an array of panels through one IP socket.

    PM me if you are interested in the module. (Excessive advertising trying to be avoided)
  • John NagyJohn Nagy Posts: 1,714
    Well, there IS a way to work with an array of panels through one IP socket.

    Our design treats control and feedback as a single entity/instance per MMS output, with the feedback stored in a single array at the NetLinx. Then panel display feedback is vended out to whatever and however many panels as happen to want to look at it, all managed from the Netlinx. It doesn't matter which panel might send commands, any panel tuned in to a given MMS output has equal access to push commands, and any panel sharing a view of that output will be sent the same feedback. The MMS has no idea or concern about talking to panels, but any number can share it without delay or loss of synchronization. This single-control-point with distributed page content design holds up with any feedback device, including Kaliedescape, Request, anything.

    And I'm convinced there are at least a few other ways to do it....
  • TurnipTruckTurnipTruck Posts: 1,485
    The reason that we do one socket per UI is that browsing is instanced per socket by the MMS. Multiple panels browsing on the same socket would mirror each other if they were all on the browsing screen. We find that to be a less-desired mode of operation. In our implementation, multiple panels are free to browse at will. Once one of the panels makes a selection, only the "Now Playing" feedback of the other panels changes. The browsing of the other panels is not interrupted.
Sign In or Register to comment.