Quote:
Even though we can't tell you everything, we still consider it very important to be present and keep interacting with our customers, even if we can't tell them what they are wanting to hear.
And honestly, while they may not express it, I'm guessing that most of the people here think it's important that you're all around, too. You all offer more help than automated reply systems, and it gives at least some people confidence that our ideas are being read by
somebody within the company. Thank you for your detailed reply, by the way.
Quote:
Quote:
But when you say that the hardware support is only halfway-implemented, do you mean that only half of the controllers will function with it, or that nothing will because not all of the features are properly implemented yet?
What I meant by that is, if we try and send out the software too early, you will have incomplete features, for example: a Rane Sixty-Two that is connecting and mapped to the software, but the audio part isn't complete.
Doing this is out of the question, because the first bug report we will see is "No Audio".
Quote:
Put a very loud, obvious warning on the download link (or, alternatively, hide it in the forums somewhere where you can't get it without bypassing a warning of some sort) that it will only work for a select few controllers and that it is in no way meant for performance use, but rather just for preliminary feedback for 1.6.
What you have just described is the whole intention for Public beta. When the software is available in December, that is not the final release date, that IS when the preliminary feedback for 1.6 begins. The difference is, we intend for it to be ready to be used by all supported hardware. We will be cautioning people to not use it for performance during the beta phase, but no matter how clear we make this, people still use the beta for performances, so we have to expect this, and try and deliver the software as complete and stable as we possibly can.
You make good points. I've seen enough cases of user error and didn't read the friggin' manual/warnings to sympathize with not releasing an alpha version with very limited hardware support. The reason I'd suggest an alpha release would be mostly to see if people like any changes in the GUI or settings - stuff that doesn't necessarily relate to controllers, as well as to appease the impatient masses you see on here. I know that coding takes time, and as DJ Nyce said(
serato.com), every week counts. But like you said, the first bug report (and about 500+ after that) would almost certainly be "No Audio," because people are impatient and/or don't pay attention to/understand the warnings.
Of course, if this is largely a stability and compatibility update to prepare for users moving over from ITCH, then there's hardly any point to an alpha.
Quote:
We have already announced which hardware will receive Serato DJ support in December, but regarding other features, we always stay pretty tight lipped, as do most software companies. This is for many reasons, but one of the big ones that spring to mind is this example:
We announce in advance that you will receive "Feature X" in Serato DJ 1.6 forthcoming. During development stages we encounter a huge technical problem that means Feature X is more work than expected. We now must choose to push back Feature X to another release or have Features Y and Z suffer.
We release the beta and subsequently the final release and Feature X is not available. Forum flaming commences.
I absolutely understand that. Maybe I'm just used to community- and independently-developed projects where it's more or less accepted that a planned feature list is very much subject to change. I suppose that isn't quite as accepted in the professional world (I went from the Mixxx project to a relatively brief stint on Traktor to this. Fun fact about Mixxx: it took them at least an entire year to roll out one update. Granted, it relied on people who could work on coding it without compensation - that's how they kept it free - and they were short on coders for a while. But for those of you who complain about how long it takes Serato to roll something out, realize that adding new features or improving old ones can take quite some time, even if you have the code for it already.
I've done some coding in my life (not much, but enough to know how painful it can be), and I know that adding features can be a massive pain. As in your example, all too often, one thing is added or fixed, and something else breaks. People wonder why Microsoft has to release updates for Windows so often, and one of the biggest reasons is that patching one security hole often opens up more unforeseen holes. If this wasn't the case, they'd have had these holes all patched up within 3 months of Windows's release. The same applies for any complex program. You go to add/fix one thing, and something totally unrelated breaks. When you revert the changes you made, it works perfectly. Additionally, even if they had code for it from other pieces of software, there's no guarantee that code will even work in SDJ.
Say you want to bring over a feature from ITCH (I've never used ITCH, so you'll have to use your imaginations here). Sure, Serato has code for that feature, but that code might rely on core code that SDJ doesn't have. Yeah, the dev team might be able to just copy the applicable code over and make the feature work, but that isn't a stable way to do things, and the last thing you want as a DJ is for your software to crash in the middle of a performance. So the dev team typically doesn't have many choices when bringing a feature over. They can slowly and carefully implement highly requested features and make sure they function safely, or they can quickly and haphazardly copy the necessary code over, make any fixes that need to be done to adapt it with spit, gum, and prayers, and then toss the results at us. Before you blow up on the support staff about how long something takes, think about it this way: is that feature so important to you that you'll risk SDJ crashing on you in the middle of a set? I'll admit, there are feature requests on these forums that I feel are taking way longer than they should to be put in, but there are reasons for putting things off, whether they tell us what they are or not.
I'm also willing to bet that the dev team is at least a little hesitant to start implementing a bunch of new features before they are finished with (or are close to being finished with) increasing hardware support. Taking things one step at a time may not be the fastest way to do things, but it is one of the safest. If you add too many features to a program at once, you might end up banging your head against a wall trying to figure out which piece is causing problems. If they finish stabilizing the program for different pieces of hardware first, they'll likely have fewer problems down the line when adding features. We may have to wait a few months before they even start adding features. If we're lucky, they have a couple of coders working on our requested features. My guess? They're focused on getting hardware working more than anything else right now. I'm not saying that the wait isn't frustrating, because it can be. But Serato has a reason for what they're doing right now.
Martin explained perfectly why they can't make promises: if they do, they risk getting flamed by people who don't realize that dev teams aren't perfect. All too often, awesome things end up getting cut out of programs and games at the last minute because they just can't get them to work right in time for release, or there are more important things to work on, or that feature turned out to be far more complex than they initially thought, and it wasn't worth their time.
My advice for now?
Please lay off the support staff. They're people too, as are all other customer support agents. They don't like getting yelled at any more than you or I, and being a jerk to them isn't going to do you any favors. Put out feature requests, vent if you have to, but don't go off on them. They tell us what they can tell us, and from what I can tell, they do what they can for us. Now then, I've got somewhere to be, so there are my two bits. Sorry for that wall o' text, everyone.
