I’m wondering if all users of various models of iPads have the ‘hanging notes’ problem that can occur?
It just seems to happen when using the built-in keyboard screen.
Very hard to even know what even triggers the sustained/hanging notes.
I’m using an iPad 3rd generation (2018). Everything else works fine.
(…it doesn’t have the memory or processing power to really use the Iconic sounds, but that’s not really a worry for me as I have the main Dorico on other computers)
A fix would be fantastic. I think it’s by far the best of all the portable iPad notation programs, Being virtually identical to the master software makes it very useful indeed.
Indeed, but that’s also part of the problem. “The master software” is a multi-platform Desktop application, not optimised for multitouch. And the iPad app shares the same UI components. Qt is a very good compromise on desktop, but I find it rather poor for iPad apps. Sure, Dorico compiles (which is in itself great achievement), mostly “works” and it’s very powerful in terms of features, but the very essence of iPad is missing from it. Touch interaction is terrible, barely usable (scrolling, zooming etc). Keyboard and mouse/trackpad are almost a requirement to avoid all the frustrations, which kind of defies the purpose of Dorico on iPad. And even in those rare circumstances when I do want to connect mouse and keyboard and use iPad as a traditional computer, Dorico doesn’t work with external displays.
Ideally, critical UI components should be written separately for iPad, by iOS developers, using native frameworks. I understand why this may never be a possibility for Dorico team, and it’s indeed some serious work, but I am not really optimistic that we will ever have a good enough Dorico on iPad with Qt only. Almost everything that I personally hate in the current iPad app is already solved (“just works”) by using native frameworks, while it requires a lot of fighting and “hacking” with Qt, hoping it won’t break anything on macOS and Windows. At the end, I really wonder if cross-platform frameworks are indeed cheaper in the long run?
No, the issues with the on-screen keyboard are definitely not hardware-related, they’re due to problems with the way we’ve built that particular component.
@ikos is right that there are of course inevitable compromises when using a third-party application framework instead of building directly to native APIs provided by each operating system. But without being able to use something like Qt, either Dorico for iPad simply wouldn’t exist, or Dorico would be significantly less feature-rich on all three platforms, because a great deal more of our development time would be spent building user interface components individually on each platform. Qt is no panacea – we often have to fix bugs directly in Qt itself, which we really try to avoid doing, because our own fixes create an ongoing maintenance overhead when we come to upgrade to later versions of the framework, but we really have little choice.
But it’s also the case that Qt is capable of producing really great cross-platform software, especially if you’re able to take advantage of its latest technologies. The challenge we have is that despite being a relatively young application, Dorico already has code that’s more than a decade old, and continually refactoring and reworking that code to be able to take advantage of the latest functionality provided by Qt is itself a huge job.
It’s all a matter of managing our time carefully, trying to pick our moment to rework or rebuild something, and balancing those tasks against driving the capabilities of the product forward. We could easily manage to spend multiple years simply reworking the internals of Dorico without adding a single feature, but commercially that’s simply not a viable approach.
In the specific case of the Keyboard panel, we “just” have bugs that need some dedicated time and attention to fix them. The issue is not the technology, or the fact that it’s running on an iPad, or the fact that it’s implemented using Qt (only a poor workman blames his tools). The issue is that we need to prioritise working in this area, and at the moment our small team of developers have their attention focused elsewhere.
Thank you for the information on the processes and the ‘behind the scenes’ thinking. Tricky stuff and I’m sure it’s a tough balancing act.
Your development team is wonderful as has been proven time and time again by the main work on Dorico for desktop. Thanks for creating Dorico and continuing to tweak it!
The iPad version is a nice little bonus to have available when one needs it. Besides the weird little keyboard problem, which is only annoying when some maneuver has mysteriously triggered the sticking note problem, it too is wonderful to have available. I’ll continue to use it whether it has this quirk or not.
Hope you guys get some sleep sometime! And a big shout out to your video/tutorial/manual teams for making life easy.
Back to a coffee and a project at hand … (latest version of Dorico is so fast and responsive…but it’s nice what a few years ‘under the belt’ can do to the workflow! … and I still haven’t used all the possible functions!)
Dorico is an excellent tool overall, but this issue has a direct impact on the user experience.
In 2026, with modern debugging tools and AI-assisted development available on iPadOS, this kind of problem should not be so difficult to identify and fix.
At a price point of €129, this behavior is simply not acceptable for software of this level, especially coming from a company that is a long-standing pioneer and reference in the music production software industry.