I haven't actually tried the new syntax and I've been only half following
this thread. Having said that I would go on to say that the idea of
differentiating between a chord and simultaneous music sounds like a good
idea to me.
-David Bobroff
___
L
[EMAIL PROTECTED] writes:
> then back to read the notes of the chord. Would it be possible to
> support both versions?
Sure it is. Just type (pre 1.9.4) or <> (1.9.4)
> > My feeling is that << >> stands out better in the text, and that in
> > the < > version the chord-pitches do not appear
On Sun, 31 Aug 2003 20:06:39 +0200
Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
> * Chords are more often used than simultaneous music. Hence, using < >
> for chords saves keystrokes. However, the benefit is not large,
> since << and >> are rather easy to type.
Eh... it's not a big deal, but <
> What about the readability of << >> vs. < > ?
IMO, for readability is good but for <> it is bad.
If I look syntax
I'll see the notes, and looking at
<> I'll see the angle brackets with my eyes going from
left to right trying to focus.
It is possible to drop << >> complete
On Sun, 31 Aug 2003, Tyler Eaves wrote:
> > Similarly, one could imagine a syntax, with increasing size of
> > structural element:
> >
> > \score { \simultaneous { 2 2 } }
> >
> > would be
> >
> > <<< << 2 2 >> >>>
> >
>
> I see this as a very BAD idea. To me code (and I consider lilypond inpu
[EMAIL PROTECTED] writes:
>
> I see this as a very BAD idea. To me code (and I consider lilypond input
> code) should be as self explanitory as possible. Besides, that kind of
> nesting makes it WAY to easy to type the wrong number of characters (IE
> >> instead of >>>) If that kind of nesting is
[EMAIL PROTECTED] writes:
>
> For structural point of view, this change is toward right direction.
>
> > * Chords are more often used than simultaneous music. Hence, using < >
> > for chords saves keystrokes. However, the benefit is not large,
> > since << and >> are rather easy to type.
>
>
I see this as a very BAD idea. To me code (and I consider lilypond input
code) should be as self explanitory as possible. Besides, that kind of
nesting makes it WAY to easy to type the wrong number of characters (IE
>> instead of >>>) If that kind of nesting is really desired, maybe an
optional 'l
On Sun, 31 Aug 2003, Han-Wen Nienhuys wrote:
>
> NOTE-NOTE-NOTE-NOTE-NOTE-NOTE
> *
> 1.9.4 is an experimental release: the documentation does NOT compile!
>
> Hi there,
>
> I have just put up 1.9.4. For this release I have changed the chord
> syntax: effectively, << >>
[cc-ing list]
[EMAIL PROTECTED] writes:
> [Han-Wen Nienhuys]
>
> > Hence, using < > for chords saves keystrokes. However, the benefit is not
> > large, since << and >> are rather easy to type. How does readability
> > change?
>
> Hello, Han-Wen.
>
> Even if << and >> are easy to type, they ar
* Han-Wen Nienhuys ([EMAIL PROTECTED]) wrote:
I prefer << for chords and < for simultaneous.
> However, the benefit is not large, since << and >> are rather easy
> to type.
I agree, and one can use an editor to have the tags automatically
inserted. I _really_ like the "saving keystrokes" approac
NOTE-NOTE-NOTE-NOTE-NOTE-NOTE
*
1.9.4 is an experimental release: the documentation does NOT compile!
Hi there,
I have just put up 1.9.4. For this release I have changed the chord
syntax: effectively, << >> and < > have been swapped. I would like to
hear your comm
12 matches
Mail list logo
