Re: SubdivideBeam gives undesired result when beaming over more than a quarter note

[Urs Liska]

I've implemented a fix for this (hey, my first working C++ patch :-) )
but now I'm stumbling over the new git-cl workflow (sorry, when that was
set up I didn't have the time to follow closely enough, and the CG
section on uploading patches doesn't seem to be updated yet).

I manage to do the web authentication and upload the patch to Rietveld,
but got stuck at

```
Issue created. URL: http://codereview.appspot.com/278060043
Uploading base file for lily/beaming-pattern.cc
This has been identified with issue 4355.
Is this correct? [y/n (y)]n
4355 will not be used as a google tracker number.
Please enter a valid google tracker issue number
(or enter nothing to create a new issue):
Command "git config allura.token" failed.
You must configure your review setup by running "git cl config".
address@hidden:~/git/lilypond/source$ git cl config
Rietveld server (host[:port]) [codereview.appspot.com]:
Allura server []:
You must provide the address of the Allura tracker server:
```

What should I do now?

Urs


Am 19.11.2015 um 10:43 schrieb Urs Liska:
> Since the fix for #4355, respectively commits 8fa2d858 and 0382ed88, it
> is not possible anymore to subdivide beams that are longer than a
> quarter note.
>
> \version "2.19.32"
>
> {
>   \set subdivideBeams = ##t
>   % This is correctly subdivided
>   \set baseMoment = #(ly:make-moment 1 8)
>   \repeat unfold 16 c'16
>  
>   % This should always keep one beam
>   \set baseMoment = #(ly:make-moment 1 4)
>   c' 16 [ \repeat unfold 14 c' c' ]
>  
> }
>
> The behaviour is consistent with the feature request for #4355, namely:
> the dividing beam should reflect the length of the following group,
> which is 1/4 and results in no beam.
>
> However, I think that this behaviour should be changed once more in that
> subdivideBeam leaves *at least* one beam.
>
> I admit I don't understand the modified code as per 0382ed88:
>
>   // Set the count on each side of the stem
>   // We need to run this code twice to make both the
>   // left and the right counts work properly
>   for (int i = 0; i < 2; i++)
>     for (vsize i = 1; i < infos_.size () - 1; i++)
>       {
>         Direction non_flag_dir = other_dir (flag_directions[i]);
>         if (non_flag_dir)
>           {
>             int importance = infos_[i + 1].rhythmic_importance_;
>             int count = (importance < 0 && options.subdivide_beams_)
>                         ? subdivide_beam_count
>                         : min (min (infos_[i].count (non_flag_dir),
>                                         infos_[i + non_flag_dir].count
> (-non_flag_dir)),
>                                    infos_[i - non_flag_dir].count
> (non_flag_dir));
>
>             infos_[i].beam_count_drul_[non_flag_dir] = count;
>           }
>       }
>
> so I don't know whether it would be better to
> - only consider values smaller than 1/4 in the calculation or
> - ensure (in the last line?) that at least one beam is left.
>
> I hope this is an easy fix.
>
> Urs
>
> _______________________________________________
> bug-lilypond mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/bug-lilypond