Nabble - Gnu - Lilypond - Dev

Re: Describing instruments

2009-11-29T22:01:26Z

> Message: 6
> Date: Mon, 30 Nov 2009 00:42:04 +0100
> From: Valentin Villenave <v.villenave@...>
> Subject: Re: Describing instruments
> To: Graham Percival <graham@...>
> Cc: David Kastrup <dak@...>, lilypond-devel@...
> Message-ID:
> <eefe316d0911291542m51c0245bx342c1665ef3d0d0@...>
> Content-Type: text/plain; charset=UTF-8
>
> On Sun, Nov 29, 2009 at 10:03 PM, Graham Percival
> <graham@...>
> wrote:
> > I don't think that lilypond should serve as a crutch
> to composer
> > who know so little about their craft that they write
> unplayable
> > notes.
>
> Besides, things are not so black-and-white for some
> instruments (e.g.
> wind instruments or singers can produce high notes that
> are
> out-of-range but still okay, and what about pedal notes wrt
> horns and
> trombones?). That being said, it could be a nice
> enhancement for
> newcomers who are used to having such "features" in
> proprietary
> software.
> Even though I personally find such features infantilizing
> for the
> user, I consider this to be a valid feature request in case
> someone
> has time, skills and courage to implement it. Added as
> http://code.google.com/p/lilypond/issues/detail?id=914

Hi Valentine,
<snarky due to your use of the word "infantile">
If warning the user about suspiciously placed pitches in
the vertical dimension of the staff is infantile, is warning the user
about suspiciously placed rhythms in the horizontal dimension of the staff
an unacceptable engraving practice in Lilypond? Does it build character
to refrain from using barchecks?
<\snarky>
For orchestral scores, I think such a range-checking feature is more
important in Lilypond than it is in GUI programs. In GUI programs, I'm
looking at each note in the virtual score as it's entered, whereas in
Lilypond I'm entering long streams of notes without immediate visual
feedback. This is one of the reasons octave checks are important. And
if one happens to go astray between periodic octave checks-- especially
if it happens twice in a row so that the register gets back on track--
range-checking would definitely be a helpful (though not foolproff) bonus.
Also, I don't think newcomers would benefit as much as "power users."
When I first learned Lilypond I was compiling after each measure, so I
didn't even use octave checks. But if I'm entering an entire orchestral
part in one fell swoop, I'd like all the help I can get to track down
my note-entry mistakes (especially when dealing with transposition levels).

-Jonathan

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

Re: Priority-Regression policy

2009-11-29T19:48:24Z

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.

> > 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
by accident originally.

Cheers,
- Graham

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

Re: Priority-Regression policy

2009-11-29T19:34:37Z

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?
This is what Mozilla does for their products.

Like "2.14-blocker", "3.0-blocker", etc. as well as
"Priority-Regression".

> For example,
> - markup \note in time signature: worked in 2.10, currently
> Defect-Low.
> http://code.google.com/p/lilypond/issues/detail?id=628

If I'm reading this correctly, it worked in 2.8, not 2.10.

As you can tell from the comments on this issue, a *proper* solution
is going to be very involved, so I can't see this happening in the
near future. This might get fixed before 2.16 (or whatever is after
2.14).

> - Tie direction: worked in 2.10 (by accident?), currently
> Enhancement-Low.
> http://code.google.com/p/lilypond/issues/detail?id=592

Not sure about this one. Either it worked in 2.10 by accident, or it
is a regression in 2.11. I don't know enough about this code to make
a call.

> 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.

Thanks,
Patrick

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

Re: Describing instruments

2009-11-29T15:42:04Z

On Sun, Nov 29, 2009 at 10:03 PM, Graham Percival
<graham@...> wrote:
> I don't think that lilypond should serve as a crutch to composer
> who know so little about their craft that they write unplayable
> notes.

Besides, things are not so black-and-white for some instruments (e.g.
wind instruments or singers can produce high notes that are
out-of-range but still okay, and what about pedal notes wrt horns and
trombones?). That being said, it could be a nice enhancement for
newcomers who are used to having such "features" in proprietary
software.
Even though I personally find such features infantilizing for the
user, I consider this to be a valid feature request in case someone
has time, skills and courage to implement it. Added as
http://code.google.com/p/lilypond/issues/detail?id=914

Cheers,
Valentin

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

Priority-Regression policy

2009-11-29T15:39:23Z

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?

For example,
- markup \note in time signature: worked in 2.10, currently
Defect-Low.
http://code.google.com/p/lilypond/issues/detail?id=628

- Tie direction: worked in 2.10 (by accident?), currently
Enhancement-Low.
http://code.google.com/p/lilypond/issues/detail?id=592

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.

Opinions are only sought from actual developers (i.e. the people
who will be fixing such bugs). If you're an interested user or
new contributor, then although I would generally encourage you to
join the discussion, please don't get involved in this one.

Cheers,
- Graham

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

Re: [GLISS] Syntax of \parallelMusic

2009-11-29T13:34:08Z

Valentin Villenave wrote:

