Ableton Forum

Machinesworking wrote:The main problem with a list of buggy software is the simple fact that software changes all the time, updates and upgrades happen.
NI are a great example, Reactor was a buggy piece of shit on Mac, and fine on PC pre version 4. Now there's no issues.
Battery has had issues with Live on and off, depending on updates seemingly from either side. Another example is OS issues. OSX 10.3 and the quad core G5's, nothing in the OS was in place to utilize all four cores, or it wasn't well implemented. FXPansion's BFD drumkit would crash, but explain to a person that believes that the Mac OS can't have issues this? Same goes for Ableton, some part of their code could be buggy in an update, and it's possible that it could be Ableton, and not the way the developer wrote the VST/AU. It's something though where it only affects a certain plug in that utilizes some obscure VST/AU resource, and gets fixed in less that three months, should Ableton publically hang themselves for it? or should the end user not use that plug in until it works? What I'm getting at is a list would have to be maintained EVERY DAY, there would have to be full disclosure of who was at fault, and it's not even a matter of discussion that when a bug emerges if it's not immediately obvious who's fault it is, the finger pointing is going to be pretty fast furious and stupid. What if there's a change in Windows 7 say, that's documented but not obvious, and both plug in and DAW manufacturers get it slightly wrong? The finger pointing would be retarded. I'm OK with that being a behind closed doors thing, and if there was a list it would by necessity HAVE to be a non involved third party.

Now known issues with a singular combination that are consistent and documented by both sides would be cool, but those are rare. I can only think of the IK bug off hand where it was that straightforward. Even with the REactor problems I had, I used Reactor when it was buggy, just not in a live situation. So in the end it's still up the to user. <-- I see no way around that by a list, as human beings tend to ally themselves with DAWs, plug ins, OS etc. so the list would be IMO impossible to keep straight and not biased.

Machinesworking wrote:The main problem with a list of buggy software is the simple fact that software changes all the time, updates and upgrades happen.
NI are a great example, Reactor was a buggy piece of shit on Mac, and fine on PC pre version 4. Now there's no issues.
Battery has had issues with Live on and off, depending on updates seemingly from either side. Another example is OS issues. OSX 10.3 and the quad core G5's, nothing in the OS was in place to utilize all four cores, or it wasn't well implemented. FXPansion's BFD drumkit would crash, but explain to a person that believes that the Mac OS can't have issues this? Same goes for Ableton, some part of their code could be buggy in an update, and it's possible that it could be Ableton, and not the way the developer wrote the VST/AU. It's something though where it only affects a certain plug in that utilizes some obscure VST/AU resource, and gets fixed in less that three months, should Ableton publically hang themselves for it? or should the end user not use that plug in until it works? What I'm getting at is a list would have to be maintained EVERY DAY, there would have to be full disclosure of who was at fault, and it's not even a matter of discussion that when a bug emerges if it's not immediately obvious who's fault it is, the finger pointing is going to be pretty fast furious and stupid. What if there's a change in Windows 7 say, that's documented but not obvious, and both plug in and DAW manufacturers get it slightly wrong? The finger pointing would be retarded. I'm OK with that being a behind closed doors thing, and if there was a list it would by necessity HAVE to be a non involved third party.

Now known issues with a singular combination that are consistent and documented by both sides would be cool, but those are rare. I can only think of the IK bug off hand where it was that straightforward. Even with the REactor problems I had, I used Reactor when it was buggy, just not in a live situation. So in the end it's still up the to user. <-- I see no way around that by a list, as human beings tend to ally themselves with DAWs, plug ins, OS etc. so the list would be IMO impossible to keep straight and not biased.

leisuremuffin wrote:http://forum.ableton.com/viewtopic.php?f=2&t=25171

like that, kind of?


.lm.

dum wrote: 'known issues' means exactly that.
issues, which are known to ableton.
It's not a 'we suck' list. or a 'our flaws' list.
If they know of any incompatibility - whether it's their fault or native instruments (for example - could be any third party) fault, it is courtesy to let their clients know of the issue. It's not a radical idea, I deal with several prestigious audio devs who provide changelogs and known-issues lists. Sure, it's not entirely flattering, but it's not always damning either. I don't care who's at fault - I want to know in advance if there's a reasonable chance the NKI library I'm about to buy won't work with SAMPLER.

It's no extra work to compile such a list, because it's a 'known' issues list. by definition they know about it.