On 10/31/18, 7:32 PM, "Dan Eble" wrote:
On Oct 31, 2018, at 14:00, carl.d.soren...@gmail.com wrote:
>
> Why not always have our sort use stable_sort?
Because when someone finally clears away std-vector.hh, they will be more
likely to mess it up if sort() needs to be
(I'm surprised this hasn't been fixed until now.)
Welcome to LilyPond, where you supply the fixes. Your change looks good
to me, but judging from your questions, it sounds like it could be
tested better.
Have you read the chapter on Regression Tests in the Contributor's
Guide? You should
On Wed, Oct 31, 2018 at 5:46 PM Hans Åberg wrote:
> Is this right? It is traditional to raise the third below the finalis, but
> not in the octave above, and it looks as though is a. I found this [1], it
> has an additional accidental at e.
>
> Then the finalis should also be the key, as it is
On Oct 31, 2018, at 14:00, carl.d.soren...@gmail.com wrote:
>
> Why not always have our sort use stable_sort?
Because when someone finally clears away std-vector.hh, they will be more
likely to mess it up if sort() needs to be transformed into stable_sort() than
if the functions parallel those
On Wed, Oct 31, 2018 at 5:06 PM Torsten Hämmerle
wrote:
> When applying my solution to your bestenigar and revnaknuma examples
> (denoted "Torsten's mod") perfectly matches your manually tweaked "should
> look like this" versions.
> That's pretty good for a start (and it's transposable), but
> On 31 Oct 2018, at 19:51, Adam Good wrote:
>
> I have issues in that the tonic of these makams is a microtone. In standard
> Turkish notation, "fb" which is "f" 4k sharp
> We need
> \key fb \bestenigar
Is this right? It is traditional to raise the third below the finalis, but not
in the
Adam Good-3 wrote
> Attached is a shortish example showing that Rast and Segah transposition
> works great and shows bestenigar and revnaknuma with the fb in the key
> signature with two examples of what Bestenigar and Revnaknuma should look
> like.
Hi Adam,
When applying my solution to your
I've built two versions of lilypond to measure the performance impact of
always
using `stable_sort`.
The baseline (reference) is commit 964722f804 without any
modifications and the second build just changes `vector_sort` to use
`sort_stable`. The test file is from Mutopia-2015/11/04-2050
Torsten and everyone greetings,
RE: the key signatures for Turkish makam, I've made definitions for about
91 different makams like Rast, Hicaz, Segah, etc. These definitions are in
the turkish-makam.ly file, attached. We need each makam's key signature to:
1. look as they do in standard print
Why not always have our sort use stable_sort?
Have you tried with a large score (e.g. one from mutopia) to see what
the resource implications are?
https://codereview.appspot.com/353790043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Reviewers: ,
Message:
Hi all,
this is a patch to fix the issue described here:
https://lists.gnu.org/archive/html/lilypond-user/2015-02/msg00035.html
(I'm surprised this hasn't been fixed until now.)
I'm not familiar with lilypond internals at all so I don't know whether
this is correct way to
Hi Bobo
I'd like to request write access to the Sourceforge issue tracker.
I've written a small patch to fix the issue described here:
https://lists.gnu.org/archive/html/lilypond-user/2015-02/msg00035.html
Following the contributor's guide I'm currently setting up `git-cl` and
therefore
Hi all,
I'd like to request write access to the Sourceforge issue tracker.
I've written a small patch to fix the issue described here:
https://lists.gnu.org/archive/html/lilypond-user/2015-02/msg00035.html
Following the contributor's guide I'm currently setting up `git-cl` and
therefore require
13 matches
Mail list logo