[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: |
Urs Liska |
Subject: |
Re: SubdivideBeam gives undesired result when beaming over more than a quarter note |
Date: |
Fri, 20 Nov 2015 00:20:58 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 |
Thanks. Obviously it worked now and I have successfully created
https://sourceforge.net/p/testlilyissues/issues/4664/ and
https://codereview.appspot.com/278060043
However, I have a question: Where are the CLI messages defined that are
used in the git-cl process? This is still talking about Google issue
tracker items.
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
>>
>>