Hello,
When using the faders on the mixer, it would be helpful to see numerical levels. Is this a feature that exists that I am missing, or is it not implemented?
A use case would be if we have several tracks that we want at the same, non-default level, it’s pretty hard to get them to be at the same level just by spot-checking them visually, especially if they are not adjacent.
Thanks,
David
You’re not missing anything. It’s been requested, and I agree it would be helpful.
Ah, apologies for the duplicate request! Is there a place to view existing requests / roadmaps etc. outside of searching through this forum / google (which I did before posting this)?
No, you don’t need to worry about posting duplicate requests. I read every single post on the forum (and other members of the team read a good number of them too) and it’s no problem to see something requested more than once. In the near future these forums will be moving to a new platform with rather better search facilities, so hopefully it will be quicker and easier to find existing threads on a given topic.
Hi Daniel - thanks for the response. I think it could be useful to have something like a voteable feature request board that will make it obvious what the most commonly requested changes are. Is this something you’ve considered?
Similarly, it seems there is a policy of not telegraphing product roadmap before things are locked down. Is this something that you may eventually evolve?
I shouldn’t answer for Daniel, but both of these have been suggested in the past and pretty definitively declined.
Although I’ve often said it, and normally with my tongue in my cheek, our development priorities are not determined by a democratic process, and so having a system of voting for particular features would actively be at odds with the way priorities are determined. There’s no way that such a system could be representative of the needs of the userbase as a whole, the vast majority of whom don’t participate in forums like this one, and while you might think that those users who are more engaged in the community should therefore have an outsized say in determining the future direction of the software, we don’t tend to think in those terms. Plus if we were to determine our development priorities based solely or even primarily on things requested by our existing users, there’s every chance that we would fail to implement things that people who do not yet use the software would want or require in order to start using it. And a prioritised list of requests from users that we are expected to implement in descending priority order may also be the most inefficient way to develop the software, without the freedom to decide to work on a bunch of related things at the same time. Plus, users tend to request what they think of as specific solutions to their underlying requirements, but good product design requires us to think at a deeper level about those underlying requirements in order to come up with the most appropriate solutions, which will (hopefully usually) be more elegant than the solution that came to a particular user’s mind.
All of this is a very long way of saying that, no, we have no plans for a voteable feature request board. But you can rest assured that we do listen extremly closely to our users, both here on this forum and in all of the other myriad ways in which we receive their feedback, and we try to take as wide a range of user types, needs and requirements into account as possible when planning our future development.
As for publishing details of our future roadmap, no, we have no plans to do this. Firstly, notation software is a small but competitive niche and over the years we have seen on countless occasions that imitation is the sincerest form of flattery. I would prefer not to give our competitors a headstart in what they will inevitably crib from us. Secondly, software development is hard, and it’s entirely possible for a good deal of work to be put into a feature area only for that work not to translate into something that we can actually ship. (This is no purely academic concern. It has just happened, for example, with this week’s Cubase 11 release, and due to a beta tester breaking their non-disclosure agreement back in the summer and leaking information about a new feature that was included in alpha and beta versions of the new version, there was some expectation among Cubase users that a particular feature would be included in this new version, but it had to be decided a few weeks ago to delay the introduction of that feature, creating dashed expectations and disappointment when Cubase 11 was released, instead of users being unreservedly delighted with all of the amazing new features that have been introduced.)
So we are as open as we feel we can be about what we are working on, and our plans. Just in the last few days here on the forum I’ve said, for example, that the next major version of Dorico will come in 2021, it will very likely require macOS 10.15 Catalina as its minimum supported operating system version on macOS, and that it will include Universal Binary support for the new Apple Silicon-powered Macs. All of those could end up not coming to pass, in which case I will look pretty stupid and potentially cause upset and disappointment among our users. But we hope that this information is nevertheless in some way useful so that our users can plan things like hardware and software upgrades for the year ahead.
But when it comes to functionality in the software, I prefer not to say that something definitely will make it into the next version of the software, unless it has already been implemented and passed our internal testing process. Even then, I will normally choose to keep my powder dry because we don’t want to make it any easy for our competitors – who are closely watching everything we do – to try to close the gap that Dorico is leaving as it steams ahead of their products.