Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in
(429)

Issue 344160043: add fermata markup commands

Can't Edit
Can't Publish+Mail
Start Review
Created:
4 months, 3 weeks ago by Malte Meyn
Modified:
2 months, 3 weeks ago
CC:
lilypond-devel_gnu.org
Visibility:
Public.

Description

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

Patch Set 1 #

Patch Set 2 : Include very short/Henze fermatas. Don’t make markup commands. #

Patch Set 3 : fix documentation #

Unified diffs Side-by-side diffs Delta from patch set Stats (+62 lines, -15 lines) Patch
M Documentation/changes.tely View 1 2 chunks +11 lines, -12 lines 0 comments Download
M Documentation/included/script-chart.ly View 1 2 1 chunk +5 lines, -2 lines 0 comments Download
M Documentation/notation/expressive.itely View 1 2 1 chunk +3 lines, -0 lines 0 comments Download
M Documentation/notation/notation-appendices.itely View 1 2 3 chunks +20 lines, -1 line 0 comments Download
M ly/script-init.ly View 1 2 chunks +3 lines, -0 lines 0 comments Download
M scm/script.scm View 1 2 chunks +20 lines, -0 lines 0 comments Download

Messages

Total messages: 13
lemzwerg
LGTM. However, I'm not completely happy with it. What about making \fermata (and \fermataMarkup) accept ...
4 months, 3 weeks ago (2019-02-28 09:15:44 UTC) #1
Malte Meyn
On 2019/02/28 09:15:44, lemzwerg wrote: > LGTM. However, I'm not completely happy with it. What ...
4 months, 3 weeks ago (2019-02-28 09:21:34 UTC) #2
lemzwerg
On 2019/02/28 09:21:34, Malte Meyn wrote: > On 2019/02/28 09:15:44, lemzwerg wrote: > > LGTM. ...
4 months, 3 weeks ago (2019-02-28 09:38:10 UTC) #3
lemzwerg
[Oops, pressed the wrong button] The idea of \fermata 'foo is its open endedness; you ...
4 months, 3 weeks ago (2019-02-28 09:41:26 UTC) #4
thomasmorley651
On 2019/02/28 09:41:26, lemzwerg wrote: > [Oops, pressed the wrong button] > > The idea ...
4 months, 3 weeks ago (2019-02-28 09:44:46 UTC) #5
Malte Meyn
On 2019/02/28 09:41:26, lemzwerg wrote: > [Oops, pressed the wrong button] > > The idea ...
4 months, 3 weeks ago (2019-02-28 09:50:17 UTC) #6
lemzwerg
> Hm … Would this apply to the already existing script commands > \shortfermata etc.? ...
4 months, 2 weeks ago (2019-03-04 05:04:30 UTC) #7
Malte Meyn
Include very short/Henze fermatas. Don’t make markup commands.
2 months, 3 weeks ago (2019-04-28 08:16:18 UTC) #8
Malte Meyn
fix documentation
2 months, 3 weeks ago (2019-04-29 06:14:40 UTC) #9
Malte Meyn
On 2019/04/29 06:14:40, Malte Meyn wrote: > fix documentation This time I did a make ...
2 months, 3 weeks ago (2019-04-29 06:19:41 UTC) #10
lemzwerg
I wonder whether it makes sense to use more camel case for the macro names, ...
2 months, 3 weeks ago (2019-04-29 20:15:30 UTC) #11
Malte Meyn
On 2019/04/29 20:15:30, lemzwerg wrote: > I wonder whether it makes sense to use more ...
2 months, 3 weeks ago (2019-04-30 07:56:05 UTC) #12
dak
2 months, 3 weeks ago (2019-04-30 09:19:16 UTC) #13
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
Sign in to reply to this message.

Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld f62528b