Re: lilypond.pdf size?

[Valentin Villenave]

2009/3/3 John Mandereau :
> I'm not sure the hoster of this new web platform would have reasonably
> enough bandwith for
> massive downloading of 13 MB lilypond.pdf; however, I guess it is OK to use
> download.linuxaudio.org.

Hm, I'm not sure what amount of bandwidth we are talking about. They
do host distros ISO images and packages repositories on their
download-dedicated servers, so I guess 13MB may not be so huge in
comparison... But if linuxaudio is available, that could be a better
solution indeed.

Regards,
Valentin


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: lilypond.pdf size?

[Graham Percival]

On Tue, Mar 03, 2009 at 02:45:11AM -0300, Han-Wen Nienhuys wrote:
> Specifically, I am thinking of:
> 
> - splitting the document, or

lilypond.org is only the NR, which is already split up.  I'm
surprised it's so big, though.  Anybody want to investigate why?
(does it include the IR or something weird like that?)

> - putting the PDF on download.lilypond.org/ and linking to that.

The TODO list for the website redesign already includes removing
the pdf links from the main doc page and making it a tarball
instead.

... actually, that's a thought -- what's the 13-meg pdf like once
it's compressed?  I would expect it to compress fairly well.

Cheers,
- Graham


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: lilypond.pdf size?

[Francisco Vila]

2009/3/3 Graham Percival :
> The TODO list for the website redesign already includes removing
> the pdf links from the main doc page and making it a tarball
> instead.

How would this decrease the bandwidth requirements? It'll rather
increase it, because for a given person there are many unwanted pdf
files in the tarball (And wanted by others)

>
> ... actually, that's a thought -- what's the 13-meg pdf like once
> it's compressed?  I would expect it to compress fairly well.

Current is 15Mb uncompressed, 9,5Mb ZIP compressed, 8,9Mb bz2 compressed.

It includes Appendix B12 All Context Properties and B13 Layout Properties.

-- 
Francisco Vila. Badajoz (Spain)

The incredible carnival of Badajoz
http://www.flickr.com/photos/pacovila/tags/carnaval/show/


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Enabling item-interface

[Carl D. Sorensen]

On 3/2/09 10:20 PM, "Patrick McCarty"  wrote:

