>> However,
>>
>> \musicFunction 4
>>
>> could be an integer or a duration, and
>>
>> \musicFunction -4
>>
>> could be an integer or a fingering, depending on how musicFunction
>> is defined, [...]
>
> Thanks, I didn't think of music functions.
In the NR, most such functions have its argument
Hi Werner,
In the NR, most such functions have its argument starting with `#`,
for example
```
\ottava #-2
```
Are there still cases where `#` is mandatory for numbers? Otherwise
the documentation could be updated to remove all `#`.
Yes, there are: In markup, for example.
\markup
Le 26/11/2022 à 11:32, Lukas-Fabian Moser a écrit :
Hi Werner,
In the NR, most such functions have its argument starting with `#`,
for example
```
\ottava #-2
```
Are there still cases where `#` is mandatory for numbers? Otherwise
the documentation could be updated to remove all `#`.
Hi Jean,
FWIW, the last one
a4_boringly
is something I wouldn't do, since
a_boringly
does not work
Yes, d'accord.
Personally, I tend to leave out # when possible for numbers,
and also leave out #' for symbols when possible because it
is not only shorter, but allows the syntax
Jean Abou Samra writes:
>> \version "2.23.10"
>>
>> \removeWithTag dyn \new Staff = upper {
>> \tag dyn <>\mf
>> \ottava -1
>> a4_boringly
>> }
>>
>> But of course there's always the danger of beginners tripping up on
>> this because they do not recognise the situations where #/'/"" are
>>
>>> Are there still cases where `#` is mandatory for numbers?
>>> Otherwise the documentation could be updated to remove all `#`.
>>
>> Yes, there are: In markup, for example.
>>
>> \markup \fontsize 3 Hi
>>
>> is still illegal.
OK, but where exactly is this documented? Is this missing, or am I
Le 26/11/2022 à 16:16, Werner LEMBERG a écrit :
OK, but where exactly is this documented? Is this missing, or am I
blind?
I think it's not written anywhere.
If it is missing, could a Scheme expert please write some
lines that I could incorporate into an MR?
Nothing complicated: If a
Lukas-Fabian Moser writes:
> \override NoteHead.color = red
>
> actually lowers the barrier immensely compared with
>
> \override NoteHead #'color = #red
red and #red are completely different Scheme entities.
> - of course that's more than one syntax simplificiation here, but it
> shows how
On Sat, 2022-11-26 at 13:36 -0800, Eric Benson wrote:
> In anticipation of the impending release of 2.24, I recently ported my
> Lilypond files from 2.22 to 2.23.81. I have about 100 lead sheets with
> lyrics, parameterized so that I can easily create them in different keys
> and in treble clef or
Am 26.11.22 um 18:11 schrieb David Kastrup:
\override NoteHead.color = red
actually lowers the barrier immensely compared with
\override NoteHead #'color = #red
red and #red are completely different Scheme entities.
Yes indeed (I suspect red gets parsed to #'red, no?). I never took the
> Yes indeed (I suspect red gets parsed to #'red, no?). I never took
> the time to find out what's happening there behind the scenes, but
> as a frequent user of the colors "darkred" and "darkgreen", I'm a
> bit nervous about:
>
> lukas@Aquarium:~/git/lilypond/scm(master)$ git grep darkred
>
Why the difference in value? Red is 10% off, green more like 30%?
What's up with that?
L
On Sat, 26 Nov 2022, 19:21 Werner LEMBERG, wrote:
>
> >>> lukas@Aquarium:~/git/lilypond/scm(master)$ git grep darkred
> >>> color.scm:(darkred 0.54509803921568623 0 0)
> >>>
Indeed, you even had said before. Thanks Werner
L
On Sat, 26 Nov 2022, 21:55 Werner LEMBERG, wrote:
>
> > Why the difference in value? Red is 10% off, green more like 30%?
>
> Different standards (terminal colors vs. X11/CSS): identical names but
> different colours.
>
>
>Werner
>
>> OK, thanks. I wonder how the heuristics could be improved. Given
>> that a lyric hyphen must be preceded by whitespace, while normally
>> `--` as an articulation is following a non-whitespace character,
>> maybe a look-behind assertion for the latter would help? Something
>> similar could
lukas@Aquarium:~/git/lilypond/scm(master)$ git grep darkred
color.scm: (darkred 0.54509803921568623 0 0)
output-lib.scm:(define-public darkred '(0.5 0.0 0.0))
lukas@Aquarium:~/git/lilypond/scm(master)$ git grep darkgreen
color.scm: (darkgreen 0 0.39215686274509803 0)
>>> lukas@Aquarium:~/git/lilypond/scm(master)$ git grep darkred
>>> color.scm: (darkred 0.54509803921568623 0 0)
>>> output-lib.scm:(define-public darkred '(0.5 0.0 0.0))
>>>
>>> lukas@Aquarium:~/git/lilypond/scm(master)$ git grep darkgreen
>>> color.scm: (darkgreen 0
Am 26.11.22 um 18:35 schrieb Lukas-Fabian Moser:
Am 26.11.22 um 18:11 schrieb David Kastrup:
\override NoteHead.color = red
actually lowers the barrier immensely compared with
\override NoteHead #'color = #red
red and #red are completely different Scheme entities.
Yes indeed (I suspect
> Why the difference in value? Red is 10% off, green more like 30%?
Different standards (terminal colors vs. X11/CSS): identical names but
different colours.
Werner
On Sat, 2022-11-26 at 22:25 +0100, Paolo Prete wrote:
> Hello,
>
> The new releases of LilyPond show how simple it is currently to install the
> program: it is simply a matter of unpacking an archive wherever you want.
>
> This is very powerful and it means that any application (see: editors)
>
Hello,
The new releases of LilyPond show how simple it is currently to install the
program: it is simply a matter of unpacking an archive wherever you want.
This is very powerful and it means that any application (see: editors)
using LilyPond is potentially able to install it automagically,
In anticipation of the impending release of 2.24, I recently ported my
Lilypond files from 2.22 to 2.23.81. I have about 100 lead sheets with
lyrics, parameterized so that I can easily create them in different keys
and in treble clef or bass clef. There are all in the range of 1 to 2 pages
when
I compiled it myself, using Xcode's cc (Apple clang version 14.0.0). Got a
ton of warnings, mostly of the form "implicit conversion changes
signedness". These seem like the sort of thing that might not be too hard
to fix. It's a worthwhile goal to eliminate compiler warnings from as many
of the
On Nov 26, 2022, at 17:43, Eric Benson wrote:
>
> ton of warnings, mostly of the form "implicit conversion changes
> signedness". These seem like the sort of thing that might not be too hard
> to fix.
https://gitlab.com/lilypond/lilypond/-/merge_requests/1744 fixes warnings other
than
On Sat, Nov 26, 2022 at 11:07 PM Jonas Hahnfeld wrote:
> On Sat, 2022-11-26 at 22:25 +0100, Paolo Prete wrote:
> > Hello,
> >
> > The new releases of LilyPond show how simple it is currently to install
> the
> > program: it is simply a matter of unpacking an archive wherever you want.
> >
> >
24 matches
Mail list logo