> On Sun, Nov 29, 2009 at 4:51 PM, Nicolas Sceaux
> <nicolas.sceaux@...> wrote:
>> Modify parallelMusic, so that when a VoiceSeparator (instead of BarCheck)
>> music element is found, the function switches to the next voice. The
>> parallelMusic function seems well documented, this part should not be
>> difficult.
>
> (To whomever starts working on parallelMusic: please, please, please
> implement #451 already!)
> http://code.google.com/p/lilypond/issues/detail?id=451

Hi, Valentin,

to be honest - I have no clue what this bug report is about. Even
assuming syntactically correct input. (By the way, after looking at
parallelMusic, I'm not surprised at all that the newly posted snippet
jun.ly works - however, if you wanted to use this, you'd have to write a
new \relative {} construct for each and every bar.)

NR 1.5.2, section "Writing music in parallel", explicitly explains
examples (exciting alliterations...) to handle relative input:
"Relative mode may be used. Note that the \relative command is not used
inside \parallelMusic itself.
The notes are relative to the preceding note in the voice, not to the
previous note in the input – in other words, relative notes for voiceA
ignore the notes in voiceB."
The latter is not a bug, it's a feature - when I want to use relative
mode, I want to not count octaves between notes, and it's much more
reasonable for a ongoing voice to stay in the same range than the
intervals between voices.

What's the problem about adding the "relativity" _after_ the
\parallelMusic command? You barely start a \parallelMusic instance for
three or seven notes, and if you have fifty lines of music, who cares
about another
relA = \relative c \A
relB = \relative c \B
after a \parallelMusic #'(A B) { }? It's there, it's documented, and it
does exactly what I understand to be desired from the mail linked in the
bug description.

I think it's no problem defining a \parallelRelativeMusic command which
does nothing but call \parallelMusic and wrap each argument inside a
\relative c { ... } afterwards.
But do we really want this to exist?

Okay. After all the rant, I just saw that the discussion dates back to
March 2006. Maybe this is just fixed by documentation work?

Cheers,
Alexander

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

Re: Describing instruments

2009-11-29T13:03:36Z

On Sun, Nov 29, 2009 at 09:06:32PM +0100, David Kastrup wrote:
> If you transpose music, Lilypond could warn if notes become unplayable
> on a baroque soprano recorder. Because the range is left, or because a
> particular semitone is not on the instrument. Similar for other
> instruments.
...
> It would also be helpful for arrangers and composers to have a databank
> of instruments available, so that they don't go to the orchestra with
> their finished scores and get told "Dude, that's not playable on a
> standard bassoon."

I don't think that lilypond should serve as a crutch to composer
who know so little about their craft that they write unplayable
notes. But if you want to persue this, feel free to write a music
function which checks the ranges (or anything else) and add it to
LSR.

Cheers,
- Graham

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

Describing instruments

2009-11-29T12:06:32Z

Hi,

currently the only connection between instrument and lilypond are
instrument names (pure typesetting) and a midi instrument (just
sonorization).

I think it would be useful if instruments could become more than that:
for example, if a given instrument (or one manual of such an instrument)
has a certain available range, it is not really sensible if the chord
typesetters leave that range. The predefined guitar chord symbols, for
example, can map chord names to the usual guitar ranges. But what if
you have a classically trained player playing from normal notes? The
chord symbols are not mapped back into notes.

If you transpose music, Lilypond could warn if notes become unplayable
on a baroque soprano recorder. Because the range is left, or because a
particular semitone is not on the instrument. Similar for other
instruments.

Or a player could declare only a subset of guitar chords he is able to
play and tell Lilypond to transpose this thing so that he can both play
and sing a song.

It would also be helpful for arrangers and composers to have a databank
of instruments available, so that they don't go to the orchestra with
their finished scores and get told "Dude, that's not playable on a
standard bassoon."

Maybe that would be workable in the context of performers? On the other
hand, where mapping a chord to the available range is required, this has
to happen quite a bit earlier.

--
David Kastrup

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

Re: [GLISS] Syntax of \parallelMusic

2009-11-29T10:28:32Z

On Sun, Nov 29, 2009 at 4:51 PM, Nicolas Sceaux
<nicolas.sceaux@...> wrote:
> Modify parallelMusic, so that when a VoiceSeparator (instead of BarCheck)
> music element is found, the function switches to the next voice. The
> parallelMusic function seems well documented, this part should not be
> difficult.

(To whomever starts working on parallelMusic: please, please, please
implement #451 already!)
http://code.google.com/p/lilypond/issues/detail?id=451

Cheers,
Valentin

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

Re: [GLISS] Syntax of \parallelMusic

2009-11-29T08:57:31Z

[With forward to -user, since this may be interesting now for everybody.]

Nicolas Sceaux wrote:

> Le 29 nov. 2009 à 16:15, Alexander Kobel a écrit :
>
>> I propose using a different separator for \parallelMusic than "|", and allow to include bar checks in there.
>>
>> \parallelMusic as is is very fine and handy, but sometimes you want to enter a whole phrase of two or three measures in a single go, and include the bar checks in there for readability and checking later on.
>> It somewhat disturbs the workflow if you always have to look up where the voiceN ended up in the last measure, especially if you have larger intervals in the voices, or reentering the durations if one voice stays in 16, the next in 8 and the third in 2.
>>
>> What about, e.g., ":"? It's fast to type, and AFAICS, it only is used for chord mode and figured bass. And I don't see a use for those two in \parallelMusic, since - well, you usually only have one chord at a time, right?
>> Another idea: "||", to serve both as bar check and as delimiter. And there's definitely no use conflict against two bar checks at the same point in time, right?
>
> Currently, \parallelMusic highjacks the usual meaning of the pipe symbol: [...]
> This was done so that \parallelMusic has no impact on the parser.

Thanks, Nicolas,

this was exactly the hint I needed... It never occured to me that
parallelMusic might be a simple music function; I figured it's low-level
and pretty involved in parser.
"I can see clearly now, the rain is gone..."

Which allows for a quite simple modification, to make the delimiter be
"||", combining a bar check and a voice cycle: Just count how often the
existing voice change has been called, and only do some work if it's two
times in a row.
The modification is attached, and seems to work flawlessly.

Of course, this still leaves the question whether the delimiter should
be changed, and whether it's good to overload the bar check.
But it seems to me that the convert-ly rule should be so simple that
even I might figure out how to write it, and I'm perfectly satiesfied
with not having to remember the position of yet another symbol on the US
keyboard layout... ;-)

Cheers,
Alexander

parallelMusic =
#(define-music-function (parser location voice-ids music) (list? ly:music?)
(_i "Define parallel music sequences, separated by '||' (double bar check signs),
and assign them to the identifiers provided in @var{voice-ids}.

@var{voice-ids}: a list of music identifiers (symbols containing only letters)

@var{music}: a music sequence, containing double BarChecks as limiting expressions.

Example:

@verbatim
\\parallelMusic #'(A B C) {
c c | d d | e e ||
d d | e e | f f ||
e e | f f | g g ||
}
<==>
A = { c c | d d | e e | }
B = { d d | e e | f f | }
C = { e e | f f | g g | }
@end verbatim
")
(let* ((voices (apply circular-list (make-list (length voice-ids) (list))))
(current-voices voices)
(current-sequence (list))
(change-voice-call-count 0))
;;
;; utilities
(define (push-music m)
"Push the music expression into the current sequence"
(set! current-sequence (cons m current-sequence)))
(define (change-voice)
"Stores the previously built sequence into the current voice and
change to the following voice."
;; only do the actual work if change-voice is called the second time in a row
(if (odd? change-voice-call-count)
(begin
(list-set! current-voices 0 (cons (make-music 'SequentialMusic
'elements (reverse! current-sequence))
(car current-voices)))
(set! current-sequence (list))
(set! current-voices (cdr current-voices))))
;; increase the call counter
(set! change-voice-call-count (- 1 change-voice-call-count)))
(define (bar-check? m)
"Checks whether m is a bar check."
(eq? (ly:music-property m 'name) 'BarCheck))
(define (music-origin music)
"Recursively search an origin location stored in music."
(cond ((null? music) #f)
((not (null? (ly:music-property music 'origin)))
(ly:music-property music 'origin))
(else (or (music-origin (ly:music-property music 'element))
(let ((origins (remove not (map music-origin
(ly:music-property music 'elements)))))
(and (not (null? origins)) (car origins)))))))
;;
;; first, split the music and fill in voices
(map-in-order (lambda (m)
(push-music m)
(if (bar-check? m)
(change-voice)
(set! change-voice-call-count 0))) ;; reset the call counter
(ly:music-property music 'elements))
(if (not (null? current-sequence)) (begin (set! change-voice-call-count 1) (change-voice)))
;; un-circularize `voices' and reorder the voices
(set! voices (map-in-order (lambda (dummy seqs)
(reverse! seqs))
voice-ids voices))
;;
;; set origin location of each sequence in each voice
;; for better type error tracking
(for-each (lambda (voice)
(for-each (lambda (seq)
(set! (ly:music-property seq 'origin)
(or (music-origin seq) location)))
voice))
voices)
;;
;; check sequence length
(apply for-each (lambda* (#:rest seqs)
(let ((moment-reference (ly:music-length (car seqs))))
(for-each (lambda (seq moment)
(if (not (equal? moment moment-reference))
(ly:music-message seq
"Sections in parallel music don't have the same length")))
seqs (map-in-order ly:music-length seqs))))
voices)
;;
;; bind voice identifiers to the voices
(map (lambda (voice-id voice)
(ly:parser-define! parser voice-id
(make-music 'SequentialMusic
'origin location
'elements voice)))
voice-ids voices))
;; Return an empty sequence. this function is actually a "void" function.
(make-music 'SequentialMusic 'void #t))

\version "2.12.2"

\include "parallelMusic.ily"

\parallelMusic #'(A B C) {
c4 c c c | c c c c | c c c c ||
a2 a | a a | a a ||
f1 | f | f ||
}

\score {
<<
\new Staff \relative c'' \A
\new Staff \relative c'' \B
\new Staff \relative c' \C
>>
}

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

Re: [GLISS] Syntax of \parallelMusic

2009-11-29T07:51:10Z

Le 29 nov. 2009 à 16:15, Alexander Kobel a écrit :

> I propose using a different separator for \parallelMusic than "|", and allow to include bar checks in there.
>
> \parallelMusic as is is very fine and handy, but sometimes you want to enter a whole phrase of two or three measures in a single go, and include the bar checks in there for readability and checking later on.
> It somewhat disturbs the workflow if you always have to look up where the voiceN ended up in the last measure, especially if you have larger intervals in the voices, or reentering the durations if one voice stays in 16, the next in 8 and the third in 2.
>
> What about, e.g., ":"? It's fast to type, and AFAICS, it only is used for chord mode and figured bass. And I don't see a use for those two in \parallelMusic, since - well, you usually only have one chord at a time, right?
> Another idea: "||", to serve both as bar check and as delimiter. And there's definitely no use conflict against two bar checks at the same point in time, right?

Currently, \parallelMusic highjacks the usual meaning of the pipe symbol:
When the function finds a BarCheck music element (which is what a pipe is
changed into by the parser), it interprets it as: change to the next voice.
This was done so that \parallelMusic has no impact on the parser. The main
drawback is the one that you point out: bar checks are not possible (at
least, not as easily) in parallel music.

So if you want to change the voice separator, in order to keep the meaning
of the pipe, you will have to introduce another token for voice separation,
and modify the parallelMusic function so that it does not interpret BarChecks
as the voice separator, but instead use a dedicated music element.

For the voice separation syntax, you have two options:
- introduce a new token in the lexer and the parser, e.g. "&";
- or use something like that:
"s" =
#(define-music-function (parser location) ()
(make-music 'VoiceSeparator))
then the voice separator is \s.

Modify parallelMusic, so that when a VoiceSeparator (instead of BarCheck)
music element is found, the function switches to the next voice. The
parallelMusic function seems well documented, this part should not be
difficult.

Nicolas

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

[GLISS] Syntax of \parallelMusic

2009-11-29T07:15:03Z

Hi, all,

something to discuss for the GLISS... I don't know where the right place
is for such a suggestion (or if it's there at all), so I send it to
-devel - so that it ends up in the archives at least.

I propose using a different separator for \parallelMusic than "|", and
allow to include bar checks in there.

\parallelMusic as is is very fine and handy, but sometimes you want to
enter a whole phrase of two or three measures in a single go, and
include the bar checks in there for readability and checking later on.
It somewhat disturbs the workflow if you always have to look up where
the voiceN ended up in the last measure, especially if you have larger
intervals in the voices, or reentering the durations if one voice stays
in 16, the next in 8 and the third in 2.

What about, e.g., ":"? It's fast to type, and AFAICS, it only is used
for chord mode and figured bass. And I don't see a use for those two in
\parallelMusic, since - well, you usually only have one chord at a time,
right?
Another idea: "||", to serve both as bar check and as delimiter. And
there's definitely no use conflict against two bar checks at the same
point in time, right?

Cheers,
Alexander

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

Re: Issue 638 in lilypond: auto-beam-settings do not take into account all durations covered by the beam

2009-11-29T07:10:54Z

On 11/29/09 7:53 AM, "Alexander Kobel" <news@...> wrote:

> lilypond@... wrote:
>> Comment #7 on issue 638 by percival.music.ca: auto-beam-settings do not
>> take into account *all* durations covered by the beam
>>
>> I think this is the autobeaming issue that Carl's working on.
>
>
> Hi, Carl,
>
> from what I understand from Graham's remark it is you who's working on
> beaming?
> If so, perhaps you can help me with the following and/or include it in
> your thoughts and implementation.
>
> I have a few pieces where I want use beams to denote melismata . On the
> other hand, for some longer melismata - often also including quarter or
> half notes - which I specify with slurs, I want the usual automatic
> beaming take place inside.

Why not just use \melisma and \melismaEnd?

>
> Now, it's awkward to always write ([ ]), when essentially ( ) already
> implies what I want. So, a straightforward idea was to leave auto
> beaming activated, and try a function like this:
>
> INPUT: music m
>
> slurred = false
> for each chord c in m {
> if (c contains a "(" [slur-begin]) {
> slurred = true
> add forbid-beam-to-the-left to c
> add allow-beam-to-the-right to c
> } else if (c contains a ")") {
> slurred = false
> add allow-beam-to-the-left to c
> add forbid-beam-to-the-right to c
> } else {
> if (slurred) {
> add allow-beam-to-the-left to c
> add allow-beam-to-the-right to c
> } else {
> add forbid-beam-to-the-left to c
> add forbid-beam-to-the-right to c
> }
> }
> }
>
> Alas, the problem is: the allow-beam-* and forbid-beam-* are
> nonexistent, AFAICS. \noBeam outside of the slurs destroys the auto
> beaming from the last possible beam start position to this point, which
> may influence notes in the surrounding melismata; and something like
> just adding [ to ( and ] to ) gives stub beams also in cases like { c8([
> c4 c8]) }, where I actually want flags.
>
>
> So, my question is: how much effort would it take to have such a
> allow-beam-* or forbid-beam-* functionality?
> I also could imagine a \splitBeam command, which forbids a "bridge beam"
> between the preceding and the following note:
>
> { c8 c c c c \splitBeam c c c }
> ========== | =======
> | | | | |\ | | |
> | | | | | | | |
>
> Then, the code for my function would look like
>
> slurred = false
> for each chord c in m {
> if (c contains a "(" [slur-begin]) {
> slurred = true
> insert \splitBeam before c
> } else if (c contains a ")") {
> slurred = false
> } else {
> if (! slurred) {
> insert \splitBeam before c
> }
> }
> }
>
> Hell, even simpler. But - as I said - I have no idea of the work
> involved in this. It'd be great if you think about it, though.

None of this functionality is currently in autobeaming, AFAICS, and I don't
think that I'm going to try to implement it in the near future. My interest
in autobeaming isn't that high. I just want to get the current bug fixed
(and then maybe I'll try to get subdivide working, if I can ever figure out
just what that means).

If you'd like to work on this, I'll be happy to share what I know about
autobeaming with you.

Thanks,

Carl

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

Re: Issue 638 in lilypond: auto-beam-settings do not take into account all durations covered by the beam

2009-11-29T06:53:06Z

lilypond@... wrote:
> Comment #7 on issue 638 by percival.music.ca: auto-beam-settings do not
> take into account *all* durations covered by the beam
>
> I think this is the autobeaming issue that Carl's working on.

Hi, Carl,

from what I understand from Graham's remark it is you who's working on
beaming?
If so, perhaps you can help me with the following and/or include it in
your thoughts and implementation.

I have a few pieces where I want use beams to denote melismata . On the
other hand, for some longer melismata - often also including quarter or
half notes - which I specify with slurs, I want the usual automatic
beaming take place inside.

Now, it's awkward to always write ([ ]), when essentially ( ) already
implies what I want. So, a straightforward idea was to leave auto
beaming activated, and try a function like this:

INPUT: music m

slurred = false
for each chord c in m {
if (c contains a "(" [slur-begin]) {
slurred = true
add forbid-beam-to-the-left to c
add allow-beam-to-the-right to c
} else if (c contains a ")") {
slurred = false
add allow-beam-to-the-left to c
add forbid-beam-to-the-right to c
} else {
if (slurred) {
add allow-beam-to-the-left to c
add allow-beam-to-the-right to c
} else {
add forbid-beam-to-the-left to c
add forbid-beam-to-the-right to c
}
}
}

Alas, the problem is: the allow-beam-* and forbid-beam-* are
nonexistent, AFAICS. \noBeam outside of the slurs destroys the auto
beaming from the last possible beam start position to this point, which
may influence notes in the surrounding melismata; and something like
just adding [ to ( and ] to ) gives stub beams also in cases like { c8([
c4 c8]) }, where I actually want flags.

So, my question is: how much effort would it take to have such a
allow-beam-* or forbid-beam-* functionality?
I also could imagine a \splitBeam command, which forbids a "bridge beam"
between the preceding and the following note:

{ c8 c c c c \splitBeam c c c }
========== | =======
| | | | |\ | | |
| | | | | | | |

Then, the code for my function would look like

slurred = false
for each chord c in m {
if (c contains a "(" [slur-begin]) {
slurred = true
insert \splitBeam before c
} else if (c contains a ")") {
slurred = false
} else {
if (! slurred) {
insert \splitBeam before c
}
}
}

Hell, even simpler. But - as I said - I have no idea of the work
involved in this. It'd be great if you think about it, though.

Thanks,
Alexander

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

Re: Implementing Baroque Lute tablature

2009-11-28T16:45:12Z

Neil Puttock wrote Saturday, November 28, 2009 6:01 PM

> 2009/11/26 Trevor Daniels <t.daniels@...>:
>
>> Is this a sensible/suitable/best approach? Any other
>> comments welcome.
>
> I can't see anything wrong with the approach you've outlined
> below.

Thanks Neil; that's the encouragement I needed :)

>> Lettered fret indications
>> Based on "Letter tablature formatting" example from LSR
>> Needs to be installed in scm/translation-functions.scm
>> Call it fret-letter-tablature-format
>
> I notice the example pdf doesn't have whiteouts around the notes;
> would you consider making this a tweakable option?

Good idea. Will do.

>> Lute tab contexts
>> New contexts LuteTabStaff and LuteTabVoice to draw
>> all this (and a few other things) together
>
> Why not just LuteStaff and LuteVoice for these?

Well, they'll be based on TabStaff/TabVoice rather than
Staff/Voice contexts. I think I prefer to have Tab in the
name as that is what they are - Lute Tablature.

I'm nearly ready to start, but I have one problem.
Here's what I've done:

Install Sun VirtualBox - done, ok
Install Ubuntu - done, ok (thanks Jonathan!)
Upgrade Ubuntu to 9.10 - done, ok
Make git repo - done, ok
Compile Lily and Docs - done, ok
Install keys - done, ok
Test push - done, ok

Run make test-baseline - Problem!
Appears to run without serious error (console log below), but all
images in collated-files.html are broken because they are .png
but no .png files have been generated, just .eps. Any ideas?

Console log:

GNUmakefile:28: warning: overriding commands for target `install'
/home/trevor/lilypond-git/stepmake/stepmake/generic-targets.make:135:
warning: ignoring old commands for target `install'
GNUmakefile:28: warning: overriding commands for target `po-update'
/home/trevor/lilypond-git/stepmake/stepmake/podir-targets.make:14:
warning: ignoring old commands for target `po-update'
Map filename
is:
/home/trevor/lilypond-git/./out-test/xref-maps/collated-files.xref-map
Docu name is collated-files
Map filename
is:
/home/trevor/lilypond-git/./out-test/xref-maps/collated-files.xref-map
Docu name is collated-files
Map filename
is:
/home/trevor/lilypond-git/./out-test/xref-maps/collated-files.xref-map
Docu name is collated-files

> Regards,
> Neil

Trevor

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

Re: Alternative music font

2009-11-28T10:58:32Z

On Sat, Nov 28, 2009 at 2:27 PM, Carl Sorensen <c_sorensen@...> wrote:

>> > It's interesting that you should mention that: that actually reminds
>> > me of one of my specific issues with Feta, namely that the curved
>> > centre line of its treble clef _does_ make it look to me as if it's
>> > leaning over backwards. Gonville's straight-backed version feels
>> > much more balanced to me.
>>
>> That would be a bug. How many degrees would you need to rotate it to
>> get it straight, in your opinion?
>>
> Thanks to the great work on the SVG backend, I was able to do a test.
>
> I rotated the clef by 1, 2.5, and 5 degrees.
>
> Surprisingly, I could see small differences. I'd think somewhere
> between 1 and 2.5 degrees would be about right. I like the 2.5 degrees
> best at the top of the clef, but I think the tail needs to be adjusted
> a little bit to look right at 2.5 degrees.
>
> Even the 1 degree rotation appears better balanced IMO.

Good spotting!

We might also be able to fix things by moving the intersection (where
the 2 lines and the staff line) come together and the bulb slightly to
the right.

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

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

Re: translations

2009-11-28T10:52:22Z

On Fri, Nov 27, 2009 at 08:11:46PM +0100, John Mandereau wrote:
> Le vendredi 27 novembre 2009 à 14:38 +0000, Graham Percival a écrit :
> > I have
> > index_abt, index_toc (which we don't want/need, but I don't know
> > how to get rid of).
>
> WTM would you like to get rid of them?

They're not linked from the other HTML files (at least, not from
web/ files), so they only use up disk space. Not much, of course,
but if nobody ever sees them, why bother keeping them?

Cheers,
- Graham

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

Re: git bisect; finding exact commits of bugs

2009-11-28T10:48:56Z

On Fri, Nov 27, 2009 at 09:54:49PM -0800, Patrick McCarty wrote:

> On Fri, Nov 27, 2009 at 9:27 PM, Graham Percival
> <graham@...> wrote:
> > If it doesn't exist already, is it worth writing something for the
> > CG about using git bisect to find the exact commit where a
> > regression was introduced?
>
> There doesn't appear to be anything in the CG about `git bisect'. The
> man page for this command appears to have an easy-to-understand (for
> me) example, under the heading "Basic bisect commands: start, bad,
> good". But maybe we should write an even simpler example?

Nah; I'll just add it to Issues. If the man page is clear, then
anybody not willing to read it wouldn't actually do the work
anyway.

Cheers,
- Graham

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

Re: LSR update adds whitespace

2009-11-28T10:07:05Z

On Sat, Nov 28, 2009 at 04:58:01PM +0000, Neil Puttock wrote:
> 2009/11/27 Graham Percival <graham@...>:
>
> > 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.

Cheers,
- Graham

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

Re: Implementing Baroque Lute tablature

2009-11-28T10:01:36Z

2009/11/26 Trevor Daniels <t.daniels@...>:

> Is this a sensible/suitable/best approach? Any other
> comments welcome.

I can't see anything wrong with the approach you've outlined below.

> Lettered fret indications
> Based on "Letter tablature formatting" example from LSR
> Needs to be installed in scm/translation-functions.scm
> Call it fret-letter-tablature-format

I notice the example pdf doesn't have whiteouts around the notes;
would you consider making this a tweakable option?

> Lute tab contexts
> New contexts LuteTabStaff and LuteTabVoice to draw
> all this (and a few other things) together

Why not just LuteStaff and LuteVoice for these?

Regards,
Neil

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

Re: LSR update adds whitespace

2009-11-28T08:58:01Z

2009/11/27 Graham Percival <graham@...>:

> 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.

Cheers,
Neil

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

Re: Alternative music font

2009-11-28T08:27:27Z

Jan Nieuwenhuizen <janneke-list <at> xs4all.nl> writes:

>
> Op maandag 19-10-2009 om 15:33 uur [tijdzone +0100], schreef Simon
> Tatham:
>
> > It's interesting that you should mention that: that actually reminds
> > me of one of my specific issues with Feta, namely that the curved
> > centre line of its treble clef _does_ make it look to me as if it's
> > leaning over backwards. Gonville's straight-backed version feels
> > much more balanced to me.
>
> That would be a bug. How many degrees would you need to rotate it to
> get it straight, in your opinion?
>

Thanks to the great work on the SVG backend, I was able to do a test.

I rotated the clef by 1, 2.5, and 5 degrees.

Surprisingly, I could see small differences. I'd think somewhere
between 1 and 2.5 degrees would be about right. I like the 2.5 degrees
best at the top of the clef, but I think the tail needs to be adjusted
a little bit to look right at 2.5 degrees.

Even the 1 degree rotation appears better balanced IMO.

Thanks,

Carl

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

clefcheck3.png (58K) Download Attachment

Re: [frogs] Frog's Lament

2009-11-28T04:58:06Z

Francisco Vila <paconet.org@...> writes:

> 2009/11/27 David Kastrup <dak@...>:
>> I have what amounts to severe attention disorder syndrome. I can't
>> focus on easy tasks. I can only work effectively on hard or
>> impossible things, mostly until 95% are done. When learning or
>> practicing an instrument, the successful way for me was to take on
>> things that were 10 times my level. I could work on those. And
>> after a lot of time, they were just 2 times my level, and I could
>> take on new challenges because I was not progressing any more.
>
> This regime may be good for your well-being and mind health, but do
> you think seriously it is good for a collaborative effort like
> LilyPond? From your literal words, are you aware that it may cause
> unresolved bugs that nobody except you could fix?

Mastery means finding the most straightforward solution, not the hardest
one. Sometimes that involves encapsulating a small piece of
_inherently_ complex functionality, in order to make the rest of the
task easier.

For example, take scheme continuations: they are universal enough that
you can do almost any control structure with them. But if you use them,
it is almost always prudent to first _design_ a much less universal
control structure that one can actually understand more intuitively, and
use _that_ for implementing your problem.

I don't play complex pieces beyond the edge of my mastery in public. I
play those that have become accessible to me. Even if they only became
accessible in the course of spending time and effort failing on harder
ones.

--
David Kastrup

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

Re: [frogs] Frog's Lament

2009-11-28T02:56:16Z

2009/11/27 David Kastrup <dak@...>:
> I have what amounts to severe attention disorder syndrome. I can't
> focus on easy tasks. I can only work effectively on hard or impossible
> things, mostly until 95% are done. When learning or practicing an
> instrument, the successful way for me was to take on things that were 10
> times my level. I could work on those. And after a lot of time, they
> were just 2 times my level, and I could take on new challenges because I
> was not progressing any more.

This regime may be good for your well-being and mind health, but do
you think seriously it is good for a collaborative effort like
LilyPond? From your literal words, are you aware that it may cause
unresolved bugs that nobody except you could fix?

Just trying to understand all this stuff. Every help is welcome.

--
Francisco Vila. Badajoz (Spain)
www.paconet.org
www.csmbadajoz.com

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

Re: git bisect; finding exact commits of bugs

2009-11-27T21:54:49Z

On Fri, Nov 27, 2009 at 9:27 PM, Graham Percival
<graham@...> wrote:
> If it doesn't exist already, is it worth writing something for the
> CG about using git bisect to find the exact commit where a
> regression was introduced?

There doesn't appear to be anything in the CG about `git bisect'. The
man page for this command appears to have an easy-to-understand (for
me) example, under the heading "Basic bisect commands: start, bad,
good". But maybe we should write an even simpler example?

> If it does exist, would it be worth trying to convince a frog or
> two to spend time doing this? I heartily admit that it's not
> glamorous work, but if any regression issues could have the commit
> identified, I imagine it would be one less task for whoever's
> working on a patch for said regression.

Sure, I think it would helpful to find the problematic commits,
especially for regressions.

For #907, I only suspected three different commits, and was lucky that
I found the exact commit by reverting each in turn.

-Patrick

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

git bisect; finding exact commits of bugs

2009-11-27T21:27:35Z

If it doesn't exist already, is it worth writing something for the
CG about using git bisect to find the exact commit where a
regression was introduced?

If it does exist, would it be worth trying to convince a frog or
two to spend time doing this? I heartily admit that it's not
glamorous work, but if any regression issues could have the commit
identified, I imagine it would be one less task for whoever's
working on a patch for said regression.

Cheers,
- Graham

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

Re: nifty grid view of issues

2009-11-27T20:13:33Z

On Fri, Nov 27, 2009 at 09:04:10PM -0700, Carl Sorensen wrote:
> On 11/27/09 2:29 PM, "Graham Percival" <graham@...> wrote:
>
> > After a bit of experimenting, I think this is the best way to view issues:
> > http://code.google.com/p/lilypond/issues/list?mode=grid=Priority=Type=ids
>
> Yes, quite nice. It's very helpful. Thanks!

Also of note: items marked "Documentation" generally only need a
few sentences added to the docs. We could probably close 5 of
these issues with half an hour of doc-editing... if anybody wanted
to touch the docs?

Remember folks, you don't need to compile anything to write+test
docs!

> > Note that anything in the High or Regression range stops 2.14 from
> > being released.
>
> 697 dates from 2.11, so we released 2.12 with it. Do we want to hold up
> 2.14 for it?

Dunno. There's also at least one item called "Regression: blah
blah" which isn't at Regression priority. I was going to raise
this question in a few days, after everybody has had a chance to
delete all the issue update emails. :)

> > BTW, my initial guess is that 787 could be fixed with less than 5
> > lines of scheme; I think some code is doing a simple comparison rather
> > than sorting through a list.
>
> Actually, this had nothing to do with it. I'm not sure exactly why, but
> with the extra notes the outside-staff-priority was used instead of the
> script-priority. And the outside-staff-priority was not set properly.

Thanks!

Cheers,
- Graham

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

Re: nifty grid view of issues

2009-11-27T20:04:10Z

On 11/27/09 2:29 PM, "Graham Percival" <graham@...> wrote:

> After a bit of experimenting, I think this is the best way to view issues:
> http://code.google.com/p/lilypond/issues/list?mode=grid=Priority=Type=ids
> <http://code.google.com/p/lilypond/issues/list?mode=grid&y=Priority&x=Type&cel
> ls=ids>
>
> Neat, huh? I'll add it to the CG.

Yes, quite nice. It's very helpful. Thanks!

>
> Note that anything in the High or Regression range stops 2.14 from
> being released.
>

697 dates from 2.11, so we released 2.12 with it. Do we want to hold up
2.14 for it?

>
> BTW, my initial guess is that 787 could be fixed with less than 5
> lines of scheme; I think some code is doing a simple comparison rather
> than sorting through a list.

Actually, this had nothing to do with it. I'm not sure exactly why, but
with the extra notes the outside-staff-priority was used instead of the
script-priority. And the outside-staff-priority was not set properly.

Anyway, I fixed it.

Carl

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

Re: nifty grid view of issues

2009-11-27T18:31:47Z

On Fri, Nov 27, 2009 at 2:29 PM, Graham Percival
<graham@...> wrote:
> After a bit of experimenting, I think this is the best way to view issues:
> http://code.google.com/p/lilypond/issues/list?mode=grid&y=Priority&x=Type&cells=ids
>
> Neat, huh? I'll add it to the CG.

Yes! That is very cool. Somehow they seem less daunting in that format
... maybe because they take up so little space.

> Note that anything in the High or Regression range stops 2.14 from
> being released.
>
>
> BTW, my initial guess is that 787 could be fixed with less than 5
> lines of scheme; I think some code is doing a simple comparison rather
> than sorting through a list.
>
> Also, could somebody on OSX check 752 (high defect) ? I suspect this
> has been fixed by bumping pango.
>
> Also, 818 (high defect)?
>
> Cheers,
> - Graham
>
>
> _______________________________________________
> bug-lilypond mailing list
> bug-lilypond@...
> http://lists.gnu.org/mailman/listinfo/bug-lilypond
>

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

nifty grid view of issues

2009-11-27T13:29:39Z

After a bit of experimenting, I think this is the best way to view issues:
http://code.google.com/p/lilypond/issues/list?mode=grid&y=Priority&x=Type&cells=ids

Neat, huh? I'll add it to the CG.

Note that anything in the High or Regression range stops 2.14 from
being released.

BTW, my initial guess is that 787 could be fixed with less than 5
lines of scheme; I think some code is doing a simple comparison rather
than sorting through a list.

Also, could somebody on OSX check 752 (high defect) ? I suspect this
has been fixed by bumping pango.

Also, 818 (high defect)?

Cheers,
- Graham

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

LSR update adds whitespace

2009-11-27T12:30:09Z

commit d069aeb6109be7dd0f93b1e6b65f79198335ab96
adds a single space at the end of a line to a bunch of files in LSR.

I'm not certain if that's related to the recent changes to makelsr.py,
or whether Neil automatically stripped out the extra whitespace when
committing LSR updates, or what.

Cheers,
- Graham

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

Re: translations

2009-11-27T11:11:46Z

Le vendredi 27 novembre 2009 à 14:38 +0000, Graham Percival a écrit :
> I have no index_xy.html files where _xy is a number.

I have no longer such files generated in my build tree with current
master, I hope it's still the same for you.

> I have
> index_abt, index_toc (which we don't want/need, but I don't know
> how to get rid of).

WTM would you like to get rid of them?

Best,
John

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

signature.asc (205 bytes) Download Attachment

Re: Issue 872 in lilypond: Changes split-page has broken images

2009-11-27T11:09:04Z

Le lundi 09 novembre 2009 à 20:08 +0000, Graham Percival a écrit :
> And we could try looking into why we get the duplicate
> anchors which confuse opera)

If Opera is case-sensitive for anchors, it looks like I accidentally
solved this issue: this isn't a consequence of a deliberate design but
of my inability to downcase file names and anchors independently and the
way I want, without getting deeper into the mess of Texi2HTML
customization interface.

Best,
John

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

signature.asc (205 bytes) Download Attachment

Re: [frogs] Frog's Lament

2009-11-27T07:39:17Z

Hi Valentin,

> On Fri, Nov 27, 2009 at 10:36 AM, David Kastrup <dak@...> wrote:
>> Remember Rune.
>
> I feel deeply shocked by your last sentence.

Given his prior behavior on the list(s) — how rude and completely
lacking in social filters he clearly is — I had honestly thought that
nothing else David would say could shock me…
But you're right: this is beyond the pale.

Oh, wait... did I copy this to the list?
Kieren.

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

Re: translations

2009-11-27T06:38:24Z

On Fri, Nov 27, 2009 at 11:32:04AM +0100, John Mandereau wrote:
> Le vendredi 27 novembre 2009 à 00:20 +0000, Graham Percival a écrit :
> > I'm really, *really* doubting this. I've got plenty of
> > name.fr.html files, and no index_xy.html files.
>
> I can provide you a SSH access to my box (provided I have a public and
> not too filtered IP address) if you don't believe me :-)

Let's try this step by step:
- switch to master
- rm -rf *
- git reset --hard origin
- ./autogen.sh
- nice make -j4
- nice make -j4 CPU_COUNT=4 doc
- ls Documentation/out-www/web/

I have no index_xy.html files where _xy is a number. I have
index_abt, index_toc (which we don't want/need, but I don't know
how to get rid of).

I have a bunch of nodes beginning with a capital letter, but
introduction.nl.html (which AFAIK is the only semi-translated
file) shows up with a lower-case first letter.

If you see anything different, could you stop by the irc channel
or something? Something's seriously wonky.

Cheers,
- Graham

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

Nabble - Gnu - Lilypond - Dev

Re: Describing instruments

Re: Priority-Regression policy

Re: Priority-Regression policy

Re: Describing instruments

Priority-Regression policy

Re: [GLISS] Syntax of \parallelMusic

Re: Describing instruments

Describing instruments

Re: [GLISS] Syntax of \parallelMusic

Re: [GLISS] Syntax of \parallelMusic

Re: [GLISS] Syntax of \parallelMusic

[GLISS] Syntax of \parallelMusic

Re: Issue 638 in lilypond: auto-beam-settings do not take into account *all* durations covered by the beam

Re: Issue 638 in lilypond: auto-beam-settings do not take into account *all* durations covered by the beam

Re: Implementing Baroque Lute tablature

Re: Alternative music font

Re: translations

Re: git bisect; finding exact commits of bugs

Re: LSR update adds whitespace

Re: Implementing Baroque Lute tablature

Re: LSR update adds whitespace

Re: Alternative music font

Re: [frogs] Frog's Lament

Re: [frogs] Frog's Lament

Re: git bisect; finding exact commits of bugs

git bisect; finding exact commits of bugs

Re: nifty grid view of issues

Re: nifty grid view of issues

Re: nifty grid view of issues

nifty grid view of issues

LSR update adds whitespace

Re: translations

Re: Issue 872 in lilypond: Changes split-page has broken images

Re: [frogs] Frog's Lament

Re: translations

Re: Issue 638 in lilypond: auto-beam-settings do not take into account all durations covered by the beam

Re: Issue 638 in lilypond: auto-beam-settings do not take into account all durations covered by the beam