2014-04-01 18:05 GMT+02:00 Urs Liska :
> Would please someone push the attached patches?
pushed to staging as
$ git log --oneline -2
b03be2f Issue 3890: Add doc for dodecaphonic-first accidental style
deb20df Issue 3890: Add dodecaphonic-first accidental style
___
> Okay, so I'm not crazy. I happened to keep an old repo from
> four years ago, and as you can see from the attached image,
> the two histories are not the same, and neither are the
> commit SHA1 IDs... How did this happen, and could it happen
> again?
could you track down the first divergence a
2014-07-27 9:54 GMT+02:00 David Kastrup :
> Benkő Pál writes:
>
>>> Okay, so I'm not crazy. I happened to keep an old repo from
>>> four years ago, and as you can see from the attached image,
>>> the two histories are not the same, and neither are the
>&
>>> > Documentation/notation/ancient.itely:2651: an indication of how the
>>> > initial rests and note of the original version
>>> > notes
>>> >
>>> > https://codereview.appspot.com/108270043/
>>> >
>>
>>
>>> No - it should be "note". A standard incipit has all the rests
>>> leading to the first n
> I don’t recall that anybody so far has been able to explain how they know a
> piece is in 4/2 when it is denoted cut-C. Can you?
as well as knowing whether a customary C (cut or uncut) signals 2/2 or
4/4 (or 1/1, see below).
I maintain that the second Kyrie from Bach's Mass in B minor is in
4
hello Lukas,
> here's my next portion of patches for the extended mensural notation support
> I mentioned the other day. This bit is to get full support for the various
> options relating to black and hollow (unflagged and flagged) small note
> values (crotchets and below), as discussed in section
>> as far as I know when flagged notes with hollow heads are used, they are
>> used exclusively, i.e. there are no black notes at all (more precisely, all
>> black notes count as notae coloratae, which is a separate notehead style
>> anyway, and from duration point of view they behave just as their
2015-04-25 10:20 GMT+02:00 :
> Thank you for picking this up. It is certainly an improvement already.
>
> However: In an example where 8 32th notes are subdivided by 16th notes
> ony the first and third subdivision should have two beams, the second
> one only one beam.
>
> Put differently: when th
> I suspect that we got ourselves a problem with Ubuntu 15.04.
I got the same assertion, on Lubuntu 15.04.
p
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
2015-06-12 22:20 GMT+02:00 Thomas Morley :
> Though, the current patch for 4428 shows:
> Author: harm
>
> Is there any way to change it to:
> Author: Thomas Morley
> ?
my guess is
git commit --amend --reset-author --no-edit
p
___
lilypond-devel maili
2015-07-18 17:57 GMT+02:00 Federico Bruni :
> What do you think about these instructions?
> http://lilypond.org/doc/v2.19/Documentation/contributor/pushing-to-staging
>
> I have a few comments, but I'm not sure about any of them:
>
> 1. There's no real purpose in pulling and rebasing the staging br
2015-07-18 19:05 GMT+02:00 Federico Bruni :
>> $ git push origin HEAD:staging
>
> That's probably how I would like to work (so I don't need the patch file).
> `git fetch` fetches implicitly from a particular branch?
>
> What's the purpose of HEAD:staging?
moves the branch on remote to your recentl
> I don't have double flat examples from real music
Das Wohltemperierte Klavier has some double flats,
look at the E-flat and B-flat minor pieces.
as far as I can see, 19th century scores use two identical flats for a
double flat,
while early 20th century ones are more like Feta.
p
_
> The migration of the tracker from GC to Allura at SF has gone well.
> Attachments are present and searches work (in the Allura style, which takes
> some getting used to, but is pretty comprehensive.) I've set up some common
> searches to make things easier. You can view it here to inspect a
2015-08-29 11:30 GMT+02:00 Trevor Daniels :
>
> Pál, you wrote Saturday, August 29, 2015 8:21 AM
>>
>> I also noted that explicit links like
>> https://code.google.com/p/lilypond/issues/detail?id=2249
>> are not converted. Again, not a big problem, just some
>> inconvenience in reading old issues.
not exactly abandoned, just needs-work since more than three years:
http://sourceforge.net/p/testlilyissues/issues/2474/
I forgot I was waiting for feedback, as I believe I answered all
raised concerns.
p
___
lilypond-devel mailing list
lilypond-devel@g
2015-10-30 14:46 GMT+01:00 :
> On 2015/10/30 13:20:35, benko.pal wrote:
>>
>> sorry to chime in that late, but:
>> am I right that the problem is that we get the rotation matrix
>> cos a -sin a
>> sin acos a
>> inexact? and if so, how the inexactness is present? one of the
>
> diagonals is
> And PostScript (and PDF and METAFONT) _do_ represent angles in degrees.
> So it's sort of silly that we cannot get an angle of 180 degrees
> straight into PostScript without change.
now that convinced me. if we want to output angles in degrees, we
don't want to switch back and forth neither bet
> Just back home, noticing the discussion here.
>
> Current patch tries to solve (or better: workaround) the problem in
> guile.
> I have some other pending patches _needing_ exact values from
> coord-rotate.
> I'd suggest to push it as is (unless some serious defect would be
> detected) after coun
> At the risk of being blunt: more generally, is there a legitimate use
> case for completion heads? It never occurred to me that some people
> (like Simon, it seems) might rely on it that regularly; I used to
> regard it as one of those feature that seem nice at first but that
> typically tend to
2016-05-31 8:15 GMT+02:00 Federico Bruni :
> I could not push to a /dev/name/branch name. I had to use a short name
> without slashes:
>
> git push origin translation:fedelibre-doc-it
>
> while the following did not work:
>
> git push origin translation:/dev/fede/doc-it
>
> Not a big deal.. but I'd
all,
does anybody know a working e-mail address of his? perhaps do you still
lurk here, Christian?
thanks,
p
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
> c2 \bar "" \break c2 c4
>
> That should be two bars with a barline in the middle.
I think not; \bar "" starts a new bar (after issuing a warning for the
incomplete bar).
p
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/ma
sorry for the noise.
2016. szept. 19. 18:46 ezt írta ("David Kastrup" ):
> Benkő Pál writes:
>
> >> c2 \bar "" \break c2 c4
> >>
> >> That should be two bars with a barline in the middle.
> >
> > I think not; \bar "
2016-11-10 11:46 GMT+01:00 Andrew Bernard :
> David,
>
> I wish you all the very best for your future endeavours. I thank you most
> sincerely for your immensely significant and important contribution to
> making lilypond the exceptional tool for engraving that it is. Having tried
> myself to study
2017-03-04 19:03 GMT+01:00 :
> On 2017/02/25 15:19:47, felix.janda_posteo.de wrote:
>>
>> The fix probably breaks compilation on everything not using glibc:
Is lilypond supposed to be built on anything outside GNU/Linux?
___
lilypond-devel mailing list
201 - 226 of 226 matches
Mail list logo
