Am 09.04.2014 11:53, schrieb Jan Warchoł:
2014-04-04 12:43 GMT+02:00 Urs Liska :
(the
handling of accidentals in the input for example: In Amadeus you write the
"visible" notes, that is: the meaning of "d f a" depends on the currently
active key signature). But some others look interesting, an
Urs Liska writes:
> Am 09.04.2014 11:53, schrieb Jan Warchoł:
>
>> Concerning compilation speed - this is indeed a serious problem for
>> LilyPond, and i don't know which part of the code is most responsible for
>> this. Unfortunately i expect that changing this would require at least one
>> exp
Hi,
2014-04-10 11:51 GMT+02:00 David Kastrup :
> Urs Liska writes:
>
>> Am 09.04.2014 11:53, schrieb Jan Warchoł:
>>
>>> Concerning compilation speed - this is indeed a serious problem for
>>> LilyPond, and i don't know which part of the code is most responsible
for
>>> this. Unfortunately i exp
Post Scriptum:
after rereading my previous email, i see that it sounds as if i believed
that implementing the Ultimate Goal (i.e. automatic engraving) and
effectively improving "efficiency" were mutually exclusive. I don't think
that's the case - in some cases the most effective (= with the bigges
Jan Warchoł writes:
> Or, to look from other perspective: at current development speed, it
> will take LilyPond somewhere between 10 and 100 years to reach the
> stage where it does most of the things The Right Way (TM) (i.e. that
> most of the ordinary scores are engraved 100% publication qualit
Hi,
On Tue, Apr 8, 2014 at 7:53 PM, Paul Morris wrote:
Looks like this can be simplified as follows. Cheers, -Paul
>
> \version "2.19.2"
>
> offsetPositions =
> \override Slur.positions =
> #(lambda (grob)
>(cons
> (cdar (ly:slur::calc-control-points grob))
> (cdar (reverse (ly:slu
That's a difficult issue, and I think you both (Janek and David) are
completely right with what you write.
Nevertheless I think that trying to improve usability _now_ _is_ a good
thing.
A user of a (notation) software usually needs to finish stuff for a
concrete purpose. An engraver will pro
Urs Liska writes:
> That's a difficult issue, and I think you both (Janek and David) are
> completely right with what you write.
>
> Nevertheless I think that trying to improve usability _now_ _is_ a
> good thing.
>
> A user of a (notation) software usually needs to finish stuff for a
> concrete
2014-04-11 0:51 GMT+02:00 David Kastrup :
[...]
> A good part of my work is making it easier for others to do what they
> want.
[...]
... and let me say a big THANK YOU for that ...
Best,
Harm
___
lilypond-devel mailing list
lilypond-devel@gnu.org
htt
Am 11.04.2014 00:51, schrieb David Kastrup:
Urs Liska writes:
That's a difficult issue, and I think you both (Janek and David) are
completely right with what you write.
Nevertheless I think that trying to improve usability _now_ _is_ a
good thing.
A user of a (notation) software usually need
Eric Bavier wrote:
> I'm not very familiar with the development history of lilypond, so while
> trying to sort through the lilypond build one question came to mind: why
> does lilypond use stepmake?
Because the Lilypond authors wrote it. :) According to the
documentation in ancient Lilypond commit
LGTM. This works in clang 3.2, so it took me a while to figure out that
the problem was ambiguity with C++11 std::to_string, which is apparently
defined by default in 3.4.
It would be nice to avoid redefining std::to_string when it's available,
but AFAICT there isn't an easy way to detect it -- i
12 matches
Mail list logo
