Re: Align metronome mark at time signature or first musical element. Fixes #684. (issue1579041)
On 2010/07/27 14:14:12, janneke-list_xs4all.nl wrote: I'm "waiting" for an ack. From whom? http://codereview.appspot.com/1579041/show ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: T1055: Avoid using deprecated %module-public-interface in guile initialisation. (issue1160044)
On 2010/08/10 19:00:01, Ian Hulin wrote: Errm, unless you're using an unpatched, vanilla lily.scm from git you won't see it because the handler will already be defined in ergonomic-simple-format. It doesn't make any difference for me. profile-property-access.ly uses (ice-9 format) unless it's rebound locally (as I did above for testing). The only case where it was already using ergonomic-simple-format arose from the removal of module-public-interface (which you've restored in the latest patch.) To reiterate: with your patch applied, if I redefine format to use your emended ergonomic-simple-format, the exception handler doesn't work, and profile-property-access.ly fails in the same way as Patrick originally reported. It works with the changes I suggested. http://www.codereview.appspot.com/1160044/show ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: T1055: Avoid using deprecated %module-public-interface in guile initialisation. (issue1160044)
Hi Neil, On 09/08/10 22:34, n.putt...@gmail.com wrote: On 2010/08/09 20:01:10, Ian Hulin wrote: Presumably this means make a parallel change to Documentation/snippets/clip-systems.ly? OK. snippets/new/clip-systems.ly then run makelsr.py to update snippets/clip-systems.ly: scripts/auxiliar/makelsr.py OK, you've convinced me. Changing the reg test is just nasty. Valid point, but I'd rather do the work for clip-region as a separate tracker item. Raise the tracker and I'll start work on it as soon as this one's finished. Why would you want to add something to a file, only to remove it soon after? If we agree it's better from the user's perspective not to require (use-modules (scm clip-region)) in a .ly file, then it doesn't make sense to defer the change. Well, it seemed like a distinct and separate task and like it was getting this patch 'off-topic'. It was an answer from Han-Wen about how we'd got into using %module-public-interface in the first place: "I think %public-interface hack is to force all of the definitions including future ones to be public; the code that executes the assignments just does scm_module_define (mod, sym, val); -- lily-lexer.cc without doing anything to export sym." Sure, but `mod' here is created by ly_make_module, which now uses module-export-all!, so all defines will automatically be public. Because it doesn't work. I meant: leave it in lily.scm, even if you still want to use (use-modules (scm clip-region)) in clip-systems.ly. OK. Yes, If we don't have this handler, scm/define-grob-properties barfs during initialization. Procedure simple-format only handles a subset of format directives, and throws 'format if it sees one it can't handle. It kills the build and the regtests if we don't handle it here. The other option is to change define-grob-properties to use fancy-format (a.k.a the definition from module (ice-9 format)). I don't get any regtest failure without this code. That's because I was talking rubbish and trying to answer your review in a hurry. I was confusing the crash with profile-property-access.ly which I'd compiled separately as a test . There's no format call inside define-grob-properties.scm, and as I said earlier, the handler doesn't work since there's no exception thrown specifically for `format' (+ Patrick's comments and the incorrect args to the handler). Try adding this to profile-property-access.ly: #(define format ergonomic-simple-format) You'll see the exception handler doesn't catch this. If you change the code, it gets caught: Errm, unless you're using an unpatched, vanilla lily.scm from git you won't see it because the handler will already be defined in ergonomic-simple-format. Using the code as in the my patch certainly stopped profile-property-access.ly from barfing here. I'll poke around further with this. (define (simple-format-handler dest . rest) (if (string? dest) (apply fancy-format (cons #f (cons dest rest))) (apply fancy-format (cons dest rest (define-public (ergonomic-simple-format dest . rest) "Like ice-9 format, but without the memory consumption." (catch #t (lambda () (if (string? dest) (apply simple-format (cons #f (cons dest rest))) (apply simple-format (cons dest rest (lambda (key . args) (apply simple-format-handler (cons dest rest) See above. http://www.codereview.appspot.com/1160044/show Cheers, Ian ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: doc-addition for -o / --output
On Tue, Aug 10, 2010 at 04:49:24PM +0100, Trevor Daniels wrote: > > Eluze wrote Tuesday, August 10, 2010 2:54 PM > >> if you specify a folder name as output option the output will be >> directed to >> that folder and the name of the file is preserved > I don't know, but I'm reluctant to cement this change > into the docs until someone confirms it is working as > intended. It was added deliberately, I think sometime in 2007 or 2008. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: doc-addition for -o / --output
Eluze wrote Tuesday, August 10, 2010 2:54 PM happenstance or intention? I don't know, but I'm reluctant to cement this change into the docs until someone confirms it is working as intended. Looks useful though. Thanks for pointing it out. if you specify a folder name as output option the output will be directed to that folder and the name of the file is preserved so i suggest the following change/addition - or similar - in the application usage manual: 1.2 Command-line usage Command line options for lilypond -o,--output=FILE or FOLDER Set the default output file to FILE. The appropriate suffix will be added (e.g. .pdf for pdf) if a folder of that name exists, output will be directed to FOLDER (keeping the file name) Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
doc-addition for -o / --output
happenstance or intention? if you specify a folder name as output option the output will be directed to that folder and the name of the file is preserved so i suggest the following change/addition - or similar - in the application usage manual: 1.2 Command-line usage Command line options for lilypond -o,--output=FILE or FOLDER Set the default output file to FILE. The appropriate suffix will be added (e.g. .pdf for pdf) if a folder of that name exists, output will be directed to FOLDER (keeping the file name) thanks! -- View this message in context: http://old.nabble.com/doc-addition-for--o-output-tp29398032p29398032.html Sent from the Gnu - Lilypond - Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Subdivide as beamExceptions?
On 8/10/10 2:52 AM, "Xavier Scheuer" wrote: > Hi Carl! > > First of all thank you for your formidable work on the new autobeaming, > it seems really powerful and the ideas to configure it more "logical" > (although I must confess, I'm still not totally used to all these > changes)! > > I would just like to know if it is currently possible to define rules > for subdivided beams? I think I heard about this in a discussion but I > was not able to find it again. > > What I would like to do is (or seems, at least from a user point of > view) quite easy. > I'm really satisfied with current 4/4 beaming rules but I'd like to > add one more "default" rule: I want 32th to be subdivided by 8th. > So the equivalent of > > % Set beam sub-group length to an eighth note > \set subdivideBeams = ##t > \set baseMoment = #(ly:make-moment 1 8) > \set beatStructure = #'(2 2 2 2) > c32[ c c c c c c c] > > but "automatically", as default rule (i.e. within beamExceptions?). > > Because I do not want 16th (and longer notes) to be also subdivided by > 8th, which is the case if I use the code above. > > > I have seen in "scm/time-signature-settings.scm" the line: > > (subdivide . grouping-rules) (not yet implemented, reserved for future use) > > Is this what I'm looking for? And does this mean it is not implemented > yet, but will be possible in a not-so-long-term future? ;-) Yes, this is true. We currently do not have the capability of setting multiple levels of subdivide; we only subdivide on the beat. The exact mechanism of getting multiple levels of subdivision is not yet finalized. We may use a subdivide grouping rule, or we may just use a nested beatStructure. As far as a time for its implementation, I'm not sure how long it will be. I've looked into it, but I haven't yet got the architecture firmly in mind for making it happen. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Subdivide as beamExceptions?
Hi Carl! First of all thank you for your formidable work on the new autobeaming, it seems really powerful and the ideas to configure it more "logical" (although I must confess, I'm still not totally used to all these changes)! I would just like to know if it is currently possible to define rules for subdivided beams? I think I heard about this in a discussion but I was not able to find it again. What I would like to do is (or seems, at least from a user point of view) quite easy. I'm really satisfied with current 4/4 beaming rules but I'd like to add one more "default" rule: I want 32th to be subdivided by 8th. So the equivalent of % Set beam sub-group length to an eighth note \set subdivideBeams = ##t \set baseMoment = #(ly:make-moment 1 8) \set beatStructure = #'(2 2 2 2) c32[ c c c c c c c] but "automatically", as default rule (i.e. within beamExceptions?). Because I do not want 16th (and longer notes) to be also subdivided by 8th, which is the case if I use the code above. I have seen in "scm/time-signature-settings.scm" the line: (subdivide . grouping-rules) (not yet implemented, reserved for future use) Is this what I'm looking for? And does this mean it is not implemented yet, but will be possible in a not-so-long-term future? ;-) Cheers, Xavier -- Xavier Scheuer ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
