Skip to main content ↑ ↓
Topic: Beam angle descrepancy (Beta 2.21) (Read 10383 times) previous topic - next topic

Beam angle descrepancy (Beta 2.21)

Quote
!NoteWorthyComposerClip(2.0,Single)
|Note|Dur:16th|Pos:1|Opts:Stem=Down,Beam=First
|Note|Dur:16th|Pos:3|Opts:Stem=Down,Beam
|Note|Dur:16th|Pos:6|Opts:Stem=Down,Beam
|Note|Dur:16th|Pos:8|Opts:Stem=Down,Beam=End
!NoteWorthyComposerClip-End
In the Editor, the beam angle on this is what I would expect, but it is much too steep in Print Preview and when actually printed.
Registered user since 1996

Re: Beam angle descrepancy (Beta 2.21)

Reply #1 –
I do not see any difference between the angle in the editor, and in Print Preview. Is there more to this?

Re: Beam angle descrepancy (Beta 2.21)

Reply #2 –
Actually, I do notice a change to the angle in the editor while switching to different zoom levels, so this must be what you are seeing. I will look into this further.

Re: Beam angle descrepancy (Beta 2.21)

Reply #3 –
I'm going to partially hijack this topic to describe a related problem (sorry, Rick).

I just finished printing a score. Noticed a typo on p. 5, so I reprinted it. The new p. 5 had a different range of measures on it. So I checked the full score against the print preview. Here's the result:

Page #    Starting Measure
         Print Prev   Printed copy
 1      1                1
 2      12               13
 3      23               25
 4      33               36
 5      44               47
 6      55               59
 7      66               71
 8      77               82
 9      87               92
10      96              101
11      104            110
12      111            118
13      119            128
14      129            138
15      138            150
16      149            160
17      160            173
18      172

(Should have created a table in this message instead of pasting one in from EditPad, but you get the idea.)

Note that by the p. 14, the printed copy has lapped Print Preview and is a full page ahead. This was printed in landscape mode, but that shouldn't make any difference.

It appears that there are more discrepancies between Print Preview and what comes out of the printer than just the slant of beams.

Cheers (I think),

Bill

Re: Beam angle descrepancy (Beta 2.21)

Reply #4 –
G'day Eric,
Quote from: NoteWorthy Online –
Actually, I do notice a change to the angle in the editor while switching to different zoom levels, so this must be what you are seeing. I will look into this further.

Like William, I'd like to hijack things a little.

Considering you will be looking at the code relating to beam placements and angles, would it involve much more effort to also consider the vertical alignment.

What I'm looking at is when beaming between staves.  Please see the attachment.  It would be most welcome if the beams could be made to overlap exactly.  At the moment, they simply cannot, no matter what staff size etc. one chooses.
I plays 'Bones, crumpets, coronets, floosgals, youfonymums 'n tubies.

Re: Beam angle descrepancy (Beta 2.21)

Reply #5 –
Bill, are you sure that your printing to the same printer and settings as is set when using preview? The preview basically does a screen rendering of exactly what is sent to the printer. There will often be some text kerning  differences, but it is essentially impossible for there to be differences in bar counts between the two (all else being equal). When a preview does not match an actual print with respect to bar counts/pages, this generally means that the printer settings have changed.

Re: Beam angle descrepancy (Beta 2.21)

Reply #6 –
Quote from: Lawrie Pardy –
It would be most welcome if the beams could be made to overlap exactly
Never happen. The angles cannot reliably match as they change ever so slightly as note spacing and stem length change. My attachment show the only reliable methods I have found. The second is unsatifactory to me as it distorts spacing. If some method could be devised to set XNoteSpace=1 without shoving the subsequent notes, I would be very happy.

BTW, you never want a beam slant as much as in your example. See Alfred's, page 85  :)
Registered user since 1996

Re: Beam angle descrepancy (Beta 2.21)

Reply #7 –
G'day Rick,
Never say never  :)

I do take your point about beam angle, but it was a quick and dirty between phone calls during a hectic morning...  :)

Truth is, I don't see this kind of construct as much as you would but I do see it and have had to work around it - witness "William Tell" f'rinstance.  Your examples are much better than what I achieved in that work, but the use of digital whiteout means that in order for me to share something like this, then everyone needs to have the same highlight set to "white"...

A pity the highlight colours aren't able to be set/overidden in the .nwc file...

However, surely it can be possible to get these things to align...  Perhaps floating point stem lengths...
I plays 'Bones, crumpets, coronets, floosgals, youfonymums 'n tubies.
 

Re: Beam angle descrepancy (Beta 2.21)

Reply #9 –
Quote from: Rick G. –
Much easier and possibly more useful to support Stem=Up and Stem=Down within the same beam.

That'll do too :)
I plays 'Bones, crumpets, coronets, floosgals, youfonymums 'n tubies.

Re: Beam angle descrepancy (Beta 2.21)

Reply #10 –
Would it were that simple, Eric. The printer drop-down box on the printer setup screen in NWC says "HP Photosmart C3100 Series" and that is exactly what I'm printing to. Specifically, I'm using a C3180, connected to a Dell laptop (600m) running WinXP and the current NWC2 beta (2.21). I changed nothing in the file between print jobs, beyond adding barlines between the same pair of measures in three staves where I'd accidentlally left them out (this is in a nine-stave piece, and the other six staves had the barline already, so spacing wasn't affected).

