Graham Percival wrote:
On 7-Jan-05, at 9:15 AM, Paul Scott wrote:
Juergen Reuter wrote:
Another requested feature at that time was the cue notes problem:
You want to print cue notes only when extracting parts, but not when
printing the whole score. Hence, just tag all cue notes and filter
them
This isn't to demonstrate \tag. If I wanted to do that, I'd add it to
the Notation
chapter. Example templates isn't the place to demonstrate such things.
No, the reason is that I have a pathological dislike of having anything
in the individual instrument files that doesn't need to be there.
Sur
On 7-Jan-05, at 3:36 AM, Erik Sandberg wrote:
Also, if there would be a command-line option to select/unselect
certain tags,
there would be a clear advantage to use tags for extracting parts.
E.g.,
lilypond -usetag viola quartet.ly
could extract the viola part. This approach would result in the n
On 7-Jan-05, at 9:15 AM, Paul Scott wrote:
Juergen Reuter wrote:
Another requested feature at that time was the cue notes problem: You
want to print cue notes only when extracting parts, but not when
printing the whole score. Hence, just tag all cue notes and filter
them out when printing the w
On 6-Jan-05, at 4:15 PM, Anthony W. Youngman wrote:
Page 101, section 5.11.1, in the only real paragraph in the section -
"You should use \addlyrics unless you need to fancy things," - we seem
to have a missing verb or something.
Don't you mean "we seem have a missing verb or something"? :)
Page
[EMAIL PROTECTED] writes:
>
> OK. I just had a change of plans: I'm going to retain the classic
> font selection scheme, but for the non-tex backends, the selection
> scheme does not produce a PFA font name, but rather a
> PangoFontDescription as a string. For lilypond-book, I'm going to
> implem
On Sat, 8 Jan 2005 15:46:22 +0100, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
> [please keep discussion on the ML]
Sorry 'bout that...
> Add an Y-offset-callback that returns the correct amount. It might
> need additional glue, because Staff_symbol_referencer::staff_space()
> isn't callable from
On Sat, 8 Jan 2005 15:23:30 +0100, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
> The beam hack is acceptable (we do similar things for grace notes.)
> The extra-offset isn't;
Hmm, ok... When extra-offset is set to zero, fret numbers are placed
above the strings. Some tabs use this style, but the ma
[please keep discussion on the ML]
[EMAIL PROTECTED] writes:
> On Sat, 8 Jan 2005 15:23:30 +0100, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
> > The beam hack is acceptable (we do similar things for grace notes.)
> > The extra-offset isn't;
> Hmm, ok... When extra-offset is set to zero, fret num
[EMAIL PROTECTED] writes:
> Hi again,
>
> I've synced against latest cvs and made one patch that includes a
> ChangeLog entry. Hope this looks ok. Two of the changes are kind of
> hacks: the beaming and extra-offset stuff should be computed instead
> of being hard-coded.
The beam hack is acceptab
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> I believe bison has builtin support for handling locations (check out
> the bison manual under Locations). Maybe you could run some experiments
> whether it's usable for us.
Right, thanks.
___
lilypond-d
Hello and thanks for your reply,
On Sat, 8 Jan 2005 13:10:41 +0100, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
> I'm sorry that I haven't looked at your patches yet;
Oh, thats ok, not to worry...
> Could you send them as one big -u diff (including ChangeLog entry)
Shure, I'll send one later toda
[EMAIL PROTECTED] writes:
> Hello,
>
> I noticed that beams in TabStaff context are much bigger than beams in
> normal staffs. A little grep'ing shows that ly/engraver-init.ly sets
> StaffSymbol.staff-space to 1.5, which in turn seems to increase the
> beaming size. I've made a workaround to this
[EMAIL PROTECTED] writes:
> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> >
> > Right now, parser.yy sets the input location of music expressions
> > directly (using set_spot()). This method is flawed, since the parser
> > occasionally has to look ahead for parsing correctly, thus putting the
> >
In message <[EMAIL PROTECTED]>, Han-Wen Nienhuys
<[EMAIL PROTECTED]> writes
As for the more difficult things ; they are -as said- more
difficult. IMO, the proper attitude is to be glad that more difficult
hacks are possible, and accept that automatic language conversion can
not always deal with th
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
> Right now, parser.yy sets the input location of music expressions
> directly (using set_spot()). This method is flawed, since the parser
> occasionally has to look ahead for parsing correctly, thus putting the
> origin property in the wrong spot. If
16 matches
Mail list logo
