I’m not sure why I’m having so much difficulty with the basics here, since others have been able to use these features. But when I create a new flow, I see nothing. No staves, no title, no nothing. Here’s what I expect:
Create a new flow in Setup
Switch to Write mode
Select my new flow
Start entering music
Where does step 3 happen? I cannot find the new flow. Shouldn’t I be able to select it, so that I can enter some music there? But there are no flow cards. Of course I’m guessing what to do, because the documentation doesn’t give any instructions for creating a new flow and entering some music into it. (Why not, by the way? Can’t you just write a quick paragraph, maybe right now, that tells us how to do this?)
Ah… you can’t see your flow if you are showing a layout that doesn’t include it. Well it never occurred to me that the new flows would just be pasted one after another into a layout. Personally, I’m not much in favor of that. For example, suppose you have a 90-minute symphony scored for large orchestra. How small are those scrollbars going to be if Dorico pastes all the flows together? I’d put each flow in its own file, and totally unload a flow from memory when it is not in view. Otherwise people will be storing each movement in a separate file, because the Dorico data structures will bog down in giant scores. Just like Sibelius, right? Same machine, same challenge. No magic.
The biggest project I’ve created so far is about 100 pages of keyboard music. Editing that is not much slower than one page - it’s definitely not 100 times slower!
It you want “bigger scrollbars”, create a new (perhaps temporary) layout containing only one flow, and work on that.
@byronhawkins
I had the same problem last night finding additional flows in Write. Luckily I (too) found that they were in what appeared as separate “pages” when I scrolled to the right. Not immediately obvious.
In galley view, each flow is indeed on its own “page”, and in page view each flow will, by default, start on a new page (though you can change this behaviour in Layout Options).
Dorico has a completely different architecture to other scoring programs. It is designed from the ground up to handle projects with multiple movements in an efficient manner. Of course it’s possible to still come up with pathological cases: when a layout contains multiple flows, and you choose to have each flow continue directly on after the previous one on the same page, if you manage to insert e.g. 8 bars at the start of the first flow, then Dorico is potentially going to have to cast off the entire layout, and that may be somewhat slow, but in general an edit only affects the flow that you’re currently working on, and provided the casting off doesn’t need to change for the whole layout, then it doesn’t matter whether you have one flow or 100 flows in the layout. Dorico is not the same kind of beast as either Sibelius or Finale.
when a layout contains multiple flows, and you choose to have each flow continue directly on after the previous one on the same page
How can I do this? In my projects that have multiple flows, each flow always starts on a new page. I am using the default flow chain containing all flows.
All right, apologies for making assumptions. But I was going on the fact that Dorico responds slowly, which other users have pointed out here already. For example, when typing lyrics quickly, it drops the first letter or two of each syllable (for the record, I’m on an i7 with 16GB ram and no other significant load). Dorico also ignores “ctrl+s” when pressed while other UI activity is going on.
If any developers are interested in a user’s suggestion: in my experience the most reliable way to handle user input while the app is busy is to enqueue every input event in your own data structure. To improve reliability, capture enough context information to correctly comprehend the event later–even up to a full minute after the event occurred. For example, when the user clicks, store the click position and the thing that was clicked–but don’t process anything about the target object until there is enough time. This way you are more likely to process every event with due respect to the user’s intention, even when most of the cores are pegged. It can be a pain to route every event through a queue, but it goes a long way towards creating a responsive and reliable experience for the user.