I have a problem in bar 640 with the grace note of the 1st Flute, which should be after the bar-line.
I can’t figure out this problem.
The full score is ok, but the 1st Flute part looks like this.
Hi Stefano.
I’m afraid you probably have another player that has grace notes before the line. For the time being, this is a known limitation : you cannot have grace notes both before and after the barline at the same rhythmic location.
I suggest you use some workaround involving hidden tuplet and manual scaling for the grace notes after the barline…
Dear Marc,
Thank you very much for your reply.
I knew very well this issue, and I’ve checked very carefully all the other instruments.
I’m afraid this is not the problem.
Best
Stefano
Oh, sorry! I’ll check your project if I get a chance 
Hang five, Marc.
I’m working on it now and think I have found a way. I just need a few minutes to write it up and check that it works.
Not sure what the underlying cause is, but selecting the grace note and toggling the “Grace note before barline” property appears to fix it. (I.e. turning it on, then off again)
If that doesn’t work for you, perhaps there’s something in the full project (with other instruments/players) affecting it.
Hi Stefano,
Try this.
Hopefully, that should retain the desired appearance.
You will need to remove the rest in any other parts.
Playback will probably give a beat of rest at that point. If that is critical, add something really tiny like a 1/64-note instead of adding a 1/4-note. The 5/4 time signature will then need to be 257/256 ((4 x 64) + 1).
Lillie, I tried what you suggested but after quitting Dorico and re-opening the document, the grace note returns to the end of the bar before the change of system.
I also tried various combinations of starts voice and ends voice with changing the voice of the notes in bar 640. Still no good. That’s why I tried separating the grace note from what precedes it.
Yes you’re right, it does revert back when you close and reopen after toggling the property.
How’s this one @stefanorabaglia - I deleted the system break on the final system of the part, and deactivated the “Wait for next…” on the preceding system break in bar 636. Not sure why that would have such a profound influence on the grace note, but I’ll certainly ask the team.
sample_lh2.dorico (840.2 KB)
Edit: my learned colleague Richard says that the “Ends voice” property set on a rest in b199 is the real underlying cause - if you deactivate that, save, close, and re-open, the grace notes at the end should be fine. However, that will affect the notation in b199 so you’ll have to make a judgement about that. (Edit 2: you could instead use a tuplet to fill that bar with only the rests you want, and input them with force duration if needed, rather than remove rests at the end of the bar.)
(Also, be careful using the Global property scope when moving system objects graphically - it can affect the position of the corresponding item but only in the top-most staff of the system; the tempo marking in b203 is offset into the staff in the Flute part.)
That seems to be a much better solution - it is quicker, easier, and less prone to error.
Once again the team turned out to be fantastic!!! I love you all.
Lillie’s solution, in particular, is absolutely brilliant. The problem was really impossible to solve even for an experienced user. However let me say that I hope that limitations and bugs (especially concerning condensing, open meter, intrument labels etcetera) can be overcome as soon as possible. Hopefully before the release of the new version of … Dorico for SmartWatch. (Please believe me, no polemics)
Thank you so much and all the best
Yours
Stefano
Do you think the Dorico Team is likely to hold back an improvement once it is available? I think we can be confident that Dorico is constantly making improvement and releases them as soon as they are ready for prime time. Of course we all want our favorite improvement in the next version.
Dear Derrek,
I am a Dorico fan from the very first version in 2017.
I use it for professional publishing projects, where quality standards are very high. And had to fight with my publisher to use Dorico. Everybody said “Dorico is not ready, it is not mature for large projects”.
Well, there are certainly things you can do with other programs but not with Dorico.
Fortunately, the support has always been fantastic, efficient and fast.
Nevertheless I know very well how many countless hours, days and nights I spent trying to find solutions and overcome certain limitations. But in the professional field the time is money, there are deadlines to be met. You can’t delay for technical problems.
I therefore feel entitled to have my own opinion and no one could possibly be offended. I respect and admire everyone’s work. I have said it and thanked thousands of times.
I love Dorico but now I see that it is flirting with other platforms.
When I read “We’ve been working very hard… All of us have been working fully remotely throughout the Project” I can’t help but think that much time, energy and resources have been subtracted to the development of Doric Desktop version.
Steinberg surely has every right to make its own commercial choices. If the iPad market is more attractive I understand it. Steinberg could also decide to stop any further development of new features. It is in his right.
But bug fixing is necessary and due as soon as possible, because customers are entitled to have a fully functional product.
Car manufacturers recall the cars when there is a problem without waiting for the next model release.
There are bugs waiting for years to be fixed.
Anyway that’s just my two cents.
Your faithful user
Stefano
We take bugs and defects in the software very seriously and do our best to fix them as quickly as possible. Some bugs cannot practically be fixed without a more thoroughgoing rework of a functional area, which means that may have to wait for us to be able to prioritise work in that area. But in general we try to fix bugs as soon as they are discovered, and certainly fix by far the majority of the bugs that are discovered within days of them being entered into our tracker. The vast majority of those bugs are fixed before the software is released, so you never see them. (At the time of writing, our bug tracker lists 4900 fixed bugs, and around 150 open bugs, so at present around 3% of bugs discovered remain unfixed.)
It’s also the case that users sometimes incorrectly characterise areas of the software that do not work in the way they would ideally like as “bugs”: to be clear, a bug is when the software does not work in the way that the designers intended, not when it does not work in the way that one or more of its users would prefer. But we also take user feedback concerning areas of the software that do not work as users would ideally like seriously, and think about that feedback when considering future improvements.
Even during the development of Dorico for iPad this year, we have fixed many bugs and have been working hard on the development of the next version of Dorico. You will be able to see this for yourself when the next version arrives, later in the year.
Daniel, we all appreciate and applaud the hard work of the dev team. And the support you all provide here is industry leading. But you are digging yourself a hole here…
Good to know. But the fix is only resolved when it is deployed to the user.
Sorry, but that is a meaningless metric for every user who encounters any one of the outstanding 150, as well you know.
I sense a growing frustration in the community that many fixes that you claim to have resolved have not yet been deployed. Bug fix releases do not require fanfares - just a release!
We know it’s been a long time since the last release. We cannot always deploy bug fixes as soon as they are made because we normally fix bugs as we go along, in the course of new feature development, and unpicking the fixes from the feature work to make it possible to release only the fixes itself takes time that we cannot then spend either fixing more bugs or developing more features.
It should be evident that we take the quality of the software very seriously. All sophisticated software has some bugs, and many development teams are far less assiduous about tracking and fixing bugs than we are. We will get more bug fixes into your hands as soon as we are practically able, but do be aware that the next release of Dorico for macOS and Windows will be a paid one, so if you would like to rehearse the arguments about feeling aggrieved about paying for bug fixes, here’s your chance.
“The community” is never satisfied with the pace, it seems. Every new update is met with a chorus of groans for the rEalLy iMpOrTaNt fIxEs that didn’t get included. “You didn’t address X? What were you doing that whole time??”
And we all like to think that our priorities are the priorities of the community at large. The reality is, Dorico is getting widespread enough that this small forum of niche users can’t claim to speak for the whole user base.
Has it been a long time since 3.5? Yep. Am I impatient for version 4, and hoping for my wish list? Of course. But the development team has been crushing it over the past 4 years. I’m inclined to give them the benefit of the doubt. I think they’ve earned it.
To paraphrase Star Wars:
“Follow the roadmap, Luke. Follow the roadmap.” 
The bug about the grace note in this topic is the same as the one I reported in June 2020. That time, as well as this time, the problem occurred when I shortened the horizontal space of a bar by removing rests.
