The software fix/update was a disaster. Now, if you assign a NEW lcd button (create new device) all your pre-existing variables are wiped out.

URC should restore the original software without the variable features and get it right or just not do it if they can't figure this one out. I just chalk this up to lack of support. Not because there are bugs, not because there is no research going to the fixing of the mess, but how the situation is being handled in the meantime. Anybody in any software realizes if the current state of a new release is a disaster, roll back.

I've posted a thread at the URC forum about these very issues. It's sad when they mess up a perfectly good situation with those updates. The MX-900 is our fall back remote, I hope I don't have the same issues.

If you didn't know already, the MX-880 and MX-900 are completely file interchangeable. You can program in the Mx-880 then import the file to the MX-900. It actually works. I wish all URC editors and remotes were interchangeable. But that's a dream, not a wish. Good luck Vbova.

Chalk that up to a lack of vision. Different programming packages for every remote creates problems like that. I don't know why the editors can't create a file that is interchangeable - i don't think that is very difficult from a programming stance. Any difficulty that exists is simply due to a lack of foresight that maybe people would want t swap around devices.

It also encourages people to stick to one company. If people are going to replicate work anyway, they will pick a remote and or company that they know or like best.

Oh well , too late now.

There is, it's called Integration Designer, only problem is, it's for RTI.

As a software developer (a GUI developer at that), I'm always dismayed when I have to use one of the URC editors. They have never been a pleasure to use, and I think they make things more difficult than they need to be. It's clear that the overall design/architecture is out of date and woefully inadequate for their current needs.

At this point though, I doubt URC wants to make the monetary investment required to correct the problem, and would rather just keep going down the same road which requires minimal cost with each new remote.

This much is certain regarding the software development, but at least they listened to us when it came to the MX-810. They knew with that much backlash, they had to come up with a solution. I guess it's easier to make a new remote than to fix the editor for them.

Another flaw, URC seems to think that no one uses the Mac platform and it's a still a minority in the computer world. That's just funny.

Honestly, I have no issues with URC's editors when they work correctly. They're straightforward and easy. It's just the bugs, and lack of fixes, are getting ridiculous.

Well, as a former Apple employee who left on good terms, I can tell you that URC is completely aware of the Mac market. While the Macintosh market share is steadily growing (and I expect will do even more so right around the 9th of September), it still is in fact a minority market share. It just happens to be a very high profile one. Like most software companies, we keep a constant eye on hardware trends.

Ultimately, the argument for whether or not any company develops for any platform will always be "Is it profitable to develop for this platform?" Trust me, we all like the Mac around here at URC. But companies that develop for what they like instead of what the market demands are on a quick road to Fire Sale Town.

Market share in the teens is definitely getting close to the tipping point, but ultimately, we also know that like any trade, installers need to use the tools necessary for the job. Right now, one of those tools is a Windows based computer. That may change in the future—maybe even soon—but to spin a metaphor: if you want to work on cars right now, you better have the tools to change an oil filter, no matter how cool you think that shiny new hydrogen pressure guage might be.

Best regards,
Dale

The only thing Dale Didn't say after that was-


Bam!!!






Thanks URC for giving us what we want even if it is buggy.

The other thing he didn't say is when the software suite will work properly...

I was up really late on a project for CEDIA, so I'll start by saying I'm being a little more frank than usual. As always, I speak for myself, not for URC...

If you define "properly" as "completely without bugs or features that work differently than you personally prefer," then the answer is never.

I've worked for a lot of big names in software, including Apple, Macromedia, and IBM. Those companies and every other have one thing in common: they write software, and software is never, ever, 100% bug-free. And of course, a feature that one person considers a UI flaw can be the best item in the software to someone else, because there's no such thing as the perfect UI that meets every person's needs. If there was, there would be no argument between Windows, Linux, and Macintosh—the answer would be obvious and apparent, and every last computer user would have switched to it at their most recent PC purchase.

I've said many times that I'll never claim that our editors are bug-free... and that's a lot more than you'll get out of most employees commenting on their own products. I try to be as direct and communicative as I am allowed to be, but just like you, I follow the guidelines set forth by my employer, both because I like my company and because it's the appropriate thing to do. I don't feel uncomfortable admitting that our products are not 100% without fault, because I know that our competitors face the same challenges we do, and the installers who choose those products also have to deal with the flaws there.

