Re: [PATCH] functional-or returned #f for (functional-or #f #t #f). Fixed.
Patrick McCarty writes: > On 2009-11-16, David Kastrup wrote: >> >> It still suffers from not doing short-circuit evaluation. For >> readability and efficiency, I'd really prefer replacing >> '(apply functional-or' with '(any' > > It looks like Neil removed the "is-harmonic" binding from this > procedure a couple of days ago, since it was unused. > > So, nothing really needs to be changed after all. :-) Still I feel more comfortable with this patch in place. I am not entirely sure whether it would not be simpler to just scratch both functional-or and functional-and altogether since they are basically only useful in situations where one would better use a different mapping function with short-circuit evaluation. All the best -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Suggestion: Music analysis in Lilypond?
A Chordname like thing would take quite much time to implement and I don't think it is important enough for most of the users to make it happen. Though you can use the Lyrics context for this, because you can write markups as lyric syllables if I'm right. On the lilypond-user list I'm quite sure you'll get directions if you can't figure out from the manual.. Ernir ÓskarPálsson wrote: Dear developers, I have recently found Lilypond, and am discovering step by step what a wonderful program it is, and what a quick and simple method to print beautiful music it presents (once I am a little more acquainted with it at least). I have been learning the basics og the program through writing up and completing my musical analysis assignments (am currently studying Musicology) The figured bass tool (or is it called context?) has been terrific to use, and leaves me wanting more: Would it be possible to make a similar tool (or perhaps even more similar to the Chordnames thing), where you can simply write harmonical analysis; that is either the functional system (T S Sp D7 etc.) and/or the "Schönberg/Hindemith" type with roman numbers (I IV ii V7 etc.)? The variants (bassnote-numbers, Dominant of Dominant, tonic-free chords, french/German/Italian chords etc.) could propably be implemented in a similar way as in the figured bass (?) I hope I am not wasting your time, I realize lots of people must have thought of this and perhaps there is some way to write it that I have yet to find out (like I said I am new at this, and less than worthless at programming). If you like the idea, however, an implementation in a future update would be terrific! otherwise, keep up the good work!! Thankful regards, Ernir Pálsson ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Suggestion: Music analysis in Lilypond?
Dear developers, I have recently found Lilypond, and am discovering step by step what a wonderful program it is, and what a quick and simple method to print beautiful music it presents (once I am a little more acquainted with it at least). I have been learning the basics og the program through writing up and completing my musical analysis assignments (am currently studying Musicology) The figured bass tool (or is it called context?) has been terrific to use, and leaves me wanting more: Would it be possible to make a similar tool (or perhaps even more similar to the Chordnames thing), where you can simply write harmonical analysis; that is either the functional system (T S Sp D7 etc.) and/or the "Schönberg/Hindemith" type with roman numbers (I IV ii V7 etc.)? The variants (bassnote-numbers, Dominant of Dominant, tonic-free chords, french/German/Italian chords etc.) could propably be implemented in a similar way as in the figured bass (?) I hope I am not wasting your time, I realize lots of people must have thought of this and perhaps there is some way to write it that I have yet to find out (like I said I am new at this, and less than worthless at programming). If you like the idea, however, an implementation in a future update would be terrific! otherwise, keep up the good work!! Thankful regards, Ernir Pálsson ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] functional-or returned #f for (functional-or #f #t #f). Fixed.
On 2009-11-16, David Kastrup wrote: > Patrick McCarty writes: > > > Thanks, pushed. > > Thanks. The only caller (this is apparently in local namespace) as far > as I can see is > > (define-public (fret-number-tablature-format string context event) > (let* ((tuning (ly:context-property context 'stringTunings)) >(pitch (ly:event-property event 'pitch)) >(is-harmonic (apply > functional-or > (map > (lambda (ev) > (eq? 'harmonic-event (ly:event-property ev 'class))) > (ly:event-property event 'articulations) > > And that would likely be better written as > > (is-harmonic (memq 'harmonic-event >(map (lambda (ev) (ly:event-property ev 'class)) > (ly:event-property event 'articulations))) > > It still suffers from not doing short-circuit evaluation. For > readability and efficiency, I'd really prefer replacing > '(apply functional-or' with '(any' It looks like Neil removed the "is-harmonic" binding from this procedure a couple of days ago, since it was unused. So, nothing really needs to be changed after all. :-) Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH 1/2] scm/define-markup-commands.scm: remove some unnecessary lookups
Carl Sorensen writes: > I appreciate your work on this. > > However, I am *not* in favor of moving in this direction to solve the > problems you correctly identified. > > In my mind, the *last* thing we need is another opaque interface in > LilyPond, where in the markup command we don't know whether a certain > property is to be looked up in props or to be assigned a value in a > let-binding from the define-internal-markup-command macro. > > I think it's *much* better to pass default values as appended values > to the tail of props. Then we can go ahead and use a props lookup in > the code. Hm? As I already wrote, I did a code review and this is the style used for 95% of the existing markups. My patches just bring the remaining 5% in line with the rest. There is not much point in _not_ applying them unless you plan to change the other 95%. Even then, starting from a consistent state does not much harm. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH 1/2] scm/define-markup-commands.scm: remove some unnecessary lookups
Le 17 nov. 2009 à 19:00, Carl Sorensen a écrit : > David, > > I appreciate your work on this. > > However, I am *not* in favor of moving in this direction to solve the > problems you correctly identified. > > In my mind, the *last* thing we need is another opaque interface in > LilyPond, where in the markup command we don't know whether a certain > property is to be looked up in props or to be assigned a value in a > let-binding from the define-internal-markup-command macro. > > I think it's *much* better to pass default values as appended values to the > tail of props. Then we can go ahead and use a props lookup in the code. I disagree. The patch is consistent with all other markup command definitions, and inforces a common coding style. Changing the value of `props' as you suggest is not much better: changing the value of a function argument behind the scene is not what I would call a fine design. Moreover, seeing the chain-assoc-get calls ever and ever on the very same argument calls for a simplification: this is the lisp way of things. That's why I introduced this property binding mechanism. The interface is opaque, you're right. Then it shall be better documented: please wait for a few days until I work on that. Nicolas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: My "make doc" is broken
> You forgot "make doc-clean" in this sequence; in this case "make -C > Documentation/ doc-clean" (which avoids rebuilding all snippets with > lilypond-book) might be enough to get rid of your error with pdftex. That worked, thanks, Frédéric ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH 1/2] scm/define-markup-commands.scm: remove some unnecessary lookups
David,
I appreciate your work on this.
However, I am *not* in favor of moving in this direction to solve the
problems you correctly identified.
In my mind, the *last* thing we need is another opaque interface in
LilyPond, where in the markup command we don't know whether a certain
property is to be looked up in props or to be assigned a value in a
let-binding from the define-internal-markup-command macro.
I think it's *much* better to pass default values as appended values to the
tail of props. Then we can go ahead and use a props lookup in the code.
Thanks,
Carl
On 11/17/09 9:27 AM, "David Kastrup" wrote:
> ---
> scm/define-markup-commands.scm |3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/scm/define-markup-commands.scm b/scm/define-markup-commands.scm
> index 08c24bb..fec895d 100644
> --- a/scm/define-markup-commands.scm
> +++ b/scm/define-markup-commands.scm
> @@ -732,7 +732,6 @@ If there are no arguments, return an empty stencil.
>stencils))
> (text-width (apply + text-widths))
> (word-count (length stencils))
> -(prop-line-width (chain-assoc-get 'line-width props #f))
> (line-width (or line-width (ly:output-def-lookup layout
> 'line-width)))
> (fill-space
> (cond
> @@ -3198,7 +3197,7 @@ where @var{X} is the number of staff spaces."
>((baseline-skip))
>"Like @code{\\column}, but return a list of lines instead of a single
> markup.
> @code{baseline-skip} determines the space between each markup in @var{args}."
> - (space-lines (chain-assoc-get 'baseline-skip props)
> + (space-lines baseline-skip
>(interpret-markup-list layout props args)))
>
> (define-builtin-markup-list-command (override-lines layout props new-prop
> args)
> --
> 1.6.5.3.153.g0670
>
>
>
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH 1/2] scm/define-markup-commands.scm: remove some unnecessary lookups
---
scm/define-markup-commands.scm |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/scm/define-markup-commands.scm b/scm/define-markup-commands.scm
index 08c24bb..fec895d 100644
--- a/scm/define-markup-commands.scm
+++ b/scm/define-markup-commands.scm
@@ -732,7 +732,6 @@ If there are no arguments, return an empty stencil.
stencils))
(text-width (apply + text-widths))
(word-count (length stencils))
-(prop-line-width (chain-assoc-get 'line-width props #f))
(line-width (or line-width (ly:output-def-lookup layout 'line-width)))
(fill-space
(cond
@@ -3198,7 +3197,7 @@ where @var{X} is the number of staff spaces."
((baseline-skip))
"Like @code{\\column}, but return a list of lines instead of a single markup.
@code{baseline-skip} determines the space between each markup in @var{args}."
- (space-lines (chain-assoc-get 'baseline-skip props)
+ (space-lines baseline-skip
(interpret-markup-list layout props args)))
(define-builtin-markup-list-command (override-lines layout props new-prop args)
--
1.6.5.3.153.g0670
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH 2/2] scm/harp-pedals.scm: Fold make-harp-pedal into \harp-pedal markup.
The already outcommented problematic \harp-pedal-verbose markup is
removed completely. Inlining make-harp-pedal makes it possible to use
the property binding mechanism of define-builtin-markup-command in
order to minimize inconsistencies between documentation and behavior.
---
scm/harp-pedals.scm | 115 ++
1 files changed, 42 insertions(+), 73 deletions(-)
diff --git a/scm/harp-pedals.scm b/scm/harp-pedals.scm
index f476783..7af4e71 100644
--- a/scm/harp-pedals.scm
+++ b/scm/harp-pedals.scm
@@ -9,7 +9,7 @@
(define-builtin-markup-command (harp-pedal layout props definition-string)
(string?)
instrument-specific-markup ; markup type for the documentation!
((size 1.2)
- (harp-pedal-details)
+ (harp-pedal-details '())
(thickness 0.5))
"Make a harp pedal diagram.
@@ -50,78 +50,8 @@ divider) and @code{space-after-divider} (box spacing after
the divider).
\\markup \\harp-pedal #\"^-v|--ov^\"
@end lilypond
"
- (make-harp-pedal layout props (harp-pedals-parse-string definition-string)))
-
-
-;; There is also a \harp-pedal-verbose version, which takes a list of -1/0/1
-;; directions, o and a possible |. It's commented out, because it has some
-;; issues (see below) and does not add any new functionality over \harp-pedal
-;; The caveats:
-;; 1) the | cannot be given as a string "|" but as a character #\| and
-;; the "o" has to be given as #\o.
-;; 2) if one wants to use directions like UP, CENTER or DOWN, one cannot use
-;; '(UP DOWN CENTER #\| ), because the contents of that list are
-;; never evaluated to -1/0/1. Instead one has to explicitly create a
-;; list like (list UP DOWN CENTER #\| )
-;;
-;; (define-builtin-markup-command (harp-pedal-verbose layout props pedal-list)
(list?)
-;; instrument-specific-markup ; markup type
-;; ((size 1.2)
-;;(harp-pedal-details)
-;;(thickness 0.5))
-;; "Make a harp pedal diagram containing the directions indicated in
@var{pedal-list}."
-;; (make-harp-pedal layout props pedal-list))
-
-
-
-;; Parse the harp pedal definition string into list of directions (-1/0/1),
#\o and #\|
-(define (harp-pedals-parse-string definition-string)
- "Parse a harp pedals diagram string and return a list containing 1, 0, -1,
#\\o or #\\|"
- (map (lambda (c)
-(case c
- ((#\^) 1)
- ((#\v) -1)
- ((#\-) 0)
- ((#\| #\o) c)
- (else c)))
-(string->list definition-string)))
-
-
-;; Analyze the pedal-list: Return (pedalcount . (divider positions))
-(define (harp-pedal-info pedal-list)
- (let check ((pedals pedal-list)
- (pedalcount 0)
- (dividerpositions '()))
-(if (null? pedals)
- (cons pedalcount (reverse dividerpositions))
-
- (case (car pedals)
-((-1 0 1) (check (cdr pedals) (+ pedalcount 1) dividerpositions))
-((#\|)(check (cdr pedals) pedalcount (cons pedalcount
dividerpositions)))
-(else (check (cdr pedals) pedalcount dividerpositions))
-
-
-;; Sanity checks, spit out warning if pedal-list violates the conventions
-(define (harp-pedal-check pedal-list)
- "Perform some sanity checks for harp pedals (7 pedals, divider after third)"
- (let ((info (harp-pedal-info pedal-list)))
-; 7 pedals:
-(if (not (equal? (car info) 7))
- (ly:warning "Harp pedal diagram contains ~a pedals rather than the usual
7." (car info)))
-; One divider after third pedal:
-(if (null? (cdr info))
- (ly:warning "Harp pedal diagram does not contain a divider (usually
after third pedal).")
- (if (not (equal? (cdr info) '(3)))
-(ly:warning "Harp pedal diagram contains dividers at positions ~a.
Normally, there is only one divider after the third pedal." (cdr info))
-
-
-(define (make-harp-pedal layout props pedal-list)
- "Make a harp pedals diagram markup"
-
- (harp-pedal-check pedal-list)
-
- (let* ((size (chain-assoc-get 'size props 1.2))
-(details (chain-assoc-get 'harp-pedal-details props '()))
+ (let* ((pedal-list (harp-pedals-parse-string definition-string))
+(details (begin (harp-pedal-check pedal-list) harp-pedal-details))
(dy (* size (assoc-get 'box-offset details 0.8))) ; offset of the box
center from the line
(line-width (* (ly:output-def-lookup layout 'line-thickness)
(chain-assoc-get 'thickness props 0.5)))
@@ -185,3 +115,42 @@ divider) and @code{space-after-divider} (box spacing after
the divider).
(make-line-stencil line-width 0 0 final-x 0)
stencils
+;; Parse the harp pedal definition string into list of directions (-1/0/1),
#\o and #\|
+(define (harp-pedals-parse-string definition-string)
+ "Parse a harp pedals diagram string and return a list containing 1, 0, -1,
#\\o or #\\|"
+ (map (lambda (c)
+(case c
+ ((#\^) 1)
+ ((#\v) -1)
+ ((#\-) 0)
+ ((#\| #\o) c)
+ (else c)))
+(string->list definition-string)))
+
+
+;; An
Re: Getting start/end moments from an Audio_element_info???
Am Dienstag, 17. November 2009 01:29:49 schrieb Han-Wen Nienhuys: > On Mon, Nov 16, 2009 at 4:54 PM, Reinhold Kainhofer > > wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > while trying to fix some MIDI issues, I've now run into the problem that > > in a performer's acknowledge_audio_element method I need to calculate the > > offset of the current Audio_element_info to a past info. Unfortunately, I > > couldn't find > > The audio element might not contain that information, but can't you > just do performer->now_mom() to get the current moment? Yes, of course, for the current moment. The problem is with ties and tieWaitForNote that when adding the end note of the tie, I can't simply append the duration of that end note to the start note of the tie, since that will miss any skips between the tied notes. So, I need the end moment of the starting note to get the gap between the tied notes Well, I suppose the only way then is how it is done in Tie_engraver, where a struct is used containing the tie object, spanner, start note and moment... Unfortunately, then I'm running into strange memory corruption issues here: Interpretation der Musik...terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Aborted Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: My "make doc" is broken
Le dimanche 15 novembre 2009 à 23:12 +0100, Frédéric Bron a écrit : > did not know that (not in CG): I did the sudo apt-get build-dep > lilypond. I have already tex2thml 1.82 (installed manually). > redone git pull, make clean, make all, make doc. You forgot "make doc-clean" in this sequence; in this case "make -C Documentation/ doc-clean" (which avoids rebuilding all snippets with lilypond-book) might be enough to get rid of your error with pdftex. HTH, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
