Re: Work on Issue 1320
Am 08.04.2012 15:38, schrieb Thomas Morley: Am 7. April 2012 16:06 schrieb Marc Hohlm...@hohlart.de: How shall we proceed? I am short of time now (I have to move with my familiy into another house by the end of april, perhaps even one or two weeks earlier), Well, that's the main problem for me, too. I can only work on/with lily in my leisure time. And for now I'm working most of my time on LSR-updating and the follow ups. But working on a single file/problem is somehow relaxing. :) but ... do you think we can work together on this issue? Perhaps we both could bring the stuff in a shape suitable for being included in lilys code base. I'd be glad to try to do so. How shall we communicate? - the devel-list is the right place to discuss major problems, but perhaps we should change the channel for minor problems, in order not to blow up the list. - we could switch to the frog-list http://lilypond-frogs.2124236.n2.nabble.com/ but this list is nearly dead. - Regarding your mail-address I think you live in Germany. Could we switch to german in private mails? I think we should choose the latter. We communicate privately via mail unless a) we have a perfect solution or b) we need help. And yes, I live in Germany, so we'll switch to german while out conspirative mail exchange. Regards, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Work on Issue 1320
Am 7. April 2012 16:06 schrieb Marc Hohl m...@hohlart.de: How shall we proceed? I am short of time now (I have to move with my familiy into another house by the end of april, perhaps even one or two weeks earlier), Well, that's the main problem for me, too. I can only work on/with lily in my leisure time. And for now I'm working most of my time on LSR-updating and the follow ups. But working on a single file/problem is somehow relaxing. :) but ... do you think we can work together on this issue? Perhaps we both could bring the stuff in a shape suitable for being included in lilys code base. I'd be glad to try to do so. How shall we communicate? - the devel-list is the right place to discuss major problems, but perhaps we should change the channel for minor problems, in order not to blow up the list. - we could switch to the frog-list http://lilypond-frogs.2124236.n2.nabble.com/ but this list is nearly dead. - Regarding your mail-address I think you live in Germany. Could we switch to german in private mails? Or perhaps we could use the german lilypond-forum http://www.lilypondforum.de/index.php#c1 What do you think? -Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Work on Issue 1320
Am 06.04.2012 23:04, schrieb Carl Sorensen: On 4/5/12 12:51 PM, Marc Hohlm...@hohlart.de wrote: Does it make sense to replace the definitions in bar-line.cc/span-bar.cc with the scheme equivalents? If yes, I'd draw a patch and would include one example for integrating user-defined bar lines with the new approach as a snippet (once I get the dashed bar line right in place ...) It seems to me that it makes sense to put the stencil building functions in Guile instead of in c++. No sense adding the extra interface layer for scheme calls from c++. I would suggest that you make custom-bar-print-alist and custom-bar-glyph-alist context properties, so they will be documented and available for modification. Whenever I see Scheme code that says something like (do (( ... (set! foo bar))) I cringe a bit. This looks like a direct statement-by-statement translation from c++, rather than an implementation in native Scheme idioms. Well, that's what I did, more or less. I saw a do-loop in Nicolas' code, and I am pretty sure he knows *a lot more* scheme than I do, and at least I am glad that the code works (well, most of it). It surely can be improved ... set! creates a side effect for the procedure, and the Scheme gurus like to avoid side effects as much as possible (at least they did 25 years ago ... am I really that old?). I haven't looked carefully at your code to write an alternative, but it's likely that this code can be rewritten either as a recursive function or as a map, fold, or apply function, all of which are more native Scheme idioms. Anyway, overall this looks like great work, and I think we ought to get it into the code base. Sounds good - thanks for your kind words! Regards, Marc Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Work on Issue 1320
Am 07.04.2012 01:03, schrieb Thomas Morley: Am 6. April 2012 23:04 schrieb Carl Sorensenc_soren...@byu.edu: On 4/5/12 12:51 PM, Marc Hohlm...@hohlart.de wrote: Does it make sense to replace the definitions in bar-line.cc/span-bar.cc with the scheme equivalents? If yes, I'd draw a patch and would include one example for integrating user-defined bar lines with the new approach as a snippet (once I get the dashed bar line right in place ...) It seems to me that it makes sense to put the stencil building functions in Guile instead of in c++. No sense adding the extra interface layer for scheme calls from c++. I would suggest that you make custom-bar-print-alist and custom-bar-glyph-alist context properties, so they will be documented and available for modification. Whenever I see Scheme code that says something like (do (( ... (set! foo bar))) I cringe a bit. This looks like a direct statement-by-statement translation from c++, rather than an implementation in native Scheme idioms. set! creates a side effect for the procedure, and the Scheme gurus like to avoid side effects as much as possible (at least they did 25 years ago ... am I really that old?). I haven't looked carefully at your code to write an alternative, but it's likely that this code can be rewritten either as a recursive function or as a map, fold, or apply function, all of which are more native Scheme idioms. Anyway, overall this looks like great work, and I think we ought to get it into the code base. Thanks, Carl I'm working on a very similiar stuff. But I didn' try to rewrite lily/bar-line.cc etc. I tried another approach, defining only drawing-functions for glyphs of string-length = 1 Putting them together with a recursive function. Please note: This is work in progress. You may recognize many fragments of your and Nicolas' work. Thanks to you both. Currently there are a lot of inconsequences and small issues. And I didn't work on the line-break and the span-bar so far. That's on my todo-list. :) Nevertheless, I'm able to print very curious custom-barlines. Perhaps you may get some ideas for your own work. Hey, looks good! The idea of building the bar lines by parsing the string argument is very clever! How shall we proceed? I am short of time now (I have to move with my familiy into another house by the end of april, perhaps even one or two weeks earlier), but ... do you think we can work together on this issue? Perhaps we both could bring the stuff in a shape suitable for being included in lilys code base. Regards, Marc -Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Work on Issue 1320
On 4/5/12 12:51 PM, Marc Hohl m...@hohlart.de wrote: Does it make sense to replace the definitions in bar-line.cc/span-bar.cc with the scheme equivalents? If yes, I'd draw a patch and would include one example for integrating user-defined bar lines with the new approach as a snippet (once I get the dashed bar line right in place ...) It seems to me that it makes sense to put the stencil building functions in Guile instead of in c++. No sense adding the extra interface layer for scheme calls from c++. I would suggest that you make custom-bar-print-alist and custom-bar-glyph-alist context properties, so they will be documented and available for modification. Whenever I see Scheme code that says something like (do (( ... (set! foo bar))) I cringe a bit. This looks like a direct statement-by-statement translation from c++, rather than an implementation in native Scheme idioms. set! creates a side effect for the procedure, and the Scheme gurus like to avoid side effects as much as possible (at least they did 25 years ago ... am I really that old?). I haven't looked carefully at your code to write an alternative, but it's likely that this code can be rewritten either as a recursive function or as a map, fold, or apply function, all of which are more native Scheme idioms. Anyway, overall this looks like great work, and I think we ought to get it into the code base. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Work on Issue 1320
Am 6. April 2012 23:04 schrieb Carl Sorensen c_soren...@byu.edu: On 4/5/12 12:51 PM, Marc Hohl m...@hohlart.de wrote: Does it make sense to replace the definitions in bar-line.cc/span-bar.cc with the scheme equivalents? If yes, I'd draw a patch and would include one example for integrating user-defined bar lines with the new approach as a snippet (once I get the dashed bar line right in place ...) It seems to me that it makes sense to put the stencil building functions in Guile instead of in c++. No sense adding the extra interface layer for scheme calls from c++. I would suggest that you make custom-bar-print-alist and custom-bar-glyph-alist context properties, so they will be documented and available for modification. Whenever I see Scheme code that says something like (do (( ... (set! foo bar))) I cringe a bit. This looks like a direct statement-by-statement translation from c++, rather than an implementation in native Scheme idioms. set! creates a side effect for the procedure, and the Scheme gurus like to avoid side effects as much as possible (at least they did 25 years ago ... am I really that old?). I haven't looked carefully at your code to write an alternative, but it's likely that this code can be rewritten either as a recursive function or as a map, fold, or apply function, all of which are more native Scheme idioms. Anyway, overall this looks like great work, and I think we ought to get it into the code base. Thanks, Carl I'm working on a very similiar stuff. But I didn' try to rewrite lily/bar-line.cc etc. I tried another approach, defining only drawing-functions for glyphs of string-length = 1 Putting them together with a recursive function. Please note: This is work in progress. You may recognize many fragments of your and Nicolas' work. Thanks to you both. Currently there are a lot of inconsequences and small issues. And I didn't work on the line-break and the span-bar so far. That's on my todo-list. :) Nevertheless, I'm able to print very curious custom-barlines. Perhaps you may get some ideas for your own work. -Harm custom-bars-01.ly Description: Binary data attachment: custom-bars-01.png___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Work on Issue 1320
Hello list, as issue 1320 is labeled as 'frog', I thought it would be a good idea to dig deeper into scheme and c++ by rewriting most parts of lily/bar-line.cc and lily/span-bar.cc It was not as easy and straightforward as I thought, because there were some cross-references between the two files. Please find attached what I have done so far. I don't know whether the kievan bar line makes sense with span bars, but I managed to get this better IMHO, but the dashed bar line is positioned *over* the topmost bar line, which is wrong. And I have to admit that some lines of code were adopted from Nicolas Sceaux's work on custom bar lines; this made this task a lot easier. Kudos to Nicolas! Does it make sense to replace the definitions in bar-line.cc/span-bar.cc with the scheme equivalents? If yes, I'd draw a patch and would include one example for integrating user-defined bar lines with the new approach as a snippet (once I get the dashed bar line right in place ...) Thanks in advance, Marc \version 2.15.34 #(define (bar-line::calc-bar-extent grob) (let ((staff-symbol (ly:grob-object grob 'staff-symbol)) (staff-extent (cons 0 0))) (if (ly:grob? staff-symbol) (let* ((bar-line-color (ly:grob-property grob 'color)) (staff-color (ly:grob-property staff-symbol 'color)) (radius (ly:staff-symbol-staff-radius grob)) (line-thickness (ly:staff-symbol-line-thickness grob))) (set! staff-extent (ly:staff-symbol::height staff-symbol)) (if (and (eq? bar-line-color staff-color) radius) (interval-widen staff-extent (- 1 (* 1/2 (/ line-thickness radius))) staff-extent)) #(define (bar-line::bar-y-extent grob refpoint) (let* ((extent (ly:grob-property grob 'bar-extent '(0 . 0))) (rel-y (ly:grob-relative-coordinate grob refpoint Y)) (y-extent (coord-translate extent rel-y))) y-extent)) #(define-public (bar-line::print grob) (let ((glyph (ly:grob-property grob 'glyph-name)) (extent (ly:grob-property grob 'bar-extent '(0 . 0 (if (and (not (eq? glyph '())) ( (interval-length extent) 0)) (bar-line::compound-bar-line grob glyph extent #f) #f))) #(define-public custom-bar-print-alist ;; this alist can contain one ore more entries ;; like (glyph-string . ,print-procedure) `()) #(define-public custom-bar-glyph-alist ;; this alist can contain one ore more entries ;; like (glyph-string . (glyph-at-end-of-line . glyph-at-begin-of-line)) `()) #(define-public (bar-line::custom-print grob) (let* ((glyph (ly:grob-property 'glyph-name)) (custom-proc (assoc-get glyph custom-bar-print-alist))) (if (procedure? custom-proc) (custom-proc grob) (bar-line::print grob #(define-public (bar-line::custom-calc-glyph-name grob) (let* ((glyph (ly:grob-property grob 'glyph)) (dir (ly:item-break-dir grob)) (result (assoc-get glyph custom-bar-glyph-alist))) (if (= dir CENTER) glyph (if result (and (string? (index-cell result dir)) (index-cell result dir)) (bar-line::calc-glyph-name grob) % bar line helper functions % #(define-public (bar-line::simple-bar-line grob width extent rounded) (let ((blot (if rounded (ly:output-def-lookup layout 'blot-diameter) 0))) (ly:round-filled-box (cons 0 width) extent blot))) #(define-public (bar-line::tick-bar-line grob height rounded) (let ((half-staff (* 1/2 (ly:staff-symbol-staff-space grob))) (stafflinethick (ly:staff-symbol-line-thickness grob)) (blot (if rounded (ly:output-def-lookup layout 'blot-diameter) 0))) (ly:round-filled-box (cons 0 stafflinethick) (cons (- height half-staff) (+ height half-staff)) blot))) #(define-public (bar-line::colon-bar-line grob) (let* ((staff-symbol (ly:grob-object grob 'staff-symbol)) (line-count (if (ly:grob? staff-symbol) (ly:grob-property staff-symbol 'line-count) 0)) (staff-space (ly:staff-symbol-staff-space grob)) (dist (cond ((odd? line-count) 1) ((zero? line-count) 1) (( staff-space 2) (* 2 staff-space)) (else (* 0.5 staff-space (dot (ly:font-get-glyph (ly:grob-default-font grob) dots.dot)) (stencil empty-stencil)) (set! stencil (ly:stencil-add stencil dot)) (set! stencil (ly:stencil-translate-axis stencil dist Y))
Re: Work on Issue 1320
On Thu, Apr 5, 2012 at 2:51 PM, Marc Hohl m...@hohlart.de wrote: I don't know whether the kievan bar line makes sense with span bars It doesn't make sense with span bars. but I managed to get this better IMHO I've attempted to modify your code to use stencil-whiteout to remove the staff lines behind the kievan bar line. Please see attached. Aleksandr barlinetest.ly Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
