Re: Tablature: proper support for tie/slur- and tie/glissando-constellations (issue2191042)
Am 31.10.2010 00:07, schrieb Neil Puttock: On 30 October 2010 22:40, Marc Hohlm...@hohlart.de wrote: File /home/marc/git/lilypond/python/out/book_snippets.py, line 561, in compose_ly if self.global_options.safe_mode: AttributeError: Values instance has no attribute 'safe_mode' I don't think this has anything to do with your patch. It looks like lilypond-book is out of date (the safe_mode option was only added a week or two ago). Oops, sorry. I do a git pull nearly every day, but probably I rebased the branch containing the tie stuff not very recently ... Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tablature: proper support for tie/slur- and tie/glissando-constellations (issue2191042)
On Sun, Oct 31, 2010 at 4:33 AM, carl.d.soren...@gmail.com wrote: I've put a new patch up on Rietveld, with the Scheme engraver moved to a C++ engraver to avoid the challenges with documentation. Thanks Carl! In the meantime, I've opened http://code.google.com/p/lilypond/issues/detail?id=1375 as a brainstorming session for Scheme engravers. Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tablature: proper support for tie/slur- and tie/glissando-constellations (issue2191042)
Am 29.10.2010 11:05, schrieb Neil Puttock: On 28 October 2010 23:55, Carl Sorensenc_soren...@byu.edu wrote: Well, as far as I can see, Scheme engravers are really engravers, so they ought to be documented in the IR along with the C++ engravers, not in an appendix of the NR along with Scheme functions. Although the approach you suggest is better than having nothing at all. I haven't tested Marc's latest patch yet (and I'm sorry this issue didn't cross my mind when I originally suggested using a Scheme engraver), but I don't think Valentin's approach is possible without also changing the doc infrastructure for C++ engravers: I think you'll find \consist-ing a Scheme engraver in engraver-init.ly will cause `make doc' to fail. Running `make doc', I get Compiling /home/marc/git/lilypond/input/regression/out-www/AAA-intro-regression.texi... /home/marc/git/lilypond/input/regression/out-www/AAA-intro-regression.texi is up to date. /home/marc/git/lilypond/scripts/build/out/extract_texi_filenames -I ./out-www -I . -o /home/marc/git/lilypond/./out-www/xref-maps out-www/AAA-intro-regression.texi extract_texi_filenames.py: Processing out-www/AAA-intro-regression.texi writing: /home/marc/git/lilypond/./out-www/xref-maps/AAA-intro-regression.xref-map Writing snippets...Traceback (most recent call last): File ../../scripts/lilypond-book.py, line 679, in module main () File ../../scripts/lilypond-book.py, line 661, in main chunks = do_file (files[0]) File ../../scripts/lilypond-book.py, line 555, in do_file do_process_cmd (chunks, input_fullname, global_options) File ../../scripts/lilypond-book.py, line 416, in do_process_cmd snippet.write_ly() File /home/marc/git/lilypond/python/out/book_snippets.py, line 612, in write_ly if self.relevant_contents (existing) != self.relevant_contents (self.full_ly ()): File /home/marc/git/lilypond/python/out/book_snippets.py, line 378, in full_ly return self.compose_ly (s) File /home/marc/git/lilypond/python/out/book_snippets.py, line 561, in compose_ly if self.global_options.safe_mode: AttributeError: Values instance has no attribute 'safe_mode' make[3]: *** [out-www/collated-files.texi] Error 1 rm out-www/weblinks.itexi make[3]: Leaving directory `/home/marc/git/lilypond/input/regression' make[2]: *** [WWW-1] Error 2 make[2]: Leaving directory `/home/marc/git/lilypond/input' make[1]: *** [WWW-1] Error 2 make[1]: Leaving directory `/home/marc/git/lilypond' make: *** [doc-stage-1] Fehler 2 What is to be done? Is there a clean solution to enable scheme engravers in engraver-init.ly? I am not able to rewrite the engraver in c++. Marc Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tablature: proper support for tie/slur- and tie/glissando-constellations (issue2191042)
On 30 October 2010 22:40, Marc Hohl m...@hohlart.de wrote:
File /home/marc/git/lilypond/python/out/book_snippets.py, line 561, in
compose_ly
if self.global_options.safe_mode:
AttributeError: Values instance has no attribute 'safe_mode'
I don't think this has anything to do with your patch. It looks like
lilypond-book is out of date (the safe_mode option was only added a
week or two ago).
What is to be done? Is there a clean solution to enable scheme engravers in
engraver-init.ly?
Scheme engravers need to link up with the existing code which makes
all the translator documentation accessible from scheme
(translator_description () and ly:translator-description).
This is what I get from a clean build (I can't even get to the doc build stage):
Writing internals.texi...Backtrace:
In
/home/neil/lilypond/out/share/lilypond/current/scm/documentation-generate.scm:
159: 3* [list #texi-node 2ba01bc1ffa0 ...
161: 4* [translation-doc-node]
In /home/neil/lilypond/out/share/lilypond/current/scm/document-translation.scm:
276: 5 [make-instance #class texi-node 2ba01c1ae900 #:name ... ...
280: 6* [list ...
281: 7* [all-contexts-doc]
239: 8 (let* (# # #) (make texi-node # Contexts ...))
245: 9 [make-instance #class texi-node 2ba01c1ae900 #:name ... ...
249: 10* [map #procedure context-doc (context-desc) (# # # # ...)]
In unknown file:
?: 11* [context-doc (# # # # ...)]
In /home/neil/lilypond/out/share/lilypond/current/scm/document-translation.scm:
162: 12* (let* (# # # # ...) (make texi-node # name ...))
169: 13* [context-grobs (# # # # ...)]
228: 14 (let* ((group #) (consists #) (grobs #)) grobs)
234: 15* [apply #primitive-procedure append ...
235: 16* [map #procedure engraver-grobs # #]
In unknown file:
?: 17* [engraver-grobs {#procedure Tab_tie_follow_engraver (context)}]
In /home/neil/lilypond/out/share/lilypond/current/scm/document-translation.scm:
220: 18* (let* ((eg (if # # ...))) (if (eq? eg #f) (quote ()) ...))
223: 19 (if (eq? eg #f) (quote ()) ...)
225: 20 [map #primitive-procedure symbol-string ...
225: 21* [ly:assoc-get grobs-created ...
225: 22* [ly:translator-description {#procedure Tab_tie_follow_engraver #}]
/home/neil/lilypond/out/share/lilypond/current/scm/document-translation.scm:225:55:
In procedure ly:translator-description in expression
(ly:translator-description eg):
/home/neil/lilypond/out/share/lilypond/current/scm/document-translation.scm:225:55:
Wrong type argument in position 1 (expecting Translator): #procedure
Tab_tie_follow_engraver (context)
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tablature: proper support for tie/slur- and tie/glissando-constellations (issue2191042)
On 10/30/10 3:40 PM, Marc Hohl m...@hohlart.de wrote: Am 29.10.2010 11:05, schrieb Neil Puttock: On 28 October 2010 23:55, Carl Sorensenc_soren...@byu.edu wrote: Well, as far as I can see, Scheme engravers are really engravers, so they ought to be documented in the IR along with the C++ engravers, not in an appendix of the NR along with Scheme functions. Although the approach you suggest is better than having nothing at all. I haven't tested Marc's latest patch yet (and I'm sorry this issue didn't cross my mind when I originally suggested using a Scheme engraver), but I don't think Valentin's approach is possible without also changing the doc infrastructure for C++ engravers: I think you'll find \consist-ing a Scheme engraver in engraver-init.ly will cause `make doc' to fail. What is to be done? Is there a clean solution to enable scheme engravers in engraver-init.ly? I am not able to rewrite the engraver in c++. In order to solve this problem for Marc, I'm working on writing an engraver in c++. It's my first engraver using acknowledgers instead of listeners, so it's providing some good learning for me. Marc, I hope this will be helpful for you. I'll post a patch when I get a chance. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tablature: proper support for tie/slur- and tie/glissando-constellations (issue2191042)
I've put a new patch up on Rietveld, with the Scheme engraver moved to a C++ engraver to avoid the challenges with documentation. http://codereview.appspot.com/2723043 Thanks, Carl http://codereview.appspot.com/2191042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tablature: proper support for tie/slur- and tie/glissando-constellations (issue2191042)
On 28 October 2010 23:55, Carl Sorensen c_soren...@byu.edu wrote: Well, as far as I can see, Scheme engravers are really engravers, so they ought to be documented in the IR along with the C++ engravers, not in an appendix of the NR along with Scheme functions. Although the approach you suggest is better than having nothing at all. I haven't tested Marc's latest patch yet (and I'm sorry this issue didn't cross my mind when I originally suggested using a Scheme engraver), but I don't think Valentin's approach is possible without also changing the doc infrastructure for C++ engravers: I think you'll find \consist-ing a Scheme engraver in engraver-init.ly will cause `make doc' to fail. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tablature: proper support for tie/slur- and tie/glissando-constellations (issue2191042)
Am 28.10.2010 14:53, schrieb carl.d.soren...@gmail.com: LGTM. However, I'm a bit nervous about putting bends as well into the Tab_tie_follow_engraver. Not that the engraver won't work, but that the Tab_tie_follow_engraver won't be part of the documentation. Currently, I view Scheme engravers as a way for users (and snippets) to add engraver functionality, but not as an optimal way to add core functionality. I'm not asking you to change your code, but I'm trying to send up a caution flag to see what others might say about it. Thanks, Carl http://codereview.appspot.com/2191042/diff/17001/input/regression/tablature-tie-slur-glissando.ly File input/regression/tablature-tie-slur-glissando.ly (right): http://codereview.appspot.com/2191042/diff/17001/input/regression/tablature-tie-slur-glissando.ly#newcode1 input/regression/tablature-tie-slur-glissando.ly:1: \version 2.13.37 2.13.38 Done. http://codereview.appspot.com/2191042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tablature: proper support for tie/slur- and tie/glissando-constellations (issue2191042)
LGTM. However, I'm a bit nervous about putting bends as well into the Tab_tie_follow_engraver. Not that the engraver won't work, but that the Tab_tie_follow_engraver won't be part of the documentation. Currently, I view Scheme engravers as a way for users (and snippets) to add engraver functionality, but not as an optimal way to add core functionality. I'm not asking you to change your code, but I'm trying to send up a caution flag to see what others might say about it. Thanks, Carl http://codereview.appspot.com/2191042/diff/17001/input/regression/tablature-tie-slur-glissando.ly File input/regression/tablature-tie-slur-glissando.ly (right): http://codereview.appspot.com/2191042/diff/17001/input/regression/tablature-tie-slur-glissando.ly#newcode1 input/regression/tablature-tie-slur-glissando.ly:1: \version 2.13.37 2.13.38 http://codereview.appspot.com/2191042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tablature: proper support for tie/slur- and tie/glissando-constellations (issue2191042)
I've not reviewed the code but I share Carl's concern about scheme engravers if there is no way of documenting them in the IR. If the grobs have any user-servicable properties they must be properly documented. Trevor http://codereview.appspot.com/2191042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tablature: proper support for tie/slur- and tie/glissando-constellations (issue2191042)
Am 28.10.2010 20:34, schrieb tdanielsmu...@googlemail.com: I've not reviewed the code but I share Carl's concern about scheme engravers if there is no way of documenting them in the IR. If the grobs have any user-servicable properties they must be properly documented. Ok, I see the point, but in this case, there are only internal properties involved. More generally, I suspect more scheme engravers to come, so a proper way of getting them well documented would be fine. Marc Trevor http://codereview.appspot.com/2191042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tablature: proper support for tie/slur- and tie/glissando-constellations (issue2191042)
Am 28.10.2010 14:53, schrieb carl.d.soren...@gmail.com: LGTM. However, I'm a bit nervous about putting bends as well into the Tab_tie_follow_engraver. Not that the engraver won't work, but that the Tab_tie_follow_engraver won't be part of the documentation. I think you misunderstood the TODO. I did not want to propose the bend engraver to be part of the Tab_tie_follow_engraver, but a tie followed by a bend should be handled exactly as a tie/slur or a tie/glissando combination. Currently, I view Scheme engravers as a way for users (and snippets) to add engraver functionality, but not as an optimal way to add core functionality. I understand your argument, but I think that it would be better to include scheme engravers into the docs before recoding the Tab_tie_follow_engraver in c++. At least, I cannot cope with this. Aside from that, I think that more extensions on the scheme side (including engravers) are about to come. Marc I'm not asking you to change your code, but I'm trying to send up a caution flag to see what others might say about it. Thanks, Carl http://codereview.appspot.com/2191042/diff/17001/input/regression/tablature-tie-slur-glissando.ly File input/regression/tablature-tie-slur-glissando.ly (right): http://codereview.appspot.com/2191042/diff/17001/input/regression/tablature-tie-slur-glissando.ly#newcode1 input/regression/tablature-tie-slur-glissando.ly:1: \version 2.13.37 2.13.38 http://codereview.appspot.com/2191042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tablature: proper support for tie/slur- and tie/glissando-constellations (issue2191042)
On 10/28/10 1:54 PM, Marc Hohl m...@hohlart.de wrote: Am 28.10.2010 14:53, schrieb carl.d.soren...@gmail.com: Currently, I view Scheme engravers as a way for users (and snippets) to add engraver functionality, but not as an optimal way to add core functionality. I understand your argument, but I think that it would be better to include scheme engravers into the docs before recoding the Tab_tie_follow_engraver in c++. At least, I cannot cope with this. Aside from that, I think that more extensions on the scheme side (including engravers) are about to come. I would *love* to have a way to document Scheme engravers such that we could include them in the docs, but at present I have no knowledge of how to do so. Can anybody shed any light on this? Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tablature: proper support for tie/slur- and tie/glissando-constellations (issue2191042)
On Fri, Oct 29, 2010 at 12:15 AM, Carl Sorensen c_soren...@byu.edu wrote: I would *love* to have a way to document Scheme engravers such that we could include them in the docs, but at present I have no knowledge of how to do so. Can anybody shed any light on this? How about basic regrouping all engravers-related Scheme definitions in a `define-scheme-engravers.scm' file, and then document it just like music-functions.scm and define-markup-commands.scm, using (_ localized doc strings). Or is that too pedestrian? Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tablature: proper support for tie/slur- and tie/glissando-constellations (issue2191042)
On 10/28/10 4:50 PM, Valentin Villenave valen...@villenave.net wrote: On Fri, Oct 29, 2010 at 12:15 AM, Carl Sorensen c_soren...@byu.edu wrote: I would *love* to have a way to document Scheme engravers such that we could include them in the docs, but at present I have no knowledge of how to do so. Can anybody shed any light on this? How about basic regrouping all engravers-related Scheme definitions in a `define-scheme-engravers.scm' file, and then document it just like music-functions.scm and define-markup-commands.scm, using (_ localized doc strings). Or is that too pedestrian? Well, as far as I can see, Scheme engravers are really engravers, so they ought to be documented in the IR along with the C++ engravers, not in an appendix of the NR along with Scheme functions. Although the approach you suggest is better than having nothing at all. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tablature: proper support for tie/slur- and tie/glissando-constellations (issue2191042)
Am 20.10.2010 11:12, schrieb Marc Hohl: Am 18.09.2010 22:21, schrieb n.putt...@gmail.com: [...] I think the only sane method would be to use a scheme engraver, since you could acknowledge interesting grobs and make typesetting decisions for the TabNoteHead based on the grobs present at a particular timestep. Done. This doesn't belong in 'details since it's set beyond the user's control: it only makes sense as an internal property, so should be defined separately Done (I hope I did it right?) Looks OK. Just needs a few minor changes: -) It's not user serviceable so should go in `all-internal-grob-properties'. Done. -) As a flag which is usually #f, it doesn't need to be set in define-grobs.scm: you can set the default when reading the property instead. Done. -) It needs adding to an interface to prevent error messages popping up. Done. Regards, Marc Anyone? I know, most developers are extremely busy right now. This particular feature isn't listed on the tracker, but since 2.14 will provide a major change concerning the tablature handling, I think it is important that tablature should work properly out of the box. Sorry for being too pushy, I know that there are more important things than tablature around for now ... Regards, Marc http://codereview.appspot.com/2191042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tablature: proper support for tie/slur- and tie/glissando-constellations (issue2191042)
On Wed, Oct 27, 2010 at 11:00 AM, Marc Hohl m...@hohlart.de wrote: I know, most developers are extremely busy right now. This particular feature isn't listed on the tracker, but since 2.14 will provide a major change concerning the tablature handling, I think it is important that tablature should work properly out of the box. I think we wouldn't want 2.14 to be released without your patch. I have opened a tracker page about it: http://code.google.com/p/lilypond/issues/detail?id=1366 I haven't made this a Critical priority, but it might be appropriate to raise the priority. I'm not sure; hopefully this will get reviewed and approved even with the default priority. Sorry for being too pushy, I know that there are more important things than tablature around for now ... Sometimes it's ok to be pushy -- and I'm way ahead of you in this regard :-) Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tablature: proper support for tie/slur- and tie/glissando-constellations (issue2191042)
Am 27.10.2010 12:14, schrieb Valentin Villenave: On Wed, Oct 27, 2010 at 11:00 AM, Marc Hohlm...@hohlart.de wrote: I know, most developers are extremely busy right now. This particular feature isn't listed on the tracker, but since 2.14 will provide a major change concerning the tablature handling, I think it is important that tablature should work properly out of the box. I think we wouldn't want 2.14 to be released without your patch. I have opened a tracker page about it: http://code.google.com/p/lilypond/issues/detail?id=1366 Thanks, Valentin! I haven't made this a Critical priority, but it might be appropriate to raise the priority. I'm not sure; hopefully this will get reviewed and approved even with the default priority. Sorry for being too pushy, I know that there are more important things than tablature around for now ... Sometimes it's ok to be pushy -- and I'm way ahead of you in this regard :-) :-) Best regards, Marc Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tablature: proper support for tie/slur- and tie/glissando-constellations (issue2191042)
Am 18.09.2010 22:21, schrieb n.putt...@gmail.com: [...] I think the only sane method would be to use a scheme engraver, since you could acknowledge interesting grobs and make typesetting decisions for the TabNoteHead based on the grobs present at a particular timestep. Done. This doesn't belong in 'details since it's set beyond the user's control: it only makes sense as an internal property, so should be defined separately Done (I hope I did it right?) Looks OK. Just needs a few minor changes: -) It's not user serviceable so should go in `all-internal-grob-properties'. Done. -) As a flag which is usually #f, it doesn't need to be set in define-grobs.scm: you can set the default when reading the property instead. Done. -) It needs adding to an interface to prevent error messages popping up. Done. Regards, Marc http://codereview.appspot.com/2191042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tablature: proper support for tie/slur- and tie/glissando-constellations (issue2191042)
n.putt...@gmail.com schrieb: On 2010/09/17 07:01:40, marc wrote: TO be honest, I don't understand what you mean here. Add #(ly:set-option 'check-internal-types) to your snippet below. Two of the bounds aren't TabNoteHeads; these are the left bounds of the ties following a break. Ah, ok, now I see. Thanks! Try running `make check' to see what I mean. ;) Here neither - I see I made a mistake, because `make check' fails, but the output doesn't help a lot. Is this *before* or *after* you changed the version number in the regtest? Any regtest with a version number later than the current version will break `make check'. Um, I don't know, probably before. But even if I do 'make check' now, I got /home/marc/git/lilypond/scripts/build/out/output-distance --create-images --output-dir /home/marc/git/lilypond/out/test-results input/regression/out-test-baseline input/regression/out-test/ Traceback (most recent call last): File /home/marc/git/lilypond/scripts/build/out/output-distance, line 1261, in module main() File /home/marc/git/lilypond/scripts/build/out/output-distance, line 1258, in main compare_trees (args[0], args[1], name, options.threshold) File /home/marc/git/lilypond/scripts/build/out/output-distance, line 969, in compare_trees data.compare_trees (dir1, dir2) File /home/marc/git/lilypond/scripts/build/out/output-distance, line 812, in compare_trees (root, dirs, files) = os.walk (dir1).next () StopIteration make: *** [local-check] Fehler 1 I don't know whether this is due to my erroneous file, but it is not very helpful to me... [...] I think the only sane method would be to use a scheme engraver, since you could acknowledge interesting grobs and make typesetting decisions for the TabNoteHead based on the grobs present at a particular timestep. D'oh - I failed already once trying my luck with engravers, but I'll give it a try. Could you please sketch the functionality a bit in more detail? Do I still need the 'tied-to' bit, or is the engraver responsible for the full appearance of the tab note head? Thanks, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tablature: proper support for tie/slur- and tie/glissando-constellations (issue2191042)
On 2010/09/17 07:01:40, marc wrote: TO be honest, I don't understand what you mean here. Add #(ly:set-option 'check-internal-types) to your snippet below. Two of the bounds aren't TabNoteHeads; these are the left bounds of the ties following a break. Try running `make check' to see what I mean. ;) Here neither - I see I made a mistake, because `make check' fails, but the output doesn't help a lot. Is this *before* or *after* you changed the version number in the regtest? Any regtest with a version number later than the current version will break `make check'. formatting Done. Looking at various files in input/regression, I see there are various formatting styles. What about adding a file called template.ly or something similar, which can be copied and edited to avoid formatting issues? We could add a README similar to the one in snippets/new. Eventually we should have a style guide for .ly snippets which deals with correct formatting. This is a bit of a misnomer, since it indirectly makes some heads visible later. It would be better if you could avoid hiding such notes rather than hiding them, then making them visible. How can I avoid making heads invisible? The tie routine doesn't know whether a slur or glissando follows or not, so I have to make it invisible to be on the safe side, add a mark to this note that it is tied to another one and read this information by the slur/glissando routine. Or is it just the name? Well, I could use a more self-explanatory name, but since it is just a shortcut, I don't know whether it's worth the effort... I think the only sane method would be to use a scheme engraver, since you could acknowledge interesting grobs and make typesetting decisions for the TabNoteHead based on the grobs present at a particular timestep. This doesn't belong in 'details since it's set beyond the user's control: it only makes sense as an internal property, so should be defined separately Done (I hope I did it right?) Looks OK. Just needs a few minor changes: -) It's not user serviceable so should go in `all-internal-grob-properties'. -) As a flag which is usually #f, it doesn't need to be set in define-grobs.scm: you can set the default when reading the property instead. -) It needs adding to an interface to prevent error messages popping up. this won't happen for tied notes after a break unless you explicitly set 'tied-to outside `hide-tab-note-head' I don't know what you mean - I tried to break everything ;-) and it seems to work: The padding tweak isn't applied to the glissando in bar five since the left-bound for the tie isn't a TabNoteHead. Cheers, Neil http://codereview.appspot.com/2191042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tablature: proper support for tie/slur- and tie/glissando-constellations (issue2191042)
On Sat, Sep 18, 2010 at 9:21 PM, n.putt...@gmail.com wrote: On 2010/09/17 07:01:40, marc wrote: Done. Looking at various files in input/regression, I see there are various formatting styles. What about adding a file called template.ly or something similar, which can be copied and edited to avoid formatting issues? We could add a README similar to the one in snippets/new. Eventually we should have a style guide for .ly snippets which deals with correct formatting. Planned for the tail end of GLISS. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tablature: proper support for tie/slur- and tie/glissando-constellations (issue2191042)
carl.d.soren...@gmail.com schrieb: Looks good to me. Just a comment on the name of the new property to be added to details. Thanks, Carl Hello Carl, http://codereview.appspot.com/2191042/diff/1/scm/define-grobs.scm File scm/define-grobs.scm (right): http://codereview.appspot.com/2191042/diff/1/scm/define-grobs.scm#newcode1979 scm/define-grobs.scm:1979: (tied-to . #f))) tied-from might be a better name than tied-to, since it's the property of the left-hand note that we're adjusting, rather than the property of the right hand note. Just for clarification, since I am not a native speaker: Consider c'4 ~ c'4 ( d'2 ). I used tied-to, because this value is set while evaluating the tie, so from this point of view, the right note (i.e. the second c') is tied to the left c'. This information is then passed to the slur/glissando routine. Am I wrong here? Is tied-to misleading? And maybe something like span-start or spanner-start would be even better, since I'd guess we want the same behavior to apply for slurs, glissandos, and bends, all of which are spanners. And starting the spanner at the note-head means we want to display the number. AFAIK, the only situation in which this may occur is when a tie is followed by a spanner like slur, glissando, or bend. When a tie follows another spanner, lilypond already works as expected. But I thought about alternatives like tie-terminate or terminate-tie or tie-end before, but tied-to felt just right. Marc http://codereview.appspot.com/2191042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
