We need a list of the 3rd party stuff that works well

[Sibanger]

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.

Now I understand.

You make too much sense Machines.

(I take back the name and shame cheap arsed remark)

[dum]

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.

'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.

[leisuremuffin]

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

like that, kind of?


.lm.

[dum]

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

like that, kind of?


.lm.

yep just like that only inclusive of all issues - native & 3rd party - not just plugin quirks.

I assume because SAMPLER isn't an au/vst, it's unpredictable incompatibility with NKI libraries wasn't documented. Other than people bug-reporting or bitching about it in the forum at the time.

[Machinesworking]

'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.

The problem I believe comes in how to implement it without pointing fingers or being accused of etc.
Four years ago saying Reactor on Mac was buggy was true, it isn't now, at some point the list has to be updated, probably damned near every day. With 2000 odd plug ins, and at least 100 developers, plus two OS's with updates/upgrades, three plug in formats, and dozens of possible combinations of hardware and drivers, it becomes a nightmare to manage. I suppose if each dispatch had a specific date and a disclaimer stating that it's quite possible that a recent update has fixed X problem,...
NI as you mentioned, used to publish a projected update schedule (Battery 3 is due in late May 08 etc.) even with a disclaimer stating it was a projection people would get mad, just pissed. Say 50 people have a PC set up that includes drivers that fuck up Trilogy in Live, is that enough people to add it to the list? Those 50 people will definitely be stomping around forums etc. dogging Ableton etc. for dodgy practices.... Unfortunately IMO it's one of those things that goes unsaid, when it's bad news, the more developers open their mouths the more people attack and condemn.

The NKI thing and Sampler import issue you had was just lame, Ableton blew it on that IMO, no way around that.