Mark Polesky wrote:
Why is Dutch the default language for note-entry?
Because the originators of LilyPond are Dutch.
-David
English uses the fewest keystrokes. For comparison,
here's a measure from Chopin's Fantasie-impromptu:
English:
r16 gs( a gs fss gs cs e ds cs ds cs bs cs e gs)
Du
Why is Dutch the default language for note-entry?
English uses the fewest keystrokes. For comparison,
here's a measure from Chopin's Fantasie-impromptu:
English:
r16 gs( a gs fss gs cs e ds cs ds cs bs cs e gs)
Dutch:
r16 gis( a gis fisis gis cis e dis cis dis cis bis cis e gis)
49 keystrok
On 12/15/08 1:26 PM, "Francisco Vila" wrote:
> 2008/12/15 Carl D. Sorensen :
>>
>>
>>
>> On 12/15/08 7:18 AM, "Han-Wen Nienhuys" wrote:
>>
>>
>>> Try not to form mental models. Use the source instead.
>>
>> Unfortunately, not very many of us understand the source completely, and so
>>
here's a ly file and png (attached) to help visualize.
- Mark
This will generate 2 warnings:
warning: unterminated slur
warning: cannot end slur
\version "2.11.65-1"
\relative {
\time 2/4
\repeat volta 2 { f4( e~ }
\alternative { { e f) } { e\repeatTie d) } }
\bar "|."
}
\relativ
feature req: slur versions of \repeatTie and \laissezVibrer
When a (non-initial) volta alternative starts with a note
tied from the end of the volta, we can use \repeatTie to
correctly display the half-tie, but it seems there's no way
On Mon, Dec 15, 2008 at 6:09 PM, Patrick McCarty wrote:
> Hi Trevor,
>
> On Mon, Dec 15, 2008 at 2:12 PM, Trevor Bača wrote:
> >
> > * OK, so based on this understanding, can somebody please correct my
> > understanding of the parsing (not the iteration, just the parsing) of the
> > following ex
On Mon, Dec 15, 2008 at 6:21 PM, Han-Wen Nienhuys wrote:
> On Mon, Dec 15, 2008 at 10:20 PM, Han-Wen Nienhuys
> wrote:
>
> >> I know that the next part in the process is iteration. But I want to
> stop
> >> and check my understanding here: am I understanding the output of the
> parser
> >> corre
On Mon, Dec 15, 2008 at 10:20 PM, Han-Wen Nienhuys wrote:
>> I know that the next part in the process is iteration. But I want to stop
>> and check my understanding here: am I understanding the output of the parser
>> correctly at this point?
>
> No. the \new Staff and \new Score are created at
On Mon, Dec 15, 2008 at 8:12 PM, Trevor Bača wrote:
> * OK, so based on this understanding, can somebody please correct my
> understanding of the parsing (not the iteration, just the parsing) of the
> following expression (which is the same as my original example #2):
>
> {
> \new Voice {
>
Hi Trevor,
On Mon, Dec 15, 2008 at 2:12 PM, Trevor Bača wrote:
>
> * OK, so based on this understanding, can somebody please correct my
> understanding of the parsing (not the iteration, just the parsing) of the
> following expression (which is the same as my original example #2):
>
> {
> \
On Mon, Dec 15, 2008 at 02:07:35PM -0800, Mark Polesky wrote:
> I'm intentionally making a big deal out of this because this
> is the text on page 2 of the manual, and disingenuous claims
> are off-putting to new users. We're trying to "sell" a
> product, but our pitch is unconvincing and maybe a l
On 12/15/08 3:12 PM, "Trevor Bača" wrote:
> On Mon, Dec 15, 2008 at 2:09 PM, Han-Wen Nienhuys wrote:
>> On Mon, Dec 15, 2008 at 5:25 PM, Carl D. Sorensen wrote:
On 12/15/08 7:18 AM, "Han-Wen Nienhuys" wrote:
>> Try not to form mental models. Use the s
On Mon, Dec 15, 2008 at 2:09 PM, Han-Wen Nienhuys wrote:
> On Mon, Dec 15, 2008 at 5:25 PM, Carl D. Sorensen
> wrote:
> >
> >
> >
> > On 12/15/08 7:18 AM, "Han-Wen Nienhuys" wrote:
> >
> >
> >> Try not to form mental models. Use the source instead.
> >
> > Unfortunately, not very many of us un
On Mon, Dec 15, 2008, Francisco Vila said:
> I have a question for the few developers that in some degree do
> understand the source code and are able to hack it, fix bugs,
> implement new features, etc.
>
> Is the code properly commented, so that (thinking on the future) new
> people can learn
On 12/15/08 2:26 PM, "Han-Wen Nienhuys" wrote:
> 2008/12/15 Carl D. Sorensen :
>>
>
>> I'd say it differently:
>>
>> EXPRESSIONS:
>> Establish the timing of music-events relative to one another
>
>> CONTEXTS:
>> Provide the evaluation environment (my words, not Han-Wen's) in which all
>
Hello,
Please review:
http://codereview.appspot.com/11052
Regards,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
2008/12/15 Carl D. Sorensen :
>
> I'd say it differently:
>
> EXPRESSIONS:
> Establish the timing of music-events relative to one another
> CONTEXTS:
> Provide the evaluation environment (my words, not Han-Wen's) in which all
> music events will be evaluated when it's time to put them in the
On 12/15/08 6:25 AM, "Trevor Bača" wrote:
> On Sun, Dec 14, 2008 at 9:10 PM, Han-Wen Nienhuys wrote:
>> On Mon, Dec 15, 2008 at 12:18 AM, Trevor Bača wrote:
>
> ... even though contexts do not literally nest! (Even though their iterators
> inherit from one another.)
>
> So, to resume, thi
Hi Carl,
> The make web choked on trying to run a lilypond snippet. I looked at the
> snippet, and the reason that lilypond choked was because the snippet was the
> *old* version of the snippet, not the new version of the snippet. So the
> last lines of the make web output aren't likely to be he
On Mon, Dec 15, 2008 at 09:26:15PM +0100, Francisco Vila wrote:
> Is the code properly commented, so that (thinking on the future) new
> people can learn from it without having to figure out all the time
> what does each function, file etc. do? Sure, I can look at it and say,
> but I want the opini
2008/12/14 Reinhold Kainhofer :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I just saw the git commit to update input/lsr/tick-bar-lines.ly
>
> I suppose it would be easier / better to use
> \set Score.defaultBarType = "'"
> globally instead of explicit \bar "'" for each barline...
Ah y
2008/12/15 Carl D. Sorensen :
>
>
>
> On 12/15/08 7:18 AM, "Han-Wen Nienhuys" wrote:
>
>
>> Try not to form mental models. Use the source instead.
>
> Unfortunately, not very many of us understand the source completely, and so
> we need mental models to work in LilyPond. Of course, our mental mo
On Mon, Dec 15, 2008 at 5:25 PM, Carl D. Sorensen wrote:
>
>
>
> On 12/15/08 7:18 AM, "Han-Wen Nienhuys" wrote:
>
>
>> Try not to form mental models. Use the source instead.
>
> Unfortunately, not very many of us understand the source completely, and so
> we need mental models to work in LilyPon
On 12/15/08 7:18 AM, "Han-Wen Nienhuys" wrote:
> Try not to form mental models. Use the source instead.
Unfortunately, not very many of us understand the source completely, and so
we need mental models to work in LilyPond. Of course, our mental models
will be incorrect in some detail, and
While browsing the introductory docs I noticed that in those showing 'us'
vs 'them' vs 'Henle' thin bars were same line thickness as staff lines in
'us' and 'them', but slightly thicker in 'Henle'. Perhaps some discussion
would strengthen our claims.
--
Dana Emery
___
On Mon, Dec 15, 2008 at 10:15 AM, Trevor Daniels wrote:
> This is the general syntax, but the rider above needs to be
> applied when entering overrides directly in \lyricmode.
This is already documented, but making it clearer is on my TODO-list
for when I get a life (ETA 2 weeks or so).
Cheers,
Years ago I made a 4800dpi film in a printshop. It was surprisingly
different than a 600dpi laser-print.
So to make a fair comparison one should print pages with the same
professional technology and see.
Bert
Carl D. Sorensen wrote:
On 12/14/08 11:45 PM, "Mark Polesky" wrote:
LM 1.1 Ba
On 12/14/08 11:45 PM, "Mark Polesky" wrote:
> LM 1.1 Background - "Engraving" states:
>
> "our staff lines... are also
> much thicker than lines in the
> computer edition."
>
> In both the HTML and PDF versions, LilyPond's staff lines are
> in fact the thinnest when compared. I've included a
On Mon, Dec 15, 2008 at 11:25 AM, Trevor Bača wrote:
> 6. Lily reads the terminal close } brace. Even here, I'm willing to bet,
> Lily sees no reason to kill off the explicit named "foo" context. I bet Lily
> reads the terminal close } brace and instead simply closes off the original
> music *exp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Montag, 15. Dezember 2008 schrieb Reinhold Kainhofer:
> However, I'm now running into the next problem: Lilypond's configure
> claims it is missing guile!
- From the log file:
configure:8270: checking for scm_boot_guile
configure:8326: i686-linux
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Montag, 15. Dezember 2008 schrieb Jan Nieuwenhuizen:
> Op zaterdag 13-12-2008 om 01:59 uur [tijdzone +0100], schreef Reinhold
>
> Kainhofer:
> > Unfortunately, gmp does not build there, since the configure check seems
> > to think it is on a 64-bit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Montag, 15. Dezember 2008 schrieb Jan Nieuwenhuizen:
> Op vrijdag 12-12-2008 om 06:18 uur [tijdzone -0800], schreef Graham
>
> Percival:
> > Problem building the netpbm package. gcc doesn't seem to
> > recognize the "-flax-vector-conversions" optio
So there is a distinction between parser keywords and music functions?
On Sun, Dec 14, 2008 at 12:43 PM, Neil Puttock wrote:
> Hi John,
>
> 2008/12/14 John Mangual :
> > how would i go about looking up the scheme source code for a specific
> > function like "transpose" or "tuple" or "key"
>
> It
Op vrijdag 12-12-2008 om 06:18 uur [tijdzone -0800], schreef Graham
Percival:
> Problem building the netpbm package. gcc doesn't seem to
> recognize the "-flax-vector-conversions" option,
What happens if you remove that option? It would be nice if this
option is only needed for gccs that are so
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Montag, 15. Dezember 2008 06:20:21 schrieb Carl D. Sorensen:
> I've noticed that there's a problem with the doc build on kainhofer.com.
Yes, the build has been failing for some days already. I'm doing a clean build
now...
Cheers,
Reinhold
- --
-
Mark Polesky wrote Monday, December 15, 2008 8:02 AM
NR 2.1.2 "Entering lyrics: Lyrics explained"
states...
Similarly, a period which follows an alphabetic sequence is
included in the resulting string. As a consequence, spaces
must be inserted around property commands: do not write
\ov
Well, it's only specific to Lyrics. Earlier in the section, it states:
A word or syllable of lyrics begins with an alphabetic character,
and ends with any space or digit… Any character that is not a digit
or white space will be regarded as part of the syllable; one
important consequence o
NR 2.1.2 "Entering lyrics: Lyrics explained"
states...
Similarly, a period which follows an alphabetic sequence is
included in the resulting string. As a consequence, spaces
must be inserted around property commands: do not write
\override Score.LyricText #'font-shape = #'italic
but instead
38 matches
Mail list logo
