headers
Carl Sorensen | 1 Dec 2009 01:29

Re: Issue 787 in lilypond: script stack order fails with 2 more notes


On 11/30/09 2:09 PM, "lilypond <at> googlecode.com" <lilypond <at> googlecode.com>
wrote:

> Updates:
>         Status: Started
>         Labels: -fixed_2_13_9
> 
> Comment #6 on issue 787 by n.puttock: script stack order fails with 2 more
> notes
> http://code.google.com/p/lilypond/issues/detail?id=787
> 
> This is still not quite right, as Reinhold has found out with the regtest
> accidental-suggestion.ly.
> 
> If there's only one stacking direction, the new code causes a segfault,
> since it
> calls scm_car (null) in the other direction.
> 
> This fails,
> 
> \relative c' {
>    c4-"1"-"2"
> }
> 
> whereas this works:
> 
> \relative c' {
> c4-"1"^"2"
> }
(Continue reading)

Permalink | Reply | 7 comments |
headers
Ted Walther | 1 Dec 2009 01:07

Re: lyrics for right-left writing systems such as hebrew or arabic

I'm having the same problem.  I am mixing up Latin and Hebrew lettering
in the lyrics, and I want them ALL to render strictly Left-to-Right.  Is
there any way to do this in Lilypond?  You can see the problem it causes
in this example:

   http://hymns.reactor-core.org/HaikVantoura/Shema4.pdf

This causes problems because I am trying to put the Hebrew lettering
underneath a strict letter-for-letter English transliteration of the
text.  The English transliteration is Left-to-Right, but the Hebrew gets
munged as Right-to-Left on a syllable by syllable basis!

Ted

On Mon, Apr 20, 2009 at 03:34:41PM -0000, demery <at> suffolk.lib.ny.us wrote:
>On Sun, Apr 19, 2009, Richard Schoeller <schoeller <at> comcast.net> said:
>
>> One common approach when combining a right-to-left language with
>> left-to-right musical notation is to render each syllable of the lyrics
>> right-to-left but have the overall flow of the music left-to-right.  I
>> haven't tried this with any of the stuff that I've done (I present the
>> lyrics in transliteration).  So, I can't tell you how well this works in
>> LilyPond.
>
>However it is done, and by whatecer program, there are some pretty hefty
>issues for position-contextual writing systems such as arabic.  Arabic
>letters have variant shapes when used in different positions (opening,
>middle, closing); fragmenting a wordd into sylables exposes middle
>letters; not at all sure the common reader is used to seeing that.
>Further, when placed correctly under the music they will be presented in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Knoop | 1 Dec 2009 10:18

Re: LSR update adds whitespace

At 18:07 on 28 Nov 2009, Graham Percival wrote:
> On Sat, Nov 28, 2009 at 04:58:01PM +0000, Neil Puttock wrote:
> > 2009/11/27 Graham Percival <graham <at> percival-music.ca>:
> > 
> > > or whether Neil automatically stripped out the extra whitespace
> > > when committing LSR updates
> > 
> > I strip all the trailing whitespace with sed after downloading the
> > LSR tarball.
> 
> Ok.  Could we get this added to makelsr.py ?  I'd be surprised if
> it takes more than 1 line of python to strip all trailing
> whitespace.

line = line.rstrip()

--

-- 
Mark Knoop
Permalink | Reply | 0 comments |
headers
Bertalan Fodor (LilyPondTool | 1 Dec 2009 16:54
Picon

Detailed instructions for jail mode

Hi,

for the LilyPond Google Wave plugin, to ease hosting LilyPond services, 
I created detailed instructions about how to set up a good chroot jail.
Could it be (worth) linked in the doc somehow?

http://code.google.com/p/lilypondy/wiki/LilyPondInJail

Thanks,

Bert
Permalink | Reply | 3 comments |
headers
Carl Sorensen | 1 Dec 2009 21:20

Italic font on OSX 10.5

I have apparently lost my italic fonts in LilyPond on OSX 10.5.

Musical instructions such as Allegro are now in an upright font.

I believe this means that my FontConfig or something like that is messed up.

I remember this issue being raised on the list some time ago, but I couldn't
find it in the archives.

Any recommendations for what I can do to fix things?

Thanks,

Carl
Permalink | Reply | 0 comments |
headers
Patrick McCarty | 2 Dec 2009 04:19
Picon
Gravatar

Re: Priority-Regression policy

On 2009-11-30, Graham Percival wrote:
> On Sun, Nov 29, 2009 at 07:34:37PM -0800, Patrick McCarty wrote:
> > On 2009-11-29, Graham Percival wrote:
> > > What's the feeling amongst developers about what should be ranked
> > > as priority-Regression (and thus stop a release) ?  In particular,
> > > should *everything* that used to work -- even if it was by
> > > accident? -- be ranked a Regression?
> > 
> > Maybe we could add labels indicating which release an issue blocks?
> 
> The previous policy, which I assume stands, is that anything
> ranked Priority-Regression is a "release blocker".  IIRC, at one
> point this even blocked unstable releases.

Ah, okay.  Just as long as we decide not to block unstable releases,
I'm fine with it.  That's asking a little too much.  :-)

