lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GLISS] non-timed or non-musical events "z" "y"


From: David Kastrup
Subject: Re: [GLISS] non-timed or non-musical events "z" "y"
Date: Sun, 23 Sep 2012 05:29:03 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

Jay Anderson <address@hidden> writes:

> On Sat, Sep 22, 2012 at 3:07 PM, Graham Percival
> <address@hidden> wrote:
>> I have no problem with splitting \tempo into a \tempo_bpm and
>> \tempoMark command.  Or perhaps it would be better to just use
>> \mark, and add markup functions which mimic the "text" parts of
>> the existing \tempo command (if they don't already exist, which
>> they probably do).
>
> Please keep \mark and \tempo separate. They serve different purposes,

Only to some degree.

> align differently with the music, and it's a pain to put multiple
> marks in one place.

I doubt that the ultimate solution to the problem "\mark is far too
limited and restricted" is "let's add another far too limited and
restricted command".

> - \tempoText "Allegro"
> - \tempoBpm 4=100
> - \tempoTextBpm "Allegro" 4=100
> - \tempoEquation 4=2 %%% print quarter note = half note
> - \tempoTextEquation "Lo stesso tempo" 4=2
>
> Even easier: \tempoBpm can take a string instead (e.g. \tempoBpm
> "4=100") which it internally parses and throws an error if it doesn't
> like what it sees. At that point it could be 100% scheme instead of at
> the parser level. The possible downside is we'd have a mini language
> for this function, but I don't think that's too bad.

I don't really like the artificiality of additional string parsers.  It
divides LilyPond into areas with supported and those with unsupported
syntax.  For me, it makes far more sense to only work with consistent
supported syntax, and make sure that this is expressive enough not to be
an onerous restriction.

As I said: I have not yet tackled this actively since at least the
equals sign may still become part of the universe supported by music
functions.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]