Feature request: multimeasure play

Hi Dorico team,

I guess there are many choices on what to add to the next major version of Dorico, and I guess a lot will be added.

If I could vote for only one single enhancement, it would be a simple way of creating “multimeasure play” measures, since this would save hours and hours for me.

image

As of now, this can be done with trying to get rid of multimeasure rest graphics in the part and replace with what is needed. But it is very time consuming, it is very easy to do minor mistakes that might mess things up, and also the corresponding area in the score will contain whole rests which is not reflecting what is intended.

It could be very simple, just like marking an area in a staff to make a slash region, the same (with some alternate graphical marking) could be done for creating a multimeasure rest measure in the part, so that the marked region in the staff corresponds to a multimeasure rest measure in the part.

This is what I am dreaming of. Besides, of course, a white christmas.

2 Likes

Thanks for your feedback, Dan. How would such a “play” region appear in the score?

I’m afraid it’s not likely that we’ll be able to add this to the next major version, but I think it’s certainly something that is widely used and Dorico should support it more easily than it does at present.

Hi,
I am very sorry to hear this, the lack of this functionality is making the drum part even worse than it already is. I hope you change your mind, since this is a very simple yet powerful functionality. The most important is of course the part, so that also longer pieces can fit into 2 or max 3 pages. What is marked in the score is not extremely important, but if you want to keep it extremely simple, why not just state the “Play” instruction in the first bar of the area, and then leave the following empty?

Or, a little more worked-through, some simple symbol could perhaps be invented. A bar repeat symbol in a circle?

…that could be completed with some “last number in the area” if so desired

…or numbers of all measures in the area if someone would want that

It doesn’t need to be extremely fancy. Just not whole rests :slight_smile:

2 Likes

I think it’s not a question of a change of mind (Daniel’s or Steinberg’s), but a question of planning. I’m not a clairvoyant, but the next version of Dorico is probably due somewhere near the beginning of summer (this is just guessing, I don’t have any intel on that).
I’d be surprised if the development team would manage to incorporate new ideas like this in the upcoming version, however good they are.

One idea would be to offer this as a pure visual alternative to the already existing “Consolidate bar repeats” functionality, using unconsolidated bar repeats in the score.
In an ideal world, this would probably be of even better use as a consolidation of slash regions. Or perhaps both? The first idea would probably still please most people, though.

What @PjotrB said: Dorico 3.5 was released nearly a year ago (a year ago this Thursday, as it happens). I’d be very surprised if the roadmap for Dorico 4 hadn’t already been set, if not most of the coding.

2 Likes

I generally follow the Ken Williams style and put slashes in the first bar, then 1-bar repeats. Here’s a sample from pg 97 of his book:

I would love to see that style be possible in the score (preferably with Dan’s “last number” option) and some sort of “Play 8” or “Time - Play 8” indication in the part. There would definitely need to be some sort of manual override here though. I might want to use “Play 8” for an entire phrase, but not a “Play 3” before a figure that needs to be played.

(As a somewhat related topic, I’d really love the “last number” option available for all 1-bar repeats. The performer almost always needs to know the count of the final 1-bar repeat, and then the others can be shown in a logical manner. It’s that last number that is the absolute necessity though when counting and that setting can’t be automated as of now.)

I was just thinking to myself the other day that it had been quite a while since we have had a release… it has also been an unusually long cycle (for us). [To be clear, I don’t begrudge the team that; we were just so spoiled early on! ]

1 Like

When 3.5 was released, Daniel told us that the next major update would require a longer wait than had been the case in the past due to code updating as well as added features.

Yes, I remember that. No doubt Apple switching to ARM threw a major monkey wrench in things too. (And truth be told, I expect D4 to only be optimized for Rosetta rather than native code.)

Dorico 3 was released in autumn. Therefore the gap between 3.5 and 4 is already much longer than between 3 and 3.5. I remember Daniel “saying”, that this time of the year is the desired time for new versions of Dorico. But who knows in these difficult times …
I have some bigger projects in the next month. At the moment I am waiting with these for the release of Dorico 4. I hope Daniel will give us a hint, if version 4 will be released much later.

1 Like

Indeed. We were on what… 4ish month cycles of releases or “dot” updates. Now we’ve gone nearly 12 mo. That’s quite the adjustment! (Although again, I reiterate, not unreasonable. I just get antsy for new versions and it’s hard to wait so long! In my case I use Dorico every day for professional work, so the new features are usually a boon to my workflow.) And you’re right: I too remember reading Daniel mentioning that they want to get the next major version out in time that students can pick it up before the fall semester starts again. Hopefully that means no later than mid-summer.

I know it’s been a long time since the last meaningful update. And to those who are expecting Dorico 4 to be released imminently, I’m sorry to disappoint you, but there will be longer to wait.

We certainly do prefer to release new versions at this time of year if we possibly can, but there can be extenuating circumstances to make that impractical. Although the pandemic hasn’t had a direct impact on our schedule, it’s certainly been a new experience for us completely conceptualising and then implementing a whole version of Dorico completely remotely: we’ve not seen each other in real life for well over a year now, and it doesn’t appear we’ll be working back regularly in our office in London any time soon. However, on the whole we’ve been able to work much as we normally would, and the team continues to do great work.

