I’d appreciate some advice on working methods
-
Create a score and use Staff spacing to get the formatting as you want it. Then decide you need a new page somewhere within the written music but doing so, you lose your Staff spacing. Daniel has said this is working according to spec because formatting is attached to a page, not to music. OK, I really, really don’t like that but it’s not something the team are changing soon. So, how do you get around this limitation?
-
Having input all the music, I’m now looking at optimising page turns in individual parts. I’ve found a way to compact music on one page without it being illegible, so I’ve used Staff spacing to make room. However, that’s not enough to get the music to move from the following page, I have to use breaks but that doesn’t move music on all subsequent pages.
I’m guessing I’m just doing this wrong but I can’t find a “reflow” command or similar. I understand that the frame in which I’ve made room has a large margin at the bottom. Inputting new music and deleting bars both reflow automatically so the code is there somewhere
1.simple - formatting staves should be the last step. if you cannot hold yourself, your staves spacing isn’t gone, so you can simply reflow it using the “copy staff spacing” command.
@qanunji: Oh that I could. If I’m told the score changes, then it changes. This is not uncommon in my area…
@pianoleo: The problem with multiple system/frame breaks is that you end up controlling every morsel of music yourself. It’s that world that I’m trying to escape!
@Rob Tuley: Yes, this worked for me, thank you. Flow and spacing were sorted. I’ll certainly employ this and, if necessary, use it on the occasional system break signpost when absolutely required.
Thank you all for your help. Very much appreciated!
I completely agree with you, it’s a pretty normal workflow in my area too.
Thank you, Daniel - very much appreciated. And it’s in the spirit of admiration and thanks that I write the following.
Is it possible that the the desire to combine page publishing and music publishing that compromises have been made to the function of music? It certainly feels sometimes that the God of the page overrules the God of notation, as least when it comes to usability.
Caution - heretical thoughts coming up. At this stage, when the code is new, there will be very few concessions made to backward compatibility. Anyone who has worked on large projects will recognise your upcoming dilemma. The complexity of maintenance code starts to overwhelm the ability to add new function. However, it’s the clean sheet you’ve started with that so many of us welcome.
How about being prepared to turn volte face and drop or change function radically? Do what others developers do and deprecate certain functions, even if there is a potential to drop backwards compatibility. Apple’s new version of Final Cut Pro is a joy compared to the old one but they took a lot of flak in doing so.
I would vote for a little pain over a couple of years, were it to allow you to refine your architecture taking into account the voluminous feedback from these forums and elsewhere. Don’t build code alternates for old versus new. Don’t build complex “Would you like me to update your file to the new standards?” code. Highlight the deprecations or design changes and let us fix them. Allow Dorico V1 to run alongside V2, V3 etc. If need be, I’ll open an old file in the appropriate version.
I guess this is where I have to say to the other contributors: “Your mileage may vary”. As one who worked for Acorn before Ben and Jonathan first released “Sibelius 7”, and having worked for IBM, for a major ISP and through it all been a pro musician, I’ve seen what the nightmare of maintenance code can do to Finale and Sibelius. It’s no surprise that their updates are trivial. It’s the under-the-cover changes that consume much of their creative energy.
<>
No tin hat required, at least from my point of view.
At the moment we are taking a somewhat laissez faire attitude towards maintaining backwards compatibility for the reasons that you outline, though I don’t think we will be able to maintain this approach forever.
I have discussed this week with Andrew, the developer who has done the majority of the work on note spacing and page layout to date, about how we might allow staff spacing adjustments to be maintained even when the page in question moves forwards or backwards in the layout, provided no other changes occur to the range of music on the page. We have identified at least the bones of a plan, but we’re not sure when we’ll be able to actually try it out. Certainly at the moment we are deep in the implementation of a number of other significant features, and it’s not something we can do right now.