A dorico feature voting system?

I’ve read that the team prefer reading just one forum. I know cubase recently published the results of a feature survey. I’m wondering would Dan and the team follow with something similar? I can imagine how hard/annoying it is when people ask “when will dorico be integrated with cubase” etc etc. And I know this isn’t cubase, this is a very special forum and the way dan and the team respond to each user is astounding. Just thinking out loud…

This has come up before, and the decision was to keep the format the way it is currently.

And specifically, while the Development Team takes note of users requests and comments, they have said explicitly that the timing and selection of features is not subject to a survey or vote.

Considering what the Team has done already, I think it safe to say most users support that approach.
One has to take into account that Cubase is a product with much greater longevity and thus farther along its initial roadmap.

farther along its initial roadmap.

:smiley: did they even have roads in those days?

It’s not annoying when people keep asking for new features.

What is really annoying is when they stop bothering to ask, because nothing ever gets delivered.

Sibelius tried a “voting” system using the Ideascale website. it died, and Avid have now officially abandoned it.

They did, but they may have been made of cobblestones, which is why some (mistakenly) suppose the Cubase program was just cobbled together. :smiling_imp:

Nothing I have said should preclude folks asking for features, but expecting a survey has already been rejected.

The interesting thing is that, if one were at a stage where a poll was considered helpful in choosing between feature requests, it would suggest that all the really basic functions were taken care of. Dorico is now a much more mature product.

I think the handling of lyrics is underdeveloped, it’s a real nuisance not being able to have two time signatures simultaneously, and there are some things like lute tablature that need to be added sometime, but a lot of the shortcomings I’m coming across don’t tend to fit into obvious categories.

I’d really like it if the team would trawl through the posts and find the problems where the “solution” was a workaround. An upgrade that dealt with a lot of those would be really valuable at this stage I think. Not only would it make everyday use easier, it might help identify any problems with the architecture.

That is actually possible, unless I misunderstood what you meant …

I know about your workaround thanks.

I’m genuinely curious what you mean. Two time signatures simultaneously is perfectly possible without workarounds, unless you look upon having to press the Option key as a workaround. Or perhaps you mean Finale’s rather clumsy way of doing it, in which you can have simultaneous multiple time signatures but their barlines all coincide. I’ll admit that I recently had to notate 2/4 and 6/8 simultaneously with shared barlines and it required a lot of fuss and bother in Dorico, whereas it was very simple in Finale. I almost considered just notating everything in 6/8 and using duplets…

Sorry, I should have made it clear that this is the scenario I had in mind. I would suggest that this use of simultaneous time signatures is much more common than any other. I’ve had to deal with it twice in the last few days but have never yet had to have more than one time signature without the barlines aligned.

The workaround I was referring to was Claude’s from https://www.steinberg.net/forums/viewtopic.php?t=122706.

Dear tristis,
I use this workflow every time I face this situation, and I would not call it a workaround anymore, since it does perfectly what I need it to do, as designed. I agree it’s not the simplest workflow, but it has the advantage of being mathematically correct and accurate. There are many little things that can speed up the process once you’ve got acquainted with it, like alt-clicking tuplet signposts, making sure you use the chord mode (q key) when it’s needed (so you do not overwrite the tuplet signposts), etc…
Truth is that this kind of notation, while easy to understand and to read, is not conceptually the simplest, so it does require some thinking when you need it. If this were the “normal” behavior with different TS and bars joining, how would you achieve the simpler notation, where an 8th equals an 8th and the bars do not join ?

Of course, it’s a workaround. However, it is an easy one, especially since it doesn’t screw up bar numbers anymore. For me, I now have a program that does both types of polyrhythms well. If I want to engrave Ives’ “Putnam’s Camp” or the stage orchestra in Mozart’s “Don Giovanni”, I can now do it easily. If I want to do the more common 6/8-2/4, I can also do it, but with a few more commands. Having said that, users should never be afraid of expressing their needs on this forum, and automating the second option would be a plus. It’s (naively, I’m sure) obvious to me that the architecture allows it, but for now it can be done in a very sturdy way, and that will be enough for a lot of users.

Weaknesses in architecture is a slippery concept. No complex program can claim to have a perfect architecture which is adapted to all tasks. There is always some sort of Heisenbergian trade-off going on. For the most part, what attracted me to the program was the fact that its building blocks were very carefully chosen. This is why both polyrhythms above are possible. It’s also why we can predict with a high degree of accuracy what figured-bass will look like in Dorico once it’s implemented; and why we all could see from the start that condensing was indeed possible. So while I agree that a future update dealing chiefly with the secondary issues, big and small, would be great, I’m not sure it would uncover flaws in the architecture. We already know of those trade-offs such as the following:

  1. Many layout operations are computationally extremely expensive.
  2. Collision avoidance and object positioning has to be at the mercy of very complicated algorithms which increase in complexity as more objects are added to the mix. A sort of Newtonian three-body problem.
  3. Anything to do with condensing (percussion staves, condensing feature) runs into the basic nature of Dorico’s concept of “events on a grid”, and has difficulties dealing with rests as a result.

Most other issues (properties propagation for example) have little to do with the basic structure of the program. The developers can’t simply address larger trade-offs by changing the entire structure of their product, an architecture that appears to me to be very sound – there is to much to lose there. Also, from a financial standpoint, dealing with the smaller improvements at the expense of features when competing with two mature programs is not necessarily wise, and a balanced approach must prevail… That is not to say that I don’t wish A-B-C … etc. would be fixed/implemented/improved; I think that every day. But Dorico developers are also Dorico users, and they also want the best outcomes and solutions. We’re dealing with eight programmers here, and again there is a trade-off: some things will take more time (although goodness knows they are fast!), but the overall quality and sophistication of the program benefits from this boutique approach. So yes, we should always bring our grievances here, but at this point, I more than trust them to be equal to the task.

I can understand why. They have a bigger idea of how the releases are going to be, and which features to add when and why (what is feasible and important in the short, medium and long term, regardless of what’s popular).