Interesting interaction with Ableton 10 bug report staff

[jonljacobi]

Whatever the import support, it should not lock up the program. I'm guessing infinite loop.

I'm guessing didn't RTFM. Why would they take the time to fix a problem that only exists for users that don't bother to check compatible formats that they've already told you about?..twice.

I did read the effing manual. A program shouldn't lock up not matter what the user does, educated or no, logical or no. That's pretty much taught on the first day of coding 101, not to mention a point of pride with any decent programmer. I'm guessing low standards.

[shonky]

I did read the effing manual.

Not the bit about Sampler and compatible formats then? Or the same blurb on the Ableton site?

A program shouldn't lock up not matter what the user does, educated or no, logical or no. That's pretty much taught on the first day of coding 101, not to mention a point of pride with any decent programmer. I'm guessing low standards.

Thing is though, I've personally never had an issue with Sampler unless I've moved or deleted samples. I've loaded up EXS24 instruments, and other compatible formats and never had an issue. I have however had issues with Kontakt crashing in Ableton, which could be attributed to Ableton's implementation of 3rd party software or might be a problem on the Kontakt side (most other NI plugs work without a problem).

[jonljacobi]

It's hanging up reading a file. Kontakt did change their file format, which is the issue. However, there should be check code to see if the file is the older type, or, failing that, a timeout on the loop that's trying to read the file. Programmers don't like timeouts or lots of error-checking because they slow things down, but it's the only thing that will keep a program from locking up. I'm guessing Native Instruments doesn't want to share the info on the later file structure, as apparently nothing else can read them either.

Again, it's not about the "not loading", it's about the fact that it locks the program up. And it doesn't make any difference what files are compatible, a program should not lock up because of user error. Period. End of story. This is a 100% iron-clad rule of software and interface design and anyone who has been involved in software development (CEOs and CFOs excluded) will tell you that. Why? Because eventually, someone will make said error.

I'm not trying to slam Live, it's a great program, IMHO, the best thing out there. So no one needs to defend it. But in this instance, the dismissal was annoying as hell. And my bug report was quite clear on what was happening. Everyone makes programming errors, not fixing them after years of reports is inexcusable.

[Romantique Tp]

This is a silly thread but OP is right. DAWs shouldn't crash regardless of what the user does.

[Jace-BeOS]

This is a silly thread but OP is right. DAWs shouldn't crash regardless of what the user does.

No software should crash just because the user operates a switch or menu that's provided by the software. Developers should be trying to break things and then creating handlers for those cases. Fault tolerance and protection of user data (and system integrity) is supposed to be a basic core component of being a programmer (at least where people actually had formal instruction or read quality books on programming practices). Today, the decades of zero accountability in the computer industry, and the mob mentality of tech geeks eager to feel superior to "lusers", has resulted in the same level of quality control present in one-man weekend hobby programming projects seemingly becoming the default model for all products, with apologists throwing special pleading illogic at any people offering legit criticisms of broken software, effectively turning all responsibility onto the users (including paying customers). Then there's the DRM.

Okay, the above is a little hyperbolic, but the way so many tech people act, throwing "it's your fault" barbs at users critiquing software (whether beta or final commercial releases), and the way developers act like they cannot be bothered to deal with the last 10% (90%?) of the work (or the basics, sometimes)... it's not far off. Computers are like a religion. It can't be your belief in your god that's wrong; the heathens just aren't praying right.

[pottering]

This is a silly thread but OP is right. DAWs shouldn't crash regardless of what the user does.

No software should crash just because the user operates a switch or menu that's provided by the software. Developers should be trying to break things and then creating handlers for those cases. Fault tolerance and protection of user data (and system integrity) is supposed to be a basic core component of being a programmer (at least where people actually had formal instruction or read quality books on programming practices). Today, the decades of zero accountability in the computer industry, and the mob mentality of tech geeks eager to feel superior to "lusers", has resulted in the same level of quality control present in one-man weekend hobby programming projects seemingly becoming the default model for all products, with apologists throwing special pleading illogic at any people offering legit criticisms of broken software, effectively turning all responsibility onto the users (including paying customers). Then there's the DRM.

Okay, the above is a little hyperbolic, but the way so many tech people act, throwing "it's your fault" barbs at users critiquing software (whether beta or final commercial releases), and the way developers act like they cannot be bothered to deal with the last 10% (90%?) of the work (or the basics, sometimes)... it's not far off. Computers are like a religion. It can't be your belief in your god that's wrong; the heathens just aren't praying right.

Where did anyone say that Ableton does not take care of protection of user data (and system integrity)?

In fact it does it better than most other DAWs as it is non-destructive by default.

Fault-tolerance has its problems too, is not the perfect model.

Since Live is used in live performances daily, there is a strong argument it is better for it to have zero tolerance of errors in third party plugins and proprietary file formats, so those don't get used at all after being tested in rehearsals or earlier.