> > > I don't particularly mind which way we decide, but I'd like it to
> > > be consistent, and I'm going to insist that if something is
> > > Priority-Regression, it blocks a release.
> > 
> > IMO, regressions from 2.13 should get first priority and should block
> > 2.14, but other regressions should be considered on a case-by-case
> > basis.
> 
> I'm not opposed to this, although if we want to go this route, I
> propose *removing* the Priority-Regression label.  We could then
> use High, Medium, Low, Postponed.  Regressions would then be
> High-priority by default, but developers could lower it if the
> regression was due to an architecture change, or if it only worked
(Continue reading)

Permalink | Reply | 0 comments |
headers
Graham Percival | 2 Dec 2009 04:44
Picon
Favicon

Re: Detailed instructions for jail mode

On Tue, Dec 01, 2009 at 04:54:59PM +0100, Bertalan Fodor (LilyPondTool) wrote:
> for the LilyPond Google Wave plugin, to ease hosting LilyPond services,  
> I created detailed instructions about how to set up a good chroot jail.
> Could it be (worth) linked in the doc somehow?

Dunno what the wave thing is all about, but I'm totally fine with
better jail instructions.  It would go in Usage 1.7 Jail, or
Security issues, or Running as a web service, or something like
that.

As long as the patch compiles, and doesn't touch other areas
(other than possibly adding a link from 1.2 to it), I'm not going
to be too picky about it.

Cheers,
- Graham
Permalink | Reply | 2 comments |
headers
Graham Percival | 2 Dec 2009 05:04
Picon
Favicon

Re: [frogs] Frog's Lament

On Mon, Nov 30, 2009 at 11:25:46AM -0500, Chris Snyder wrote:
> Graham Percival wrote:
>> On Thu, Nov 26, 2009 at 11:12:26PM +0100, David Kastrup wrote:
>>> We are not talking about explaining concepts to potential contributors
>>> in private.  We are talking about explanations happening on the
>>> developer list.  Those can be skimmed off into documentation, without
>>> requiring all too much advance knowledge, because they were written for
>>> the sake of people without all too much knowledge.
>>
>> I agree COMPLETELY.  Are you volunteering?
>>
>>> Perhaps it would be worth of another task master just to tick any such
>>> article with the potential "more useful than existing docs" into a list,
>>
>> I agree COMPLETELY.  Are you volunteering?
>
> It seems to me that such a list would best be maintained in a  
> bug-tracker of some sort (though IMHO not the official issue tracker due  
> to the noise it would generate).

Despite my agreements to both paragraphs above, I agree more with
the first than the second.  Namely, I don't see the point of
keeping a list of stuff to add to the docs; that's a recipe for
not getting anything done.

Add stuff directly to the CG.  If you really can't figure out what
somebody talking about, just add something like

-----
Han-Wen wrote something about contexts and accessing property
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bertalan Fodor | 2 Dec 2009 08:35
Picon

Re: Detailed instructions for jail mode

> On Tue, Dec 01, 2009 at 04:54:59PM +0100, Bertalan Fodor (LilyPondTool)
> wrote:
>> for the LilyPond Google Wave plugin, to ease hosting LilyPond services,
>> I created detailed instructions about how to set up a good chroot jail.
>> Could it be (worth) linked in the doc somehow?
>
> Dunno what the wave thing is all about, but I'm totally fine with
> better jail instructions.  It would go in Usage 1.7 Jail, or
> Security issues, or Running as a web service, or something like
> that.
>
> As long as the patch compiles, and doesn't touch other areas
> (other than possibly adding a link from 1.2 to it), I'm not going
> to be too picky about it.
>
> Cheers,
> - Graham
>
>

Would you prefer providing compact instructions in the lilypond doc and an
external link to the details, or detailed instructions in the lilypond doc
and external link to the reference web service implementation.
Permalink | Reply | 1 comment |
headers
Trevor Daniels | 2 Dec 2009 10:26
Picon

Lettered tablature patch

I posted my first patch to Rietveld last night, but nothing seems to 
have been cc'd to the list.  Not sure what I did wrong.  It's at 
http://codereview.appspot.com/164063.  Here's what it does.

This is the first patch of a series aiming eventually to enable 
Baroque lute tablature to be produced.

This first patch enables an option to indicate fret numbers with 
letters.  The option is turned on by setting the context variable 
tablatureFormat to fret-letter-tablature-format.  The letters are 
taken sequentially from the alphabet by default, but the first n of 
these may be overridden by setting the context variable fretLetters 
to a string of n length.  For example, the third fret on a Baroque 
lute is indicated by "r" rather than "c", as "c" can easily be 
confused with "e".  (Actually it was originally a Greek gamma, but 
"r" is usually used).  So, for a Baroque lute, fretLetters would be 
set to #'("a" "b" "r").

Following a suggestion by Neil I have also made the whiteout behind 
all fret numbers optional.  This is controlled by the 'whiteout 
property of TabNoteHead.  The default is #t to preserve the current 
behaviour.

As this is my first attempt at modifying LilyPond code I'm sure 
there are many things that could be improved.  Comments welcome.

Trevor

ps I've not included an addition to changes nor any documentation. 
I'll do that after this approach (the three new properties) has been
(Continue reading)

Permalink | Reply | 13 comments |

Gmane