I guess when you've worked for as many manufacturers as I have, you get a bit more sympathetic to the realities of product development. You can't please all of the people all of the time, and it's not the people with the biggest problems who get the most most attention... it's the ones who complain loudest, regarless of the magnitude of the issue.

Best regards,
Dale

What's funny is your lack of mathematical comprehension. While some analysts have set the market share of Macs at 21%, the real number as best as anyone can tell, is between 7 and 8 % (7.8% being the most widely quoted number). Furthermore, the percentage of Macs being used in a business setting is lower than that. Most are located in the dorm rooms of hipster college kids.

Last I checked, anything less than 50% is a minority. The bottom line is, there is no mac support because not enough people care. Most people who are using macs these days are *used* to not having software support, so they install parallels, bootcamp, vmware, etc to allow non-Mac software. Suggest you try one of those routes and lay off the whining.

-aedile-

I don't think you're as frank as you could have been. ALL software has bugs that are true bugs, not just "differences that work differently than you prefer". To believe otherwise is just not true.

However, I don't think it fair to fault URC or any other software company for such bugs though as it's just part of the business. Could URC make bug free software? Sure, anybody can given enough time and cost. But that time and cost would bankrupt them (or anybody else for that matter).

In lieu of 100% bug-free code, any company with software must have an adequate support organization and be active in publishing patches/updates as necessary for customer issues. I personally have no experience with URC's support (or lack thereof) so I can't comment on their track record here.

Dale,

I'm not asking for nuance fixes here, I'm asking for core feature fixes. Are you saying that you don't think that losing defined variables upon adding or importing a device is not a bug that should be addressed immediatly?

I program Crestron, and a little in C# as it can relate to Crestron...I understand bugs, they happen all the time. But come on, all you had to do was use the MX900 editor for 2 minutes before you realize that it's not ready for release.

To me, the definition of a bug is 'small and hard to find coding errors that only occur in specific circumstances' not, 'use the program for 2 minutes and your $hit is gone' type of thing.

For what it's worth, I'm not a decision maker about what happens in the engineering department or what gets priority. I'm actually drastically out of that loop, not even being in the same state as the engineering department. What I do know is that those guys are some of the most crazy overworked, dedicated engineers I've worked with. And I also know that everything I say here is a careful dance between trying to be as up front as I can be and trying to make sure I stand by the policies of my employer, both to the letter and the spirit.

If I were in possession of a list of items the engineers are working on, and I was allowed to post it here, you can bet I would. You have no idea how many times I have to just turn away from a post and act like I didn't see it just because I know something exciting and cool, but I can't say anything. That's just part of being a professional. Imagine working for Macromedia and having to stay quiet while you know the whole company is about to be sold to Adobe! Most of the time the secrets are little though, like what features our engineers are currently examining in existing software.

So no, I'm neither defending nor denying any particular bug or feature. I can't, and it's my paycheck after all, so I wouldn't if I could. The point of my post though, was that all software has flaws. Some of them are even big ones, and some take time to solve, for reasons that are also confidential items we can't discuss. Earlier this year Microsoft finally fixed a bug in Windows Explorer that froze, but didn't bluescreen, all of Windows. And it was literally as simple as "drag any file from this location to that location, then right click any file in the same folder from where you dragged the first file." It froze the whole operating system, and was present from the very first shipment of Windows XP until early this year. That's a pretty big bug, from a company with a LOT of resources at their disposal. But it took them years to track it down and fix it.

Of course, bugs like that are the exception. But still, it's very easy to assume that a fix is elementary if you're not the one reading several hundred thousand lines of code trying to track it down.

Ultimately, the reason I commented, and really, the reason I spend time on forums at all, is that I'm in the cool position of being able to personally and truthfully say that I really do work for a company that has the best interest of my peers at heart. It's cool to be able to share what I can and just be "one of the guys" with the industry. We can't always solve every problem in the order or in the way that each installer wants, but I can honestly say that we really are trying to make your jobs cooler, easier, and more profitable.

So... to those of you who are on my wavelength on this, please drop by our booth at CEDIA and say Hi. For those who are not, all I can say is that we, and I, are working every day (and for some like me, nights too) trying to keep URC products the best choice in your line-up. Because we're like you: we love this stuff, and we're darned happy to be able to make a living doing it.

Best regards,
Dale