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 this
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.
http://lilypond.org/doc/v2.21/Documentation/changes
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 sel
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. T
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 w
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 only
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"
\layou
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
tim
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 that
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 M
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 Axis_group
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 VerticalAx
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 occu
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
firs
> 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
2007/4/23, Joe Neeman <[EMAIL PROTECTED]>:
Here is an example of a treble clef. I only need the outermost curves traced,
but it doesn't matter if some other curves are. I don't know exactly what the
resolution needs to be, but it should distinguish between, for example, the
stem and the bottom of
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
> > bound
> > 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 arbi
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 bracke
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 *
> 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
Graham Percival 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 cours
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 easy
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
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=98&can=1&q=collision%2
> >0numbers
>
> On that page it says that
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=98&can=1&q=collision%20numbers
On that page it says that the fix already happend in 2.11.5. Looking at
the git diff output, Jo
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 th
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 <<
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 numb
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).
This has been fixed in 2.11; please wait until the next stable release
(2.12) comes out.
http://code.google.com/p/lilypon
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 f
31 matches
Mail list logo