> Hi Carl,
> 
> I'm not really sure what to suggest, but I can point out a couple of
> things.
> 
> On Mon, Mar 02, 2009 at 09:05:29PM -0700, Carl D. Sorensen wrote:
>> 
>> I've added the item-interface to the fretboard grob:
>> 
>>(FretBoard
>>  . ((stencil . ,fret-board::calc-stencil)
>> (fret-diagram-details . ((finger-code . below-string)))
>> (meta . ((class . Item)
>>  (interfaces . (fret-diagram-interface
>> rhythmic-grob-interface
>> item-interface
>> font-interface))
> 
> You don't need to add item-interface because it is added automatically
> to any grob with (class . Item).  FretBoard is an Item, so this is
> taken care of.

Thanks, Patrick!  I hadn't caught that.  I didn't start with item-interface
as one of the interfaces, but  I put it in explicitly when things aren't
working.

> 
>> Can anybody suggest what else I need to do to enable
>> "begin-of-line-visible" with FretBoards?
> 
> I don't think this is possible because FretBoard grobs are only placed
> in the *middle* of a line, not at the beginning or end.
> 
> So, `begin-of-line-visible' will always make FretBoards invisible.

ChordNames and FretBoards both appear at the same places on the line, and
this begin-of-line-visible property is what is used to make repeated
ChordNames invisible except at the beginning of a line.

As Joe Neeman pointed out in a later email, the property is
begin-of-line-invisible, not break-visibility, which is something I
overlooked before (since break-visibility has a possible value
begin-of-line-invisible).  So I'll figure out how the
begin-of-line-invisible property works.

Thanks,


Carl



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Enabling item-interface

[Carl D. Sorensen]

On 3/2/09 11:37 PM, "Joe Neeman"  wrote:

> On Mon, 2009-03-02 at 21:05 -0700, Carl D. Sorensen wrote:
>> I'm working to enable the chordChanges property for a FretBoards object.
>> 
>> I've changed the fretboard-engraver to keep track of the last fretboard,
>> using the chord-name-engraver as a model.  I've verified that the code works
>> to keep track of the changes in the fretboards.
>> 
>> Here's the relevant code from fretboard-engraver.
>> 
>>   SCM changes = get_property("chordChanges");
>>   if (to_boolean (changes) && scm_is_pair(last_fret_notes_)
>>   && ly_is_equal (last_fret_notes_, fret_notes))
>> fret_board_->set_property ("begin-of-line-visible", SCM_BOOL_T);
> 
> Why does ChordName use 'begin-of-line-visible = #t instead of
> 'break-visibility = begin-of-line-visible like all the other items?
> That's why this change doesn't work AFAICT: chord-name.cc has extra
> logic to deal with the 'begin-of-line-visible property that doesn't
> apply to FretBoard.

Thanks, Joe.  I had mixed up begin-of-line-visible as a property with
begin-of-line-visible as a value of the break-visibility property.

I suspect that ChordName uses begin-of-line-visible rather than
break-visibility because, as Patrick suggests in his email, ChordName never
appears at the beginning of a line (i.e.it's after the clef, and the key
signature, etc.)

Thanks for the tip.  I'll chase down the begin-of-line-visible property.

Carl



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: lilypond.pdf size?

[Han-Wen Nienhuys]

On Tue, Mar 3, 2009 at 6:23 AM, Valentin Villenave
 wrote:
> 2009/3/3 John Mandereau :
>> I'm not sure the hoster of this new web platform would have reasonably
>> enough bandwith for
>> massive downloading of 13 MB lilypond.pdf; however, I guess it is OK to use
>> download.linuxaudio.org.
>
> Hm, I'm not sure what amount of bandwidth we are talking about. They

http://lilypond.org/stats/stats/  (user/pw stats/stats)

Total B/W for lp.org is 250 Gb/month currently. we're on a shared host
with a 1 Tb limit.  The PDFs are 20 Gb of that.

Also, for some reason lots of people download the darwin/x86 version
from lilypond.org.  Is there some sort of file tracker
(versiontracker?) that is using lilypond.org as canonical site?

-- 
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

[PATCH] Add chordChanges property to FretBoard grobs

[Carl D. Sorensen]

Please review the patch I have just placed on Rietveld:



The patch adds chordChanges capability to FretBoard grobs to match the
functionality of ChordName grobs.

Thanks,

Carl



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

2.13.0 source archive

[Chris Snyder]

When I browse the download site, the source for 2.13.0 is at
http://download.linuxaudio.org/lilypond/sources/v2.13 rather than
http://download.linuxaudio.org/lilypond/sources/v2.13/lilypond-2.13.0.tar.gz.
Perhaps someone did a "cp lilypond-2.13.0.tar.gz [...]/sources/v2.13
before creating the v2.13 directory?

-Chris


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Add chordChanges capability to FretBoard grobs

[joeneeman]

lgtm

http://codereview.appspot.com/24044


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Proposal for resolving Half/Quarter note ambiguity on pure tablature staves (with partial code mod)

[demery]

Historical lute tablature notation had a number of issues to deal with
when it came to indication of rhythm.  Remember that this was the late
renaissance, at a time when the notation was being simplified (see Thomas
Morley, _A Plain and Easy Introductiuon to Practical Music_.

A Composer then had a choice of what note to assign his tactus to.  If the
musical form was in any way trinary (eg, a galliard, or a bransle simple)
it was considered apropriate to use the longer durations which could be
'perfect' (maxima, longa, breve, semi-breve) one unto another.  But if
binaria sufficed, the lesser notes could be taken advantage of,
semi-breve..semifusa; and these had the advantage (to us) of all being
stemed.

Thus, the solution lies in 'reduction'; ie, advise users against the use
of half notes and longer in new composition; transliterations should
employ reduction (eg, half->quarter; quarter->eighth ...).

The odd breve is found in some renaissance lute tablature, it has a stem 
toped by a left-going flag or has a circle (at half-mast).

\\|   /
|.   \o   |
|||   |
___
___
..


-- 
Dana Emery




___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add chordChanges capability to FretBoard grobs

[n . puttock]

http://codereview.appspot.com/24044/diff/1/2
File input/new/fretboard-chordchanges.ly (right):

http://codereview.appspot.com/24044/diff/1/2#newcode8
Line 8: \version "2.13.0"
"2.13.1"

http://codereview.appspot.com/24044/diff/1/3
File input/regression/fretboard-chordchanges.ly (right):

http://codereview.appspot.com/24044/diff/1/3#newcode8
Line 8: \version "2.13.0"
"2.13.1"

http://codereview.appspot.com/24044/diff/1/5
File lily/fretboard-engraver.cc (right):

http://codereview.appspot.com/24044/diff/1/5#newcode39
Line 39: SCM last_fret_notes_;
scm_gc_mark () to prevent garbage collection?

http://codereview.appspot.com/24044/diff/1/6
File ly/engraver-init.ly (right):

http://codereview.appspot.com/24044/diff/1/6#newcode24
Line 24: \consists "Separating_line_group_engraver"
Instrument_name_engraver?

http://codereview.appspot.com/24044


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: lilypond.pdf size?

[Ivo Bouwmans]

Hallo all,

Han-Wen Nienhuys schreef / wrote / skribis:


Also, for some reason lots of people download the darwin/x86 version
from lilypond.org.  Is there some sort of file tracker
(versiontracker?) that is using lilypond.org as canonical site?


That might be because  linked to 
lilypond.org until a couple of minutes ago.

I never realised I shouldn't link to that site (nor did I know how many people 
go there for the download).

I have changed the links to 
, so I take it 
that the problem is solved.

If I need to link to some other site still, please let me know!
--
Vriendelijke groeten,  =  Best wishes,  =  Afablajn salutojn,

Ivo


www.ivo.bouwmans.name


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: lilypond.pdf size?

[Francisco Vila]

2009/3/3 Han-Wen Nienhuys :
> http://lilypond.org/stats/stats/  (user/pw stats/stats)
>
> Total B/W for lp.org is 250 Gb/month currently. we're on a shared host
> with a 1 Tb limit.  The PDFs are 20 Gb of that.
>
> Also, for some reason lots of people download the darwin/x86 version
> from lilypond.org.  Is there some sort of file tracker
> (versiontracker?) that is using lilypond.org as canonical site?

There is also a japanese top referer that hotlinks all images from the
big page manual.
-- 
Francisco Vila. Badajoz (Spain)

The incredible carnival of Badajoz
http://www.flickr.com/photos/pacovila/tags/carnaval/show/


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Proposal for resolving Half/Quarter note ambiguity on pure tablature staves (with partial code mod)

[Neil Puttock]

2009/3/2 Ricdude :
> Ian Hulin  hulin.org.uk> writes:
>
>> > What I'd like to have output is something like:
>> >
>> >         __        _
>> >         |     |   |  _|
>> > -+--|-|---|---|
>> > -+--|-|---|---|
>> > -+--|-|---|---|
>> > --2--+--2-2---2.--2
>> > -+-
>> > -+-
>>
>> Ric, this is a problem.  With your proposal the up stem for a half note
>> will look uncomfortably like an unbeamed eighth note.
>
> Ahh, I see how you're interpreting my poor ascii rendition.  The thickness of
> the half note flag should be the same thickness as the stem itself, not a 
> beam.
> The half note flag is more like a bent stem, instead of a separate flag.
>
> Does that shed any light on how to address this?

I'm not sure it's the right approach to include conditional code in
the backend which is dependent on the context; it would be simpler to
set the flag type using a callback for the Stem object.

If you have a look at the News page for version 2.12, you'll see two
examples of custom flags, which could easily be adapted to override
the default behaviour just for minims.

Regards,
Neil


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Proposal for resolving Half/Quarter note ambiguity on pure tablature staves (with partial code mod)

[Ricdude]

Neil Puttock  gmail.com> writes:

> I'm not sure it's the right approach to include conditional code in
> the backend which is dependent on the context; it would be simpler to
> set the flag type using a callback for the Stem object.
> 
> If you have a look at the News page for version 2.12, you'll see two
> examples of custom flags, which could easily be adapted to override
> the default behaviour just for minims.

Perhaps we have different definitions of "easily" ;)

I like this approach, primarily as it keeps all the mods in my .ly files, 
instead of tweaking sources...

Being a scheme newbie, I tried a quick hack job on the "weight-
flag/inverted-flag" example.  It works on TabStaffs, but I have a few 
questions about the implementation:

1) Is the \autoBeamOff required?  Is there a way to allow autobeaming and 
still override the flag style?

2) How does one locate the end of the stem for connecting a line to it?  For
that matter, how does indicate a line should be drawn in scheme?

3) Is there any (better) documentation of overriding default stems/flags?





___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel