live 8.1.3 : were any of the 'suite' packs updated?

[pepezabala]

man, I want changelogs, too.

Looks as if ableton has become a normal company that needs to hide what's going on inside of the corporation. Before it was this bunch of friendly dudes from berlin that shared their sequencing tool with you, including dvelopment and testing. This "music-software made by musicians like you"-attitude. Now it's "a crashing DAW made by a normal company like all the others". Sigh.

[orgul]

man, I want changelogs, too.

Looks as if ableton has become a normal company that needs to hide what's going on inside of the corporation. Before it was this bunch of friendly dudes from berlin that shared their sequencing tool with you, including dvelopment and testing. This "music-software made by musicians like you"-attitude. Now it's "a crashing DAW made by a normal company like all the others". Sigh.

+1

[102455]

[yawn]

Get over it.

Talk about nitpicking....

[posssu]

I always liked the changelogs, they were very open of a developer to share that info. They were always funny too:

"When you turned a midi controller of a certain manufacturer and Live was in maximized or other state, something would happen for a few users. - Fixed."

Indeed, but they were also terrifying and confusing, for exactly that reason.

If a user reads something like that, they wonder if it could have been happening for them. Particularly, we were concerned about things like:

"In certain situations, Live could crash when dragging a clip."

This is horrible to read, because it sounds like something was really wrong. But in fact, those "certain situations" were incredibly specific hypothetical test cases that no normal user would EVER come across.

The only other solution would have been to write multi-page technical explanations of every fix - which still wouldn't have helped most users.

So, for now, we've decided to not post anything.

Best,

Dennis, the downside of this is (like I posted earlier) that some bugs take a lots of effort to "try out". It's not that with every bug you just click a button and then see if it's still there, but it can still be a very annoying bug that appears when you least need it.

Now you are forcing users to test this bug after every update even though in your internal list this bug might be four small updates away. This is really much work for those you want to hunt bugs for you and may also backfire for your developing efforts by you not getting so snappy responses on fixes. I don't think everyone wants to test all the worst bugs after every single update.

This is why it would be good to get changelogs. It's not only nerd data, it's very valuable for those who actively want to report bugs about your software to see if you've tried to fix it in the latest version.

I don't think it's so horrifying to read "Live crashed when dragging a clip in certain circumstances". It might be something I've never met and if I have, I'm just glad it's now fixed. Sure, it would be bad to read on the ableton.com frontpage, but this is forum and also people who want to make your software better.

We're just happy to read you've fixed things.

[3phase]

