On Sat, 17 Oct 2020 at 18:29, Marc Shepherd wrote:
>
> Kieren's example does indeed work with LP 2.21.2. However, the
distribution for 2.21.2 seems to "break" a number of other functions; for
instance, \fermataMarkup no longer works.
>
> Anyhow, I am still in the market for a better way to do
Le 17/10/2020 à 18:28, Marc Shepherd a écrit :
Kieren's example does indeed work with LP 2.21.2. However, the
distribution for 2.21.2 seems to "break" a number of other functions;
for instance, \fermataMarkup no longer works.
Use \fermata.
Kieren's example does indeed work with LP 2.21.2. However, the distribution
for 2.21.2 seems to "break" a number of other functions; for instance,
\fermataMarkup no longer works.
Anyhow, I am still in the market for a better way to do this, but for the
time being will just turn off bar numbers
Hi Marc,
> In your example, the rehearsal letters printed twice at the top of the winds
> group. I don't know if it matters that I am on version 2.20
It may.
> Also, if I am reading the code correctly, in a passage where only the brass
> and strings play, no marks would print on that system.
If you want to try 2.21.2 (as opposed to 2.21.7) see
https://lilypond.org/download/binaries/mingw/ for which Windows releases (for
example) are available for download.
On 17/10/2020 15:46, Marc Shepherd wrote:
Hi Kieren,
In your example, the rehearsal letters printed twice at the top of the
Hi Kieren,
In your example, the rehearsal letters printed twice at the top of the
winds group. I don't know if it matters that I am on version 2.20, whereas
you specified 2.21.2, which is not publicly available from the LP website.
Also, if I am reading the code correctly, in a passage where
Hi Marc,
> What I want is to print the MarkLine twice, once above Violin I, and once at
> the top of each system.
In recent versions, you can just add the engravers to the appropriate
StaffGroup contexts (see below). Does that solve your problem?
Cheers,
Kieren.
\version "2.21.2"
As I am a very new LP user, I copied the code from various snippets. What I
want is to print the MarkLine twice, once above Violin I, and once at the
top of each system. The actual top staff will not always be the same from
one system to the next, because not all instruments are playing all the
This is an orchestral score, where the convention is to print tempo and
rehearsal marks twice, at the top of the system and above the first violin
staff. In the LP documentation, the recommended way to do this is to create
a separate context called “MarkLine” for rehearsal and tempo marks.
So
On Fri, Oct 16, 2020 at 4:28 PM Marc Shepherd wrote:
> Here is a minimal example showing this behavior:
>
> \version "2.20.0"
>
> \layout {
> \context {
> \name MarkLine
> \type Engraver_group
> \consists Output_property_engraver
> \consists Axis_group_engraver
> \consists
Am Sa., 17. Okt. 2020 um 00:28 Uhr schrieb Marc Shepherd <
oakapp...@gmail.com>:
> Here is a minimal example showing this behavior:
>
> \version "2.20.0"
>
> \layout {
> \context {
> \name MarkLine
> \type Engraver_group
> \consists Output_property_engraver
> \consists
Here is a minimal example showing this behavior:
\version "2.20.0"
\layout {
\context {
\name MarkLine
\type Engraver_group
\consists Output_property_engraver
\consists Axis_group_engraver
\consists Mark_engraver
\consists Metronome_mark_engraver
\override
On Fri, 16 Oct 2020 at 20:55, Marc Shepherd wrote:
>
> In the example shown below, lilypond is shifting the measure number (85)
down, because it thinks there is a collision with the rehearsal letter "C".
But in fact there is no collision: the 85 would be just fine in its normal
position. This
In the example shown below, lilypond is shifting the measure number (85)
down, because it thinks there is a collision with the rehearsal letter "C".
But in fact there is no collision: the 85 would be just fine in its normal
position. This occurs only where a rehearsal letter coincides with the
I think it would be hard to write macros to approximate strokes with
lines.
Well, right now I'm rewriting the parmesan stuff to make it work with
mf2pt1 (the feta stuff has already be done two years ago). After this
has been finished, only `fill' and `unfill' is used, and `draw' and
`drawdot'
Graham Percival gpermus at gmail.com writes:
What about giving a StaffGroup some width? I'm thinking of your recent
fix for #352. I mean, if there's a StaffGroup grob then we want the bar
numbers to be higher; if there's no StaffGroup grob then we don't want
to move the bar numbers.
Of
The solution for this is to use more accurate glyph outlines than
bounding boxes. I hope to do this at some point, but it is
non-trivial.
Making metafont emit improved data on glyph outlines is quite easy.
The very question is *what* shall it emit...
Can you elaborate on this?
Werner
On Monday 23 April 2007 14:38, Werner LEMBERG wrote:
The solution for this is to use more accurate glyph outlines than
bounding boxes. I hope to do this at some point, but it is
non-trivial.
Making metafont emit improved data on glyph outlines is quite easy.
The very question is *what*
On Monday 23 April 2007 09:23, Graham Percival wrote:
Joe Neeman wrote:
On Monday 23 April 2007 05:49, Maximilian Albert wrote:
Reinserting the above line manually in scm/define-grobs.scm and
comparing it with Mats' solution yields exactly the same result for
staves with brackets, but for
Making metafont emit improved data on glyph outlines is quite
easy. The very question is *what* shall it emit...
Can you elaborate on this?
If it could emit a list of line segments that approximates the
boundary of the glyph, that would be _very_ useful.
Please take an arbitrary
On Tuesday 24 April 2007 00:39, Werner LEMBERG wrote:
Making metafont emit improved data on glyph outlines is quite
easy. The very question is *what* shall it emit...
Can you elaborate on this?
If it could emit a list of line segments that approximates the
boundary of the glyph,
Hello all,
Jason Merrill wrote:
I'm having a problem with the measure numbers colliding with the staff
tie (not sure of the correct name for the thing that ties two staffs
together).
Graham Percival wrote:
This has been fixed in 2.11;
I am using version 2.11.21 and the measure numbers
Quoting Zoltán Selyem [EMAIL PROTECTED]:
I'm sure there must be a way to move those numbers around manually,
but I haven't looked that hard for it yet.
I usually change the extra-offset property of BarNumber:
%---
\version 2.11.21
\new StaffGroup
Zoltán Selyem wrote:
Hello all,
Jason Merrill wrote:
I'm having a problem with the measure numbers colliding with the staff
tie (not sure of the correct name for the thing that ties two staffs
together).
Graham Percival wrote:
This has been fixed in 2.11;
I am using version 2.11.21 and
Graham Percival schrieb:
This has been fixed in 2.11; please wait until the next stable release
(2.12) comes out.
http://code.google.com/p/lilypond/issues/detail?id=98can=1q=collision%20numbers
On that page it says that the fix already happend in 2.11.5. Looking at
the git diff output, Joe at
On Monday 23 April 2007 05:49, Maximilian Albert wrote:
Graham Percival schrieb:
This has been fixed in 2.11; please wait until the next stable release
(2.12) comes out.
http://code.google.com/p/lilypond/issues/detail?id=98can=1q=collision%2
0numbers
On that page it says that the fix
Joe Neeman schrieb:
Is there an easy way to make this setting only work in the former case?
(Hm, probably not, otherwise it would probably already be implemented;))
Of course, it's not a big deal to add the padding property manually to
each score if needed, but I think eventually lily should
Joe Neeman wrote:
On Monday 23 April 2007 05:49, Maximilian Albert wrote:
Reinserting the above line manually in scm/define-grobs.scm and
comparing it with Mats' solution yields exactly the same result for
staves with brackets, but for ungrouped staves it does indeed look ugly.
Is there an
I'm having a problem with the measure numbers colliding with the staff
tie (not sure of the correct name for the thing that ties two staffs
together). I'm running OS X 10.4 . Below is a fairly minimal example
that produces the problem for me. If others find the code doesn't
create the problem
29 matches
Mail list logo