I remember being a little surprised when my score printed out at 17 instead of 18 pages, but as everything looked OK, I didn't question it - until I tried to print a second p. 5.

Any further ideas?

Bill

Re: Beam angle descrepancy (Beta 2.21)

Reply #11 –
If you have a sample that prints differently than it previews, please send it to us as an e-mail attachment. However, I would be very surprised if such a thing exists.

Re: Beam angle descrepancy (Beta 2.21)

Reply #12 –
OK - never mind. I found the problem. I'm still perplexed as to why it should happen this way, but it appears to be the printer.

There was one small unnoticed change between printings. For the first printing, I set the print quality to "fast normal." When I reprinted the replacement page a few minutes later, the printer had reset itself to "fast draft," which is its default. (I hadn't turned off either the computer or the printer between the two printings, but I had exited NWC and then re-entered it, and that had triggered the reset, which in hindsight I should have expected.) The different measure counts per page resulted from the reset. This behavior is faithfully rendered by Print Preview: if the printer is set to fast draft, Preview shows pagination equivalent to the first column in my earlier message; if set to fast normal, it shows pagination equivalent to the second column.

So NWC is off the hook. But I still don't understand why increasing the print quality should squeeze more measures onto the page at exactly the same font settings. Measurements in points should be unchanged by increasing the print density. Any theories?

Bill

Re: Beam angle descrepancy (Beta 2.21)

Reply #13 –
Quote from: William Ashworth –
I changed nothing in the file between print jobs, beyond adding barlines between the same pair of measures in three staves where I'd accidentlally left them out (this is in a nine-stave piece, and the other six staves had the barline already, so spacing wasn't affected).
Emphaisis added. So you think adding barlines won't affect spacing? That's funny. Probably just to me.

I just finished a piece where replacing a 16th note with a 16th rest caused a reflow. The 16th rest is 11% wider than a standard notehead ... 557 fdu's vs 500

Quote from: William Ashworth –
I still don't understand why increasing the print quality should squeeze more measures onto the page at exactly the same font settings. Measurements in points should be unchanged by increasing the print density. Any theories?
Rounding errors play a part, but there seem to be more to it than that. I can always squeeze more in at 360dpi than 300dpi. I have a virtual Postscript printer configured for 180, 300, 360, 600, 1024 and 2048 dpi. You would be surprised how much things shift around.
Registered user since 1996

Re: Beam angle descrepancy (Beta 2.21)

Reply #14 –
Well, I'd understand how adding barline could bump a measure off the end of the page if the added barline weren't directly under an already-present barline. That's what this situation was: barlines present for soprano, flute, clarinet, harp....right down through the first violin, then absent from there to the bottom of the score. Don't ask. And yes, I've had the same experience of changing a note to a rest and thus creating a change in flow. Or adding a dynamic with the "preserve width" box unchecked, which theoretically shouldn't add any width at all to the measure it lands in....

Anyway, thanks for the input Rick. I'm glad I'm not the only one finding that lower print quality actually increases print size. It isn't rounding errors: if you compare my two printed page fives, you can see that the print is significantly larger at the lower print quality setting. The difference is measurable. With staff metrics set to 14 points, a five-line staff is exactly 5mm wide (top to bottom) in Fast Normal. It's 5.5mm wide in Fast Draft. Go figure.

Cheers,

Bill

Re: Beam angle descrepancy (Beta 2.21)

Reply #15 –
Quote from: William Ashworth –
Well, I'd understand how adding barline could bump a measure off the end of the page if the added barline weren't directly under an already-present barline.
If you have one staff that has an accidental and it is missing a barline, adding the barline will change the width.
Quote from: Staff-1
!NoteWorthyComposerClip(2.0,Single)
|Rest|Dur:Whole
|Bar
|Note|Dur:Whole|Pos:0
!NoteWorthyComposerClip-End
Quote from: Staff-2
!NoteWorthyComposerClip(2.0,Single)
|Rest|Dur:Whole
|Note|Dur:Whole|Pos:b0
!NoteWorthyComposerClip-End
Registered user since 1996

Re: Beam angle descrepancy (Beta 2.21)

Reply #16 –
Granted - the barline here takes up part of the space that had been occupied by the accidental, pushing the accidental to the right. OK. But that wasn't the situation here. No accidentals. Notes held across the barline in most of the parts (and all of the parts with missing barlines, which is part of how they went missing). No excuses. Anyway, we've determined that the problem was caused by the change in print quality, so the barline is pretty much a dead horse. ;-)

Bill

Re: Beam angle descrepancy (Beta 2.21)

Reply #17 –
In Rick's example BeamExample1.nwc, there are rests in the bass staff under the stem down notes in the treble, but there aren't rests in the treble above the bass staff stem up notes.  Is this unintentional, or is there a rule I'd like to know about?

Re: Beam angle descrepancy (Beta 2.21)

Reply #18 –
Quote from: David Palmquist –
Is this unintentional, or is there a rule I'd like to know about?
Unintentional. They should be in both or neither staves.
Registered user since 1996