Difference between posting feature requests here and on Centercode?
Difference between posting feature requests here and on Centercode?
Just curious, whenever I've contacted Ableton Support to report what I thought was a bug and was, in fact, an unfortunate feature, they asked me to submit a feature suggestion over at ableton.centercode.com, which I did, but then there's also this forum. Does Ableton keep an eye on both? Which one "matters more"?
-
- Posts: 902
- Joined: Sat Dec 30, 2017 3:36 am
Re: Difference between posting feature requests here and on Centercode?
Probably more important is centercode because of the voting system. But they scan here for ideas from what I understand.
Re: Difference between posting feature requests here and on Centercode?
Thanks. I suppose I could just copy paste what I post on Centercode here for users who are not on Centercode to see and comment.jonljacobi wrote: ↑Sun Sep 26, 2021 12:14 amProbably more important is centercode because of the voting system. But they scan here for ideas from what I understand.
Re: Difference between posting feature requests here and on Centercode?
Both are monitored, but center code has the added benefit of letting other users vote for your suggestion if they find it useful too. Sometimes (but not always) that can help push an idea to get more attention.
tarekith
https://tarekith.com
https://tarekith.com
Re: Difference between posting feature requests here and on Centercode?
I'm just not sure how many users there are on Centercode vs this forum, but I think it's a small crowd. About the voting system, this forum allows poll creation, the only difference is that the poll is not created automatically.
I've emailed quite a few bug reports direct to support and they've been quick to acknowledge them and some were fixed in the next beta. Features, on the other hand, can take forever to implement. If the number of votes is what decides what's implemented and what's not... that scares me. There are many small and simple features that, if implemented, would significantly enhance workflow. These small features are often very simple and don't even require any GUI modifications. I am a big fan of small workflow improvements because those are the ones that truly make the software a joy to use, but most users are interested in the big flashy features.
I've had some luck presenting feature requests as "inconsistent behaviour" directly to support. If cleverly worded, it works some times. One such feature request was to improve knob mouse sensitivity. Some knobs which only have a few values turn very fast and are very difficult to turn without overshooting (because one mm of mouse travel covers the full knob range...), while knobs that have a greater range of values turn at a more user-friendly speed. I reported this once and was told it was a feature and some reason why it was like that. I reported it again in a slightly different way and finally they agreed to look into it. And that's the thing, a request to improve a poorly implemented feature that doesn't prevent the software from doing its job can be considered a feature request, but it can also be viewed as a UX bug.