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

[Urs Liska]

Hi James,

thanks for the explanations.

No, I don't know about an Allura account. Or were they automatically
copied over from the Google tracker, the Rietveld tool or the LilyPond
Git repository?

Thanks
Urs

Am 19.11.2015 um 15:06 schrieb James:
> Urs,
>
> run git-cl config again (make sure you have recently pulled as there
> were some fixes).
>
> The Allura Server URL is
>
> https://sourceforge.net/p/testlilyissues/issues/]
>
> You then need to set up a token in your Allura Login 'account settings'
> (you have a login to that site right?), select the Oauth tab and create
> your own 'Bearer token' - it should be obvious how to do that. Then you
> can use that value as the final entry for your git-cl config when it
> asks you for it.
>
> Now it should all work,
>
> James
>
>
>
>
>
> The Allura Server URL is
>
> On 19/11/15 13:57, Urs Liska wrote:
>> 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
>> _______________________________________________
>> bug-lilypond mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>>
>>