Beta 2.08 : Dots placement

Topic: Beta 2.08 : Dots placement (Read 11206 times) previous topic - next topic

Beta 2.08 : Dots placement

19 years ago

I've just downloaded beta 2.08, and its new dots placement. I found it less nice than the previous one (and much harder to read). Is it a standard way to print dotted notes ? (Well... it's the first time a NWC update is not really an improvement). What do you think about that ?

Re: Beta 2.08 : Dots placement

Reply #1 – 19 years ago

Re: Beta 2.08 : Dots placement

Reply #2 – 19 years ago

Quote from: David Palmquist – 19 years ago

I don't recall too much being wrong with the old dot/double dot vertical placement...

The augmentation dot should be centered between the staff lines (or leger lines), whether the note is on a line or in a space.
In NWC, they always touch a line (I can't check this new version, though, as I still am using NWC1 - more on this at some other time...).
If I have time and the score/parts have to look really good, I insert the dots as text items.
Tedious? You bet.

While we're on dot placement, the staccato dot's placement should be centered over (or under) the notehead, but it is slightly to the right.
If I have time...

Re: Beta 2.08 : Dots placement

Reply #3 – 19 years ago

Much discussion of this is in the beta newsgroup.

The old Viewer (prior to Viewer 2.0 Beta 2.02) will still show (and print) the dots the old way. If you have upgraded NWC2 and have problems with the dots, I would advise you not to upgrade your viewer. You can have it both ways until this gets sorted out.

Re: Beta 2.08 : Dots placement - Newly discovered buglet

Reply #4 – 19 years ago

Re: Beta 2.08 : Dots placement

Reply #5 – 19 years ago

G'day Michael,
I'm pretty sure this is an artifact from the decision to use the stem direction to determine which space the dot will be placed in for notes that are on a line.

If you move either of your examples into a space, you go back to one dot! (it's actually amusing to watch it "walk" up and down the staff - oh well, small minds an' all that

I'd say this is a buglet...

Personally, I'd prefer to always see the dots in the space above except when there are 2 voices on a staff. Then, the lower voice should use the lower space only if there is some potential for confusion.

This makes layering a problem though... Perhaps we also need to be able to specify the dot location in the notes' properties page... Maybe also be able to set it for an entire staff, of course we should still be able to override it in the notes properties.

Sorry Eric, this sounds like some more work...

Re: Beta 2.08 : Dots placement

Reply #6 – 19 years ago

Quote from: Lawrie Pardy – 19 years ago

Personally, I'd prefer to always see the dots in the space above except when there are 2 voices on a staff. Then, the lower voice should use the lower space only if there is some potential for confusion.

Should there be a vote, I completely agree... The dot seems far more prominent when it is in the space above. When there is only one note present, it just doesn't look right if the dot is in the lower space, regardless of the stem direction.

Re: Beta 2.08 : Dots placement - Newly discovered buglet

Reply #7 – 19 years ago

Quote from: Michael W. Powell – 19 years ago

NWC2 places two separate dots for the same pitched note. This appears to be wrong and, at the least, confusing. Prior to 2.08 NWC2 and in NWC1 a "doubled" note that was dotted had the dots overlapped in the same spot so that they were indistinguishable from each other. As a musician, this is what I am accustomed to seeing in orchestral and band music and in church hymnals.

Your example is exactly what you will find in the Official Hymnal of the Protestant Episcopal Church of the USA. 1940 edition, printed in 1961. Presbyterians (1933), OTOH, place 1 dot, sometimes below, other times above, Methodists (1964) place 1 dot above. Look at the tune: ITALIAN HYMN in your favorite hymnal.

In the beta newsgroup, in topic: "Misplaced dots after dotted notes", I posted an example (Episcopal 349 - 350.tif.jpg).

In the same thread is: rg_Dots02.nwc, 35 examples of how G. Schirmer handles dots in chords containing a second.

This code fixes your 1st problem. The half note would need a layer (I think).

Code: [Select · Download]

!NoteWorthyComposerClip(2.0,Single)
|Clef|Type:Treble
|Key|Signature:Bb,Eb,Ab
|Chord|Dur:4th|Pos:-6|Opts:Stem=Down|Dur2:4th,Dotted|Pos2:-6
|Rest|Dur:8th|Opts:Stem=Down|Visibility:Never
|Chord|Dur:8th|Pos:-5|Opts:Stem=Up|Dur2:8th|Pos2:-6
|Chord|Dur:4th|Pos:-4|Opts:Stem=Up|Dur2:4th|Pos2:-6
|Chord|Dur:4th|Pos:-3|Opts:Stem=Up|Dur2:4th|Pos2:-6
|Bar
|Chord|Dur:Half,Dotted|Pos:-2|Opts:Stem=Up|Dur2:Half,Dotted|Pos2:-2
|Rest|Dur:4th
!NoteWorthyComposerClip-End

The fix I am using is to put the dots in as text when I don't like NWC2's. My font editor is my friend.

Re: Beta 2.08 : Dots placement

Reply #8 – 17 years ago

Re: Beta 2.08 : Dots placement

Reply #9 – 17 years ago

Quote from: David Palmquist – 17 years ago

It looks wrong and it is disconcerting. I thought the problem would have been solved a while back, but I guess I'm wrong.

There are still many dot placement bugs. Some are worse than others.
I would think that your clip is one of the harder ones to fix. Consider:

Quote

!NoteWorthyComposerClip(2.0,Single)
|TimeSig|Signature:6/8
|Chord|Dur:4th|Pos:1|Opts:Stem=Up|Dur2:4th,Dotted|Pos2:-6,-2
|Note|Dur:8th|Pos:0|Opts:Stem=Up
|Chord|Dur:4th|Pos:-1|Opts:Stem=Up|Dur2:4th,Dotted|Pos2:-6,-2
|Note|Dur:8th|Pos:0|Opts:Stem=Up
!NoteWorthyComposerClip-End

IMO, in this context, the dot placement is correct. I don't know how much analysis NWC2 can do to resolve this.

OTOH,

Quote

|Chord|Dur:4th,Dotted|Pos:0,1

Is always wrong and should be fixed.
Until then, this is a workaround that looks and plays correctly:

Quote

!NoteWorthyComposerClip(2.0,Single)
|Note|Dur:Whole,Grace|Pos:3z^|Opts:NoLegerLines,Muted|Visibility:Never
|Chord|Dur:4th,Dotted|Pos:0,1|Opts:Stem=Down|Dur2:Whole|Pos2:3z
!NoteWorthyComposerClip-End

I would think that the simplest rule that gets it 90% right might be optimal, but I don't know what that rule would be. With a simple rule, a user tool could be written that would flag the ambiguous cases so that you don't discover them in front of an audience