Skip to main content ↑ ↓
Topic: System break anomaly (Beta 2.22) (Read 7032 times) previous topic - next topic

System break anomaly (Beta 2.22)

In the attached nwc file I have set up a Key change in accordance with Alfred's Essential Dictionary of Musical Notation, pg, 172

By fiddling with the page margins, I produced the attached gif. Musically, this is wrong. The system break should (indeed must) occur at the hidden bar line after the key change. Even if I set a SysBreak on the hidden bar, it is ignored and the break still occcurs in the wrong place.

One way to code around this problem would be to consider barlines that enclose objects, none of which have any duration, to be an inseparable part of the prior measure unless a SysBreak was explicitly set. This would also handle a TimeSig change, although it would still not add the Timesig to the start of the next line.

At some point, NWC2 needs to be able to handle changes to signature items in a musically correct way. This is not a high priority, but getting the Key change right would be a start.
Registered user since 1996

Re: System break anomaly (Beta 2.22)

Reply #1 –
A quick check of this, Rick, indicates that it seems to be a function of the length of the previous system. If you shorten the second measure of your example (I simply removed the final group of 16ths), then it prints properly. You've created a separate measure holding only the key sig, and NWC doesn't think there's room enough to attach that measure to the first system. I don't think it examines the contents of the measure at all.

The ideal solution to this problem would have NWC check key sigs, time sigs and clefs at the beginning of each system and attach them to the end of the previous system automatically if there is a change at the system break, adjusting measure lengths as needed. As is, we have to do this ourselves. My solution, kosher or not, is to always place any key/time/clef change before the barline rather than after it. That way the courtesy key/time/clef is placed by the program as a matter of course. It doesn't place a barline before it, but that could be done by placing a barline as a text object and making the real barline invisible. I haven't done that, but I may try it in the future.

Cheers,

Bill

Re: System break anomaly (Beta 2.22)

Reply #2 –
G'day Rick,
you said you had fiddled with the margins, so an adjustment of the margins would also resolve it...  As it did when I played with it and set a forced system break on the hiden barline.

Now, while playing with this, and checking out the reference in Alfred's it occurred to me that another parameter on barlines could be useful...  A system "Do NOT break".  If this was available and set on the double barline prior to the key change then the keychange should stay where it belongs.

Of course this potentially creates other problems like - how do we fit the extra bar if it's too long - thus we come back to the problem you've had a bit to say about over quite some time in relation to spacing...  We really could use some extra controls.  Especially the ability to reduce spacing when required.
I plays 'Bones, crumpets, coronets, floosgals, youfonymums 'n tubies.

Re: System break anomaly (Beta 2.22)

Reply #3 –
A system "do NOT break"....I like that, Lawrie. I also like the idea of being able to adjust adjust spacing manually. The current Note Properties interface could take care of that - we just need to be able to use minus numbers in the "extra note spacing" wheel.

Re: System break anomaly (Beta 2.22)

Reply #4 –
Quote from: William Ashworth –
My solution, kosher or not, is to always place any key/time/clef change before the barline rather than after it. That way the courtesy key/time/clef is placed by the program as a matter of course.
That is "kosher" for Clef changes, but TimeSig and Key changes need to be preceeded by a barline. Of course the size of the Clef is wrong, but I digress... (and yes, I know the workarounds for it)

Quote from: Lawrie Pardy –
you said you had fiddled with the margins, so an adjustment of the margins would also resolve it...  As it did when I played with it and set a forced system break on the hiden barline.
At certain widths, setting a SysBreak on the hidden barline is ignored. IMO, this is very close to being a bug.

There are a host of workarounds for this. My point is that they should not be needed. NWC should not produce output that is typographically incorrect just because the layout changes. This is difficult to proof. I'd rather not discover it during performance.

I don't think NWC2 needs to analyze the kinds of objects enclosed by barlines. It just need to determine if the enclosure has duration and "cement" it to the previous measure if it does not. NWC2 already does something like this when it counts bars. It just needs to be refined and applied to layout.

Quote from: William Ashworth –
- we just need to be able to use minus numbers in the "extra note spacing" wheel.
I'll second that. XNoteSpace needs a lower range of -2 . Fractional spacing would cure a number of woes, but IMO, the lower range is more important.

Due to the way NWC2 does layout, an option to "forbid SysBreak" would not be very useful unless it would cause a tighter note spacing than the default spacing.
Registered user since 1996

Re: System break anomaly (Beta 2.22)

Reply #5 –
Quote from: Rick G. –
<snip>
At certain widths, setting a SysBreak on the hidden barline is ignored. IMO, this is very close to being a bug.

This is true for any barline if it would otherwise result in an empty system.

Quote
<snip>
Due to the way NWC2 does layout, an option to "forbid SysBreak" would not be very useful unless it would cause a tighter note spacing than the default spacing.

That's what I was trying to allude to with my "problems" comment...  You said it better.

I plays 'Bones, crumpets, coronets, floosgals, youfonymums 'n tubies.
 

Re: System break anomaly (Beta 2.22)

Reply #6 –
Well, I thought you would know the workarounds, but I thought others reading this thread might not, so I went ahead with a brief explanation :-)

And you are right that checking an object for duration in the way you suggest would fix the problem. But I'm not sure you're right that a sysbreak command being ignored "under certain circumstances" is a bug. I think Lawrie is correct that those circumstances are limited and appropriate.

At any rate, a change in the lower limit of the extra note spacing parameter would certainly make the whole issue a lot easier to deal with.

Re: System break anomaly (Beta 2.22)

Reply #7 –
Quote from: William Ashworth –
But I'm not sure you're right that a sysbreak command being ignored "under certain circumstances" is a bug.
Perhaps that is why I wrote "very close to being a bug."

I can't find online help for SysBreak, but:
Quote from: nwc2help.chm
When selected for a bar line that appears in the top staff of a system, this option will force a new system to be started, starting with the next measure.
is a non-obvious definition of "next measure."
Registered user since 1996

Re: System break anomaly (Beta 2.22)

Reply #8 –
Quote
...the ability to reduce spacing when required.
I, for one, would love this.