What has been different over the 10 months or so since we released Dorico 3.5.10 is that we have been working on several different projects at once, with priorities shifting over time. Some members of the Dorico team have been contributing directly to the company-wide project to replace the eLicenser. Some have been doing some work on a project related to bringing Dorico and Cubase closer together, about which I can’t say much but which will take a longer time to come to fruition. Some members of the team have been working on infrastructure projects, including evaluating the major new version of Qt that was released at the end of last year, looking at the work required to get Dorico running natively on the new Apple Silicon-powered Macs, addressing some code quality and modernisation issues, and looking at some deeper technical issues (e.g. redesigning some aspects of the application architecture to improve performance, reducing or eliminating the number of operations that require Dorico to completely recalculate the open layout from scratch). And, of course, we have all the while been working on useful new features.

Our team is not huge (you can count our engineering team on the fingers of two hands and have one or two left over), so that’s quite a few different projects that we have been splitting our time between. All of them will bear fruit sooner or later and will improve the technical foundations, user experience, performance and features of the application.

As I said on the blog when we released Dorico 3.5.12 back in February, we do plan to bring you something else new and exciting before Dorico 4 arrives, and that is still our plan. But I can’t share anything more in that direction for the time being. Please watch this space! (Well, not this space specifically, but the spaces where we announce things.)

23 Likes

I think it’s fair to say that all of these (very exciting sounding things) would stretch any team thin.

2 Likes

Hello Daniel,
Thanks for sharing this update. I do appreciate the difficulties working in a team on distance for so long. I think you did it together quite well, overall.
Please continue keeping us updated from time to time!

Suggestion: could you involve the Dorico users community more in defining the priorities for new features in Dorico. You could for example have a page where all new / to be enhanced / to be corrected features are brought together, and where the registered forum users could vote in some way about the priorities.
Or does this page already exist, and did I not discover it?
Stay healthy with all your team!
Robrecht

1 Like

Members of the Dorico Team read every post here, and Daniel tracks those with suggestions or problems, but he has stressed that setting development priorities is not a democracy.

2 Likes

Ha, I had a feeling that if I wasn’t quick enough to reply myself, somebody would come along and repeat my old mantra that Dorico development isn’t a democracy, which is something I say to make a particular point, rather than because I’m some kind of despotic authoritarian: on the contrary, I think it’s very important that Dorico’s development is driven by consensus, especially internal consensus among the team with immediate responsibility for specifying, designing, implementing and testing the software, but also in terms of the overall alignment of what its users, in the aggregate, want to see.

However, any kind of attempt to reduce to a single, ranked list of requests the complex processes and considerations that go into how we decide what to work on and when would be reductive to the point of being misleading. And a negative side effect would be to provide a nice, centralised place for our competitors to go and get a very good idea of what we are working on. There’s plenty of, shall we say, inspiration being drawn from Dorico by other developers in our little niche already without giving those developers the additional advantage of telling them what we are doing before it has been released.

11 Likes

Hello Derrek, Daniel,

Thank you for picking up my comments.

I do appreciate that setting the priorities is not a democracy :blush:.

But as an assiduous Dorico user, I would appreciate having more insight in the upcoming improvements. I just give an example:

Two years ago, I started making a new score of Tchaikovsky Piano concerto 1. At that moment, the condensing capabilities of Dorico were not what they are today. Should I have known it, I would have tackled the score writing in a different way, because at that time I created special condensing staves, to make the conductor score more condensed. That work, after 3.50 became available, has become useless, because now Dorico does it for me (I’m so happy about it :blush:). Other example in the same concerto: you really need to be able to write octava lines which do sound an octave higher (piccolo) or lower (deep piano) than noted. At that time, the notes would not sound like you would expect. Problem is solved in 3.5, happily.

It’s not terrible, but it would have helped…

Other example (which I signalled to Daniel): the inability to mix two tempo indications simultaneously (which I need in the Tchaikovsky 1), i.e. some instruments play for example in 6/8, others in 2/2, and 1 bar in 6/8 is equal to 1 bar in 2/2. I’ve not found a good workaround for that yet. It would be nice knowing if and when that feature will become available.

Anyway: I do appreciate the immense you are doing, and thank you for it!

Kind greetings, Robrecht

image001.jpg

For the independent time signatures, you might find this article helpful. It utilizes Dorico’s ability to have time signatures locally on individual staves and then tuplets to make all the required notes fit. Unless I’ve misunderstood and by “tempo indications” you do actually mean tempo marks/metronome marks?

Hello Lillie,

Thanks for getting in touch.

An example of the use case I’m mentioning is to be found in Tchaikovky’s piano concerto 1, see for example https://ks.imslp.net/files/imglnks/usimg/7/73/IMSLP00697-Piano_Concerto_No._1_in_Bb_Major,_Op._23-1.pdf, on bar 390.

Until bar 389, all instruments play in common time (4/4). From 390 on, the woodwinds, violins I and II play in 6/4, while the others continue playing in 4/4.

As it happens to be, I did use a similar trick as the article you pointed out, with tuplets as workaround to get my score noted, but it is not nice, because in my score the different time signatures are not visible anymore, because … they are not different anymore. And for me, the score should comply as much as possible with the original intent / manuscript of the composer.

So, as soon as Dorico supports polymetric notation, I shall adapt my score to reflect Tchaikovsky’s original notation, and then I can publish it. So yes, I would appreciate knowing approximately when that feature will enter into Dorico!

Kind regards,

Robrecht

image001.jpg