add fermata markup commands

add fermata markup commands

Like the markup command \fermata and \fermataMarkup there are now:
\shortfermata, \longfermata, \verylongfermata
\shortfermataMarkup, \longfermataMarkup, \verylongfermataMarkup

contains also: add fermata markup commands to docs

[lemzwerg, 2019-02-28 09:15:44]

LGTM.  However, I'm not completely happy with it.  What about making \fermata
(and \fermataMarkup) accept an optional argument that indicates the type:

  \fermata 'short
  \fermata 'veryLong
  \fermata "arbitrary markup stuff"

[Malte Meyn, 2019-02-28 09:21:34]

On 2019/02/28 09:15:44, lemzwerg wrote:
> LGTM.  However, I'm not completely happy with it.  What about making \fermata
> (and \fermataMarkup) accept an optional argument that indicates the type:
> 
>   \fermata 'short
>   \fermata 'veryLong

I’m not sure whether that would be an improvement; I used the same names as for
the scripts as it is done with \fermata[Markup]:

% currently possible
\markup \fermata
{ b1-\fermata R\fermataMarkup }

% after this patch
\markup \verylongfermata
{ b1-\verlylongfermata R\verylongfermataMarkup }

\fermata 'verylong isn’t easier to type or to remember than \verylongfermata
IMHO.

>   \fermata "arbitrary markup stuff"

We definitely don’t need that. If you want a script, just use the correct
command like -. or \staccato or a TextScript. If you want a markup, just write
\markup "foo" instead of \markup \fermata "foo". If you want to center something
above a MultiMeasureRest, just use { R1-"foo" } instead of { R1-\fermataMarkup
"foo" }.

[lemzwerg, 2019-02-28 09:38:10]

On 2019/02/28 09:21:34, Malte Meyn wrote:
> On 2019/02/28 09:15:44, lemzwerg wrote:
> > LGTM.  However, I'm not completely happy with it.  What about making
\fermata
> > (and \fermataMarkup) accept an optional argument that indicates the type:
> > 
> >   \fermata 'short
> >   \fermata 'veryLong
> 
> I’m not sure whether that would be an improvement; I used the same names as
for
> the scripts as it is done with \fermata[Markup]:
> 
> % currently possible
> \markup \fermata
> { b1-\fermata R\fermataMarkup }
> 
> % after this patch
> \markup \verylongfermata
> { b1-\verlylongfermata R\verylongfermataMarkup }
> 
> \fermata 'verylong isn’t easier to type or to remember than \verylongfermata
> IMHO.
> 
> >   \fermata "arbitrary markup stuff"
> 
> We definitely don’t need that. If you want a script, just use the correct
> command like -. or \staccato or a TextScript. If you want a markup, just write
> \markup "foo" instead of \markup \fermata "foo". If you want to center
something
> above a MultiMeasureRest, just use { R1-"foo" } instead of { R1-\fermataMarkup
> "foo" }.

[lemzwerg, 2019-02-28 09:41:26]

[Oops, pressed the wrong button]

The idea of

  \fermata 'foo

is its open endedness; you don't have to define a new command for a new fermata
type.  I'm a fan of a smaller set of multiplex commands instead of a larger set
of specific macros (which a user could always define by herself).  However, this
is probably just me.

[thomasmorley651, 2019-02-28 09:44:46]

On 2019/02/28 09:41:26, lemzwerg wrote:
> [Oops, pressed the wrong button]
> 
> The idea of
> 
>   \fermata 'foo
> 
> is its open endedness; you don't have to define a new command for a new
fermata
> type.  I'm a fan of a smaller set of multiplex commands instead of a larger
set
> of specific macros (which a user could always define by herself).  However,
this
> is probably just me.

How about a generic \fermata and derived from it the others?
Like for \tie and \over/undertie

[Malte Meyn, 2019-02-28 09:50:17]

On 2019/02/28 09:41:26, lemzwerg wrote:
> [Oops, pressed the wrong button]
> 
> The idea of
> 
>   \fermata 'foo
> 
> is its open endedness; you don't have to define a new command for a new
fermata
> type.  I'm a fan of a smaller set of multiplex commands instead of a larger
set
> of specific macros (which a user could always define by herself).  However,
this
> is probably just me.

Hm … Would this apply to the already existing script commands \shortfermata
etc.? Then we would need a convert-ly rule.

And maybe we should take that opportunity to add a very short fermata and the
Henze variants to comply SMuFL:
https://w3c.github.io/smufl/gitbook/tables/holds-and-pauses.html

[lemzwerg, 2019-03-04 05:04:30]

> Hm … Would this apply to the already existing script commands
> \shortfermata etc.? Then we would need a convert-ly rule.

Good question.  I see arguments for both directions, i.e., whether to stay with
the commands, or to remove them.

[Malte Meyn, 2019-04-28 08:16:18]

Include very short/Henze fermatas. Don’t make markup commands.

[Malte Meyn, 2019-04-29 06:14:40]

fix documentation

[Malte Meyn, 2019-04-29 06:19:41]

On 2019/04/29 06:14:40, Malte Meyn wrote:
> fix documentation

This time I did a make doc-stage-1 for english and german docs. I hope that’s
enough …

[lemzwerg, 2019-04-29 20:15:30]

I wonder whether it makes sense to use more camel case for the macro names, this
is, \shortFermata, \longFermata, etc.

[Malte Meyn, 2019-04-30 07:56:05]

On 2019/04/29 20:15:30, lemzwerg wrote:
> I wonder whether it makes sense to use more camel case for the macro names,
this
> is, \shortFermata, \longFermata, etc.

Hm … that would need new names also for other scripts like \reverseTurn,
\halfOpen and probably many others like \prallMordent, \prallPrall, \upMordent,
\snapPizzicato, \signumCongruentiae.

What happened to GLISS? camelCase vs. lowercase and others is mentioned in
section 14.7 of the CG …

[dak, 2019-04-30 09:19:16]

lilypond@maltemeyn.de writes:

> On 2019/04/29 20:15:30, lemzwerg wrote:
>> I wonder whether it makes sense to use more camel case for the macro
> names, this
>> is, \shortFermata, \longFermata, etc.
>
> Hm … that would need new names also for other scripts like \reverseTurn,
> \halfOpen and probably many others like \prallMordent, \prallPrall,
> \upMordent, \snapPizzicato, \signumCongruentiae.
>
> What happened to GLISS? camelCase vs. lowercase and others is mentioned
> in section 14.7 of the CG …
>
> https://codereview.appspot.com/344160043/

GLISS has fallen a bit by the wayside: as I understand it, it was to a
good degree an endeavor driven by non-programmers (at least not core
programmers) to get focused proposals for better human interfaces for
LilyPond that programmers then can tackle.  The composition of core
programmers and users and the balance of things being hardwired into
LilyPond (where simple changes required a core programmer) and things
being programmable at an advanced user level as long as they met certain
limitations has significantly shifted since then, and so have the
discussion and decision and code making processes.

Like with many slow-moving changes, not everything that was a good idea
remains as desirable as it once was and as the way to do things changes,
the set of people enjoying doing them also changes, partly because of a
change in the actual matter at hand, partly because of changes in the
community doing them.

Whether you want to call it GLISS or not, consistency in interfaces does
make some sense but it usually is a good idea to work on those mostly
when there is a comparatively fresh stable branch out.

-- 
David Kastrup