[
If a user reads something like that, they wonder if it could have been happening for them. Particularly, we were concerned about things like:

"In certain situations, Live could crash when dragging a clip."

This is horrible to read, because it sounds like something was really wrong. But in fact, those "certain situations" were incredibly specific hypothetical test cases that no normal user would EVER come across.

aha.. ok i see.. you are ashamed of all the bugs... because i had some of theese incredible specific hypothetical test cases on stage...

i can understand that the amount of complex interwooven bugs is nothing you really like to show..especially in a situation where people have started to make fun about the lenght of the bug list or thinking about printing t-shirts with your bug logo..

But i dont know if hiding is really the best thing to regain trust..
You should be proud of the bugs fixed..
And users learn from the crashbugs what strange combinations can cause problems,,or even learn to test the program better when beeing your betattesters again..

Print your own t-shirts with your little bug ( i would buy one )
Or better..you can use the shirts to motivate your free betattesters.. one shirt for each bug !!!

And have them on the splash screen.. they defently look better than the instrument salad...especially than the grey instrument salad the suite users have to suffer from..

So dont hide it.. do it like the gouverment... bring it upfront. and nobody will talk about it anymore..

Or do it like in the past.. Do a changelog but just leave the fixes out that you you dont like to talk about... nobody or just a few would have realized...
Now everybody is curious what you try to hide..and that is really confusing

[Dennis DeSantis]

Dennis, the downside of this is (like I posted earlier) that some bugs take a lots of effort to "try out". It's not that with every bug you just click a button and then see if it's still there, but it can still be a very annoying bug that appears when you least need it.

Indeed, but the complexity of reproducing certain bugs is another reason why changelogs simply might not help. There are certainly situations in which we fixed something that was clearly a bug, and which MAY have caused a particular behavior - or even crash - for a particular user. But as it turns out, that user's issues were caused by something else. So they read in a changelog that their bug is fixed, find out that it isn't, and are more confused than ever.

In this case, again, the only thing that works is to use the software.

Best,

[deva]

Dennis, the downside of this is (like I posted earlier) that some bugs take a lots of effort to "try out". It's not that with every bug you just click a button and then see if it's still there, but it can still be a very annoying bug that appears when you least need it.

Indeed, but the complexity of reproducing certain bugs is another reason why changelogs simply might not help. There are certainly situations in which we fixed something that was clearly a bug, and which MAY have caused a particular behavior - or even crash - for a particular user. But as it turns out, that user's issues were caused by something else. So they read in a changelog that their bug is fixed, find out that it isn't, and are more confused than ever.

In this case, again, the only thing that works is to use the software.

Best,

Or not use the software... By that I mean, I get used to not doing certain things that cause problems and if Ableton does not inform me that something is potentially fixed, I will assume that it is still broken and keep using the software as if it is still a problem cause I know that is safe. I downloaded 8.1.3 but have not installed it and not knowing if it fixed anything relevant to my use of the software, I feel no hurry to do so. Live may have certain issues that I have learned to work around and Live is solid enough for me to work with but I would not rave to friends about its stability. I may tell other users my experiences that doing X action can cause a crash. That may no longer be the case but I have no convenient way to know if I stick to my working habits within which Live is working well enough... not great, but well enough that I just get on with making music.

I would think that Ableton would want to inform users what has been fixed, but if not, that is your choice. Cheers...

[davepermen]

Dennis, the downside of this is (like I posted earlier) that some bugs take a lots of effort to "try out". It's not that with every bug you just click a button and then see if it's still there, but it can still be a very annoying bug that appears when you least need it.

Indeed, but the complexity of reproducing certain bugs is another reason why changelogs simply might not help. There are certainly situations in which we fixed something that was clearly a bug, and which MAY have caused a particular behavior - or even crash - for a particular user. But as it turns out, that user's issues were caused by something else. So they read in a changelog that their bug is fixed, find out that it isn't, and are more confused than ever.

In this case, again, the only thing that works is to use the software.

Best,

Provide the information, and let the users decide if they want to read them. for those that get confused, it's their choice and fault. i would read it and not get confused. others don't care and don't read it.

provide information. let the user fail on putting it to good use.

[H20nly]

^ that creates a loop that just comes back to Ableton. The user gets "confused" and the next thing you know there's an angry thread or flurry of angry posts... plus questions that have to be answered via email, phone etc.

I see your point. There's no denying it... However, I can see the point from the business side too.


In the end... a stable platform fixes most of this monkey motion.

[Dennis DeSantis]

Hi folks,

Thanks for the feedback. We're now preparing release notes.

Best,

[glitchrock-buddha]

Hi folks,

Thanks for the feedback. We're now preparing release notes.

Best,

Well, no matter what anyone says about Live 8's stability, I think everyone can agree that you guys are very responsive to feedback, so hats off for that.

[ccombe]

whilst I understand the reporting of bugs being fixed can raise even high level stuff is enough to keep people happy.
e.g. fix - simpler issues

there is a reason why we all love and use Ableton, its because you guys do listen!! so thankyou, problem is my downloads are capped until Sat night so I will have to wait until then booo

i am keen to test one bug I had where if I move a channel in the arrangement view whilst playing the song Live would crash and I could repeat this every time.. the program would crash, live would not be able to recover the lost work.. so now I just work around moving channel order until play has been stopped..

much love!!