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". uliska@uliska-lmde-laptop:~/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 > [email protected] > https://lists.gnu.org/mailman/listinfo/bug-lilypond _______________________________________________ bug-lilypond mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-lilypond
