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

[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
>
>