lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: James
Subject: Re: SubdivideBeam gives undesired result when beaming over more than a quarter note
Date: Thu, 19 Nov 2015 14:14:44 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

Urs

On 19/11/15 14:09, Urs Liska wrote:
> 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

Send an email to Trevor or Phil, they can set you up with one.

James

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]