Some clarifications
Dear Bob Moffett (Proformance),
Thanks for your honest posts and various comments. We're sorry that you've experienced problems with the video output on your hardware.
As the lead software architect behind OtsAV and the founder of the company I'd like to respond to some of your wider claims.
You're certainly entitled to your opinion on these issues, just as anyone. I'm also entitled to mine, and with some of the points you have raised it comes down to more than opinion and is in fact measurable with hard facts. I will try to shed some light on each of the areas.
It is not my intention to change your mind on any particular area - your view is your view and that's fine. However I do wish to introduce some balance into the discussion and at least put forward an official Ots position, whether you or anyone else reading this chooses to accept it or not.
I most likely will not comment again after this post.
First, on the issue of the overlay/video output, what Jeff and Rick have said is correct. OtsAV does not interface directly with end-hardware, but instead talks to hardware via Windows APIs. This is in fact the normal approach and attempting to bypass the Microsoft APIs is fraught with danger. So in this respect, Ots is no different to other standard Windows applications out there.
Your comments about XP and Vista/7 are simply not correct. Since Ots uses standard Windows APIs, it makes no distinction between XP and Vista/7, except where APIs and/or capabilities have changed between those versions due to Microsoft developments (ie. just like any other Windows app out there). All of our development and testing is done on Windows 7 machines and this has been the case for well over a year now (probably more like two, starting with the Win 7 beta released in 2009). In fact, it's getting harder to find an XP box in our labs now. Of course we have them for various servers and systems, and still use them for QA, testing, etc. since it's still an Ots-supported OS, but your assertion that our software is designed around XP is just not true. In fact, it would ease a lot of headaches for us if we could guarantee that all customers would just use Win 7 from this point on and we could drop all legacy support for XP, but the market is not quite ready for that just yet.
As far as why a particular video card you used worked or worked better with XP drivers even though it was a Vista/7 system, well, you'd have to cast your attention to the manufacturer and the drivers. The way Ots talks to a video card is *exactly* the same, whether the system is XP or Vista/7. Manufacturers regularly make decisions like this and there's usually nothing an application can do about it. For example, I have an audio card in one of my systems which won't support ASIO under Windows 7 (using the manufacturer's official Win 7 drivers) but by installing older drivers it is possible to get it working. Why is this the case? Who knows? You'd have to ask the manufacturer. Creating drivers and getting official Microsoft accreditation for them (so they can be digitally signed) is not a trivial or inexpensive undertaking. Also, Microsoft chose to change a lot of things under the hood with Vista in both audio and video areas, which radically changed the respective driver models. It could be that for legal reasons (since Vista and above offers a protected audio/video path) the manufacturer chose to drop ASIO support because it was going to cost more to make it compliant with that, I don't know. The point is, these decisions are outside the scope of what an application can deal with. I can't magically make OtsAV talk via ASIO on this particular card just because I want to. Neither does this reality make OtsAV XP-centric.
While I haven't personally seen any need (ever) to install an XP driver on a video card to get it to work with hardware overlays, it wouldn't surprise me that this could be the case in some isolated instances. Microsoft have been gradually pushing away from overlays beginning with Vista since some aspects of overlay usage conflict with their Aero technology (that's why the Aero desktop is automatically disabled when the overlay is used in OtsAV, as the two can not co-exist - and no, it's not Ots that explicitly disables Aero, it's Windows). This is a shame, as the video hardware overlay is still by far the most efficient manner in order to get a full-screen raster onto a video head on most systems. To test this out for yourself, download the free VLC player and compare video smoothness and CPU usage while playing full-screen videos using the overlay and other methods (VLC lets you change in its settings dialog). I last conducted this test a few months ago on a Core i7 (heaps of grunt) and was surprised that even on this machine the hardware overlay was noticeably better and used substantially less CPU. Yes, this was a Win 7 box.
So what's the point here? Well, for one thing, Ots Labs is not trying to be sexy by always using the latest Microsoft new-fangled fad API, but rather we want stability, reliability, and usability. We want results and we get them. Of course if Microsoft ever phase out overlay usage altogether (and this certainly is not impossible, even if unlikely with the next Windows) then Ots will have to start using the newer API (already on Vista/7 and above there is a new Microsoft-recommended manner for delivering video output, the only problem is it has problems and doesn't perform as well as the traditional overlay!). But by the time the overlay is completely removed from Windows (if this actually occurs) then no doubt the alternative method would be more mature and Ots would be able to get the desired level of performance out of it. We'll cross this bridge when it becomes an issue. Right now it's not.
As you can imagine with our large customer base we receive LOTS of emails every day for various support issues, and hardware overlays not working on Vista/7 is not one of them! If there was even a hint of a problem (say, if even 1% of customers were experiencing this problem) then we would certainly look into it further. But that just hasn't been the case. The fact that you've raised it is even enough that we'll look into it again to some level, but at this point you are the only one who claims to have a problem that wasn't resolved with a simple driver update or by using a supported card. As others have said, we generally don't recommend on-board Intel graphics because as many have commented, they're just not that great for anything even slightly advanced. That said, even this was more the case around 2006/2007 and is not as true today as it used to be. More recent Intel graphics chipsets support hardware overlays perfectly. I haven't seen a recent laptop with Intel graphics that didn't work perfectly with OtsAV, though we still don't recommend them due to known earlier issues (and hence I'm not in a position to unequivocally state that all modern Intel graphics work fine - though I suspect they (mostly) do).
One thing you have to remember is the significance of drivers. I know I touched on it above, but consider this: the larger video card manufacturers like AMD (formerly ATI) and nVidia put out new driver packages almost monthly. Take a look at the bug list (I have, many times) and you'll see the kind of issues they're dealing with. Often it's a bug that affects just a specific game (or app) and this is the case even though the game is talking through the Windows APIs. You can't say "Oh, but game x works fine with the same card, so therefore game y must be faulty". No, these are cases where the video card driver is at fault and this has (eventually) been recognised by the manufacturer because it didn't support a particular capability properly or without error, and it just happened that other games/apps weren't trying to make use of that capability in exactly the same way even though it's entirely valid to do so. Video and video card drivers are extremely complex beasts. Even just throwing full-screen video out onto the screen (which you may intuitively reason is not as complicated as a modern 3D-game) is highly complicated in so much as that there are endless combinations in how to achieve it and the results will vary widely based on the chosen approach. Timing, colourspace, pixel-format, refresh rate mechanism, which underlying video technology API to use, whether to be low or higher level are all some of the design decisions that have to be made - and they all potentially affect the end user experience, quality, etc.
The reason OtsAV is chosen by solution providers and used in literally thousands of venues around the world to provide in-store music and deliver bar/pub music videos, etc, is precisely *because* of how stable it is, how reliably it works, the consistent output, the quality of the mixing, etc. These particular installations (which are just a fraction of our total customer base), are almost always automated environments, and so a single error, problem or failure would almost always result in a customer service call to the solution provider company and cost them money to resolve. They choose Ots because on top of the high quality, mixing, features, etc, they get the stability they need in order to remain in business and not blow it all on road visits or lengthy phone calls to solve problems. Think about it: if they could just use Winamp or some other free player instead, they would. Based on your comments alone, and obviously flawed perception of Ots, one would wonder how this is possible at all! But this is the *business decision* these providers make, and we're talking thousands of installations, so any little saving or problem here or there gets multiplied out to a significant gain/loss.
Some other comments that need correcting:
The IntelliFade (also known as ACI) mixing that all Ots Labs products have featured since 1999 has not changed since 1999! Your notion that it was downgraded or made worse when Automated Beat Mixing was introduced in 2006 is just not correct. The code that performs IntelliFade mixing is identical. It's actually the same algorithm that was first developed in 1997 and then brought to market in 1999 in OtsJuke DJ. You can prove this by running an older version and playing some songs and recording the output. Try the same sequence in a current version and you'll get an *identical* output (all other settings, levels, etc, being equal). When I say identical, I mean literally identical (not a single sample different). So how you get from this that the mixing was made worse after ABM was released is beyond us. In fact, still today, aside from stability the biggest advantage and selling point we hear about Ots is the mixing. Customers tell us every day! So while you're certainly entitled to your opinion on the mixing in general, your notion that it changed in 2006 is just flat out wrong, and provably so. And your opinion on whether it's better or worse than competitors is, well... interesting, since it flies in the face of what we hear every day. If what you say about Ots (in respect of the competition) is true, we wouldn't be continuing to grow every year (including this current year) in absolute sales numbers. And unlike some other companies, we haven't had to drop our prices or even make our flagship product free. In fact, we recently increased some of our prices slightly due to the extremely weak US dollar.
ABM is used extensively by many DJs, radio stations and solution providers, including with some large market-leading music libraries out there (ie. they encode every dance/etc song in their library using the Ots ABM system - which they obviously wouldn't waste time doing if it wasn't worthwhile). I'll freely admit that we have further enhancements we are bringing to the ABM system, but this could be said about most aspects of our software. We are always looking to improve things, except in the few areas where it's really clear nothing much more can be done. But I have to say, if you don't find the ABM usable, then either you're not playing the kind of music that it lends itself to (music that club DJs would typically mix) or you're not using it right. It does take some effort to set up and it's therefore not for everyone. But it's an additional tool like many things, that if you invest some time and effort into, you can be repaid many times over with awesome results and/or time and effort savings.
I won't delve deeply into your latency claim here, as this post is already getting quite long, suffice to say that this too is nothing that is seen on a healthy system. Controller latency is mainly a function of the USB subsystem within Windows, and of course the respective responsiveness of both the controller and the host app. OtsAV does everything it can to be as responsive as possible and our tests and customer usage reflects this. For a technical example (will probably only be interesting to any developers reading this), some apps route all controller messages through their app's main Windows GUI thread. This has the potential to be a bottleneck and introduce additional delays, and Ots definitely does *not* do this.
I'll readily agree that OtsAV lags behind some other players in respect to the presence of certain features, but then again, this is all a matter of what a customer requires. For some, sure, it may be eg. time-coded vinyl (something which Ots may support one day, but is not a high priority) while for others it may be automation, mixing, audio and video quality, stability, our ABM approach, dynamics processing, whatever. We live in a world where the customer has numerous choices and this is a great thing! We don't pretend to be everyone's cup of tea, but as long as we're growing, receiving overwhelmingly positive feedback (and hence meeting the many and varied needs of our customers as best as possible) and most importantly of all, staying true to ourselves and our vision of the ultimate playout solution, then we feel we're on the right track. We have some very exciting things on track for this year and next, some related to OtsAV, some outside of it. We have never been a company that aspires to have every feature under the sun at any cost and that philosopy has not and will not change. We personally feel it's too distracting. We'd rather do what we do do very well, and leave other things either a/ until we are ready to do them and know we can do them well, or b/ for others to do if those features do not fit into the core Ots design philosophies. We won't apologise for this. We feel strongly after 15 years in this market that we are doing many things right. Each individual is free to choose whichever companies/philosophies suit them best and make their purchasing decisions accordingly, and we're cool with that. Some people hate Apple like it's a disease on the world. Some love them more than their closest friend. Does Apple really care?
Finally, on the point of features announced more than a decade ago for the 2.0 release, here's the status: Ots fully intends to, and will, release those features as stated. As to why it's taken so long, you have to realise a few things about the world: It's changed a lot since 1999. People have different expectations than they did back in 1999 and use their playout software in ways not even dreamed of then. Ots can only do so much. We choose to please the majority of customers the majority of the time. Naturally there will always be people who would prefer a different decision were made, but this is always the case in life with any group or organisation. Of course if we'd focussed 100% on just the features specified at that time, they'd have been completed many many years ago, and the fact that they haven't (all) been, is an easy thing to pick at if you're being picky or looking for a cheap shot. But we'll wear that, because the reality is we hear feedback every day from our customer base and this carries a lot more pertinent information than just a single thread here or there in a forum like this. Yes, there's a few remaining features required until we reach the official 2.0 status, but of more relevance, there's a wealth of very substantial features (full video, MIDI, the whole Ots media library system, OMQL, etc) that were never "promised" as such, but which hold far more value to (most) customers than the at-that-time listed planned features. If it weren't so, we wouldn't have gone about things or prioritised in the way we have. Why would we sabbotage ourselves?
Of course we'd love to have the other features completed (and it's likely we will, not *too* far from now), but the reality is, had we put out a 2.0 say, a few years ago, most people would think "so what". Times had changed and people were looking for video, hardware controller support, etc, etc. Only a small fraction of people care about "time-coded lyrics" for example. I'm not saying that the remaining 2.0 features do not hold merit, some do more than others, but the fact of life and business remains that you have to make choices. Things change. We won't back away from our earlier assertions and we *will* deliver because it's the *right* thing to do, but the overwhelming feedback we receive is that the vast majority of people don't care less about (most of) those remaining features and we've prioritised our decisions and product development in order to deliver the maximum value to the maximum number of valued customers. And look on the bright side: Everyone who bought one of those "free upgrades to 2.0" licenses back in the early days has not had to pay a single cent for an upgrade since that time (and there's been over 40 upgrades). Not too many companies allows free upgrades to span such a lengthy time. Those people know they've done well. We know, because many of them tell us. Many paid just $59 or close to that amount and they're still receiving upgrades and latest versions with substantial new functionality (costing Ots Labs millions to develop) over 10 years later. Come on, who's going to complain about that? Which is why we don't hear people claiming that they didn't get value for money (even among those who are waiting on a particular feature). And anyway, the next release is going to be very exciting and will remove at least another point from the 2.0 features list
Thanks again for your comments Bob. I realise you hold some strong views and it's good that you've chosen to share them as it provides a timely opportunity for us to point out a few things. No hard feelings and if you are not impressed with the next release and/or we can't help you solve the video output issue, then we sincerely wish you all the best in your future endeavours and with whatever tool you choose to go with. Thanks for your business thus far.
Best regards,
Adam Ots
Ots Corporation
Ots Labs
P.S. In light of your comments about Ots support I've reviewed the correspondence you've had with our technical support department and haven't seen anything out of line, although I did notice a lot of hostilities coming from you. If you feel you haven't been treated appropriately please explain why and how this is the case and we'll try to resolve the issue. Unfortunately, if you're looking for an easy answer that can make your card work, this may simply not be possible. I realise that is obviously frustrating, but there will be a logical answer which you may or may not wish to pursue (could be a driver problem or straight out card incompatibility on that hardware - would be rare for ATI, but on PCs anything is possible! - could be some other conflicting software you're running as part of your standard setup, or any number of things really). Anyway, it's certainly not normal or typical, and if you wish to go further we will continue to try and help you further - but you have to accept that it may involve a different video card or trying a different driver, etc, and it would be helpful if you try to stick to the core issue rather than directing "unnecessary" comments at our support staff. Thanks.