add glyphs for 256th, 512th and 1024th flags and rests

add glyphs for 256th, 512th and 1024th flags and rests

This post on lilypond-user asks for small rhythmic values (though it doesn’t explicitely mention rests and unbeamed/flagged notes): https://lists.gnu.org/archive/html/lilypond-user/2018-02/msg00614.html

1024th is the shortest duration suggested by SMuFL.

Needs special focus in review:
• forms of downstem flags

Needs improvement but I don’t know how to do:
• dot position for very short rests (see regtest)

Contains also:
• adjust stem lengths for 256th, 512th, and 1024th flags
• Notation Reference: change shortest value from 128th to 1024th
• add very short rests to regtest

[thomasmorley651, 2018-02-21 22:44:42]

I suggest to update regtests ‘markup-rest.ly’ and ‘markup-rest-styles.ly’ as
well.
If no glyph for a certain style is found the default is taken anyway, but it
would be nice if the new glyphs would be demonstrated via markup as well.
Also, it deserves an entry in changes, imho.

[Malte Meyn, 2018-02-22 15:39:27]

On 2018/02/21 22:44:42, thomasmorley651 wrote:
> I suggest to update regtests ‘markup-rest.ly’ and ‘markup-rest-styles.ly’ as
> well.
> If no glyph for a certain style is found the default is taken anyway, but it
> would be nice if the new glyphs would be demonstrated via markup as well.

Do we really need that triple occurence? OTOH, could you suggest where to
regtest the flags?

> Also, it deserves an entry in changes, imho.

Agreed. There is at least one other patch I made that needs a Changes entry
(issue 5247, maybe 5249, maybe 3208 after 5258 is fixed too) but at the moment
I’m not able to make doc for testing (see list).

[lemzwerg, 2018-02-23 07:30:00]

LGTM, thanks!

[Be-3, 2018-02-23 11:18:38]

On 2018/02/23 07:30:00, lemzwerg wrote:
> LGTM, thanks!

In my opinion, there's a misplacement of rest dots. Therefore,

file scm/output-lib.scm (dots::calc-staff-position)

will have to be adapted, too (see related image and comment in issue #5277)
There's no appropriate code for log > 7 (the new rest glyphs)

My suggestion:
-     ((= log 7) 4)
+     ((>= log  7) (- log 3));

That way, there's no need to add a separate line for each duration.

Just writing this as a comment because I'm terribly unsure about the correct
usage of rietveld and I don't want to mess with Malte's coding.

All the best,
Torsten

[Malte Meyn, 2018-02-23 11:41:13]

On 2018/02/23 11:18:38, Be-3 wrote:
> On 2018/02/23 07:30:00, lemzwerg wrote:
> > LGTM, thanks!
> 
> In my opinion, there's a misplacement of rest dots. Therefore,
> 
> file scm/output-lib.scm (dots::calc-staff-position)
> 
> will have to be adapted, too (see related image and comment in issue #5277)

Thanks for the hint! I looked for it at every single C++ file that has to do
with rests or dots but didn’t know or think about output-lib.scm

> There's no appropriate code for log > 7 (the new rest glyphs)
> 
> My suggestion:
> -     ((= log 7) 4)
> +     ((>= log  7) (- log 3));
> 
> That way, there's no need to add a separate line for each duration.

Probably that won’t be enough, it has to be 7,8 → 4 and 9,10 → 5; but the idea
is correct. Maybe I’ll replace the cond by an if and case ;)

> Just writing this as a comment because I'm terribly unsure about the correct
> usage of rietveld and I don't want to mess with Malte's coding.

Commenting is the correct way in this case. If you want to comment on one of the
files that have been changed you can add a comment to a single code line by
clicking on that line.

[pkx166h, 2018-02-23 12:09:34]

On 2018/02/23 11:18:38, Be-3 wrote:
> On 2018/02/23 07:30:00, lemzwerg wrote:
> > LGTM, thanks!
> 
> In my opinion, there's a misplacement of rest dots. Therefore,
> 
> file scm/output-lib.scm (dots::calc-staff-position)
> 
> will have to be adapted, too (see related image and comment in issue #5277)
> There's no appropriate code for log > 7 (the new rest glyphs)

Are we simply seeing another symptom of something I (when patch testing) have to
now ignore?

See the thread:
https://lists.gnu.org/archive/html/lilypond-devel/2017-09/msg00013.html

James

[Malte Meyn, 2018-02-23 12:52:29]

On 2018/02/23 12:09:34, pkx166h wrote:
> Are we simply seeing another symptom of something I (when patch testing) have
to
> now ignore?
> 
> See the thread:
> https://lists.gnu.org/archive/html/lilypond-devel/2017-09/msg00013.html

No. But I’ll put this patch on needs_work now because it does need work and I
won’t have time to do it for the next two days.

[Be-3, 2018-02-23 16:14:59]

On 2018/02/23 11:41:13, Malte Meyn wrote:
> Probably that won’t be enough, it has to be 7,8 → 4 and 9,10 → 5; but the idea
> is correct. Maybe I’ll replace the cond by an if and case ;)

Ah, yes, it's true that the rest height is identical for 128th/256th and
512th/1024th, therefore my "calculated" values weren't correct (even if the
output was OK).

So I agree on 7,8 → 4, but it has to be 10 → 6 ;)

[Malte Meyn, 2018-03-18 13:16:42]

add Changes entry, add rests to other regtests too, fix dot positions for rests

[Malte Meyn, 2018-03-18 13:18:57]

I’ll change the width of 8th and 16th flags (see
https://lists.gnu.org/archive/html/lilypond-devel/2018-02/msg00107.html) in
another issue.