2009/7/30 Mark Polesky :
> One question -- would my "parser variable" need to be
> defined in music-functions-init.ly or could I just define it scheme-
> style in autochange.scm?
I think it would be a bit lonely placed in music-functions-init.ly;
using define-public in autochange.scm should be fin
Neil Puttock wrote:
> I suppose you could use a music property, but you wouldn't add it to
> this object's definition.
>
> > I had thought that applyContext was the way to go. But what's a
> > parser variable? Can you give me an example of one?
>
> A good example would be afterGraceFraction, which
2009/7/29 Mark Polesky :
> Can I make it a property of the AutoChangeMusic object?
I suppose you could use a music property, but you wouldn't add it to
this object's definition.
> I had thought that applyContext was the way to go. But what's a parser
> variable? Can you give me an example of one
Neil Puttock wrote:
> > \new PianoStaff \autochange \relative {
> > \set autochangeMargin = #2
> > c8 d e f g f e d
> > c b a g f g a b
> > c d e f g f e d
> > }
>
> Making this a context property would imply some kind of relationship
> with an engraver, so I don't think it's appropriate here
I've tweaked the autochange code a little more and I've been able
to make some of the improvements suggested. It's still under
construction, but I'm posting it so you guys can play with it.
The easiest way to test it would be to just save the
autochange_revised.scm and autochange.ly attachments in
2009/7/22 Mark Polesky :
> These ideas sound ambitious to me, but should anyone want to try
> implementing them in the future, s/he can consult this post.
I can add whatever will not be implemented soon as (a) feature
request(s) in the tracker – possibly including the autochange patch,
since it s
(creating a new thread to separate the clef stuff from the staff
stuff)
David Kastrup wrote:
> I'll agree that any optionally usable clefs should be specified
> in advance. A "clef" in this respect may also consist of "8va"
> notations. There are instrument-dependent "thresholds of pain"
> invol
Wow. Thanks for all the replies. I'll answer one at a time, all
below.
David Kastrup wrote:
> I don't think so. The purpose of staff changes is to avoid help
> lines. In particular where they would require systems to be
> paced further apart. For this, the average is irrelevant, only
> the tota
>> Anyway, I think that it would make a lot more sense if the staff
>> were determined by the "average" pitch of the chord.
>
> I don't think so. The purpose of staff changes is to avoid help
> lines.
Perhaps it makes sense to provide different `modes', depending on the
purpose.
Werner
At 10:50 on 22 Jul 2009, David Kastrup wrote:
> Mark Polesky writes:
>
> > Anyway, I think that it would make a lot more sense if the staff
> > were determined by the "average" pitch of the chord.
>
> I don't think so. The purpose of staff changes is to avoid help
> lines. In particular where t
Mark Polesky writes:
> Anyway, I think that it would make a lot more sense if the staff were
> determined by the "average" pitch of the chord.
I don't think so. The purpose of staff changes is to avoid help lines.
In particular where they would require systems to be paced further
apart. For th
> I've also attached 2 png's to demonstrate the difference: the first
> one (current.png) was compiled with the current autochange.scm and
> the second one (revised.png) was compiled with my revised patch.
> You can look at the test file below to see how it is set up.
The results looks fine for m
In NR 2.2.1 Changing staff automatically, it says this:
Chords will not be split across the staves; they will be assigned
to a staff based on the first note named in the chord construct.
http://kainhofer.com/~lilypond/Documentation/user/lilypond/Common-notation-for-keyboards.html#Changing-staff-a
13 matches
Mail list logo
