Re: Remove arabic.ly from common note name languages. (issue2755041)
On 2010/10/26 22:13:26, Valentin Villenave wrote: Since I have both of your approvals, I am pushing the patch now. Thanks! I have reverted this commit. You put something up for review for 83 minutes, you don't wait for approval from the Documentation Editor -- and you *know* that I want to review doc patches on this topic. Are you *trying* to sabotage the 2.14 release process?! You know why we didn't have 2.14 out in 2009? It's because we had a whole bunch of commits which didn't receive proper attention, regtests were broken and nobody noticed, and generally we accumulated a huge bug debt that we're now almost finished paying off. Calm the bloody mao down. Doc patches _do_ get approved. James Lowe has been steadily cleaning up broken documentation; his patches sometimes take a week and 3-4 versions (notwithstanding when I push one by accident), but he gets stuff done. Pushing a half-baked patch after only waiting 83 minutes for comments is *not* being fair to him and all the hard work he's been doing. I'm sorry I was asleep when you sent the patch and didn't comment earlier, but we cannot rely on developers being awake and working on lilypond all the time. For your next patch, please wait at least 24 hours before pushing, regardless of how positive the reviews are. http://codereview.appspot.com/2755041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganize language files and add a new \language command. (issue2699041)
Looks mostly good.
http://codereview.appspot.com/2699041/diff/24001/Documentation/changes.tely
File Documentation/changes.tely (right):
http://codereview.appspot.com/2699041/diff/24001/Documentation/changes.tely#newcode74
Documentation/changes.tely:74: be used in safe mode). The old syntax is
still supported,
That sentence has a clause: clause, clause (clause). This seems a bit
convoluted. How about:
Note names can be selected with a new @code{\language italiano}
command, which can be used in safe mode. The old syntax is still
supported for now, but will be deprecated in the future.
http://codereview.appspot.com/2699041/diff/24001/ly/catalan.ly
File ly/catalan.ly (right):
http://codereview.appspot.com/2699041/diff/24001/ly/catalan.ly#newcode21
ly/catalan.ly:21: \version 2.14.0
Won't this break compiling? I'd expect lilypond to quit with a file
too new; update your version of lilypond message.
Make it 2.13.37.
http://codereview.appspot.com/2699041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: non-technical help for spacing issues
On Tue, Oct 26, 2010 at 01:23:01PM -0700, Keith E OHara wrote: On Tue, 26 Oct 2010 05:12:16 -0700, lilypond-devel-requ...@gnu.org wrote: On Tue, 26 Oct 2010 00:47:01 -0700, Graham wrote: This is directed at people saying I can't do anything to help... You sent this to -devel; did you intend -user ? No; I know from experience that this nets a few well-intentioned but clueless users. Sometimes they turn out to be great contributors (and even senior developers), but from experience only about 30% of them result in a net plus to lilypond development. I wanted developers (some of whom have said I can't do anything to help with the current Critical issues), and highly interested, skilled users. Like yourself. :) See below for more. I have a couple such overrides already from trying out the first alpha. In the next two evenings, I intend to try 2.13.37 on a few piano pieces, and one full-size orchestral score plus parts, and something string-quartet size from mutopia. I can post here any spacing overrides that seem wise, with tiny cropped images showing why I think they are wise, by Friday. That sounds ideal! However, I have no familiarity with how vocal music is supposed to look, and I tend to avoid tweaks myself. Graham's request seems quite easy for a few people to cooperate on, if we test the union of the overrides that we collectively need. That would also be great! Would you be willing to organize such an effort, particularly including lilypond-user? I don't want to send an email there, because then people (quite reasonably) ask me about it, and I just don't have the time for that -- it's not yet 9am on Wednesday, and I've already used up 7 hours of my allowable 10 hours of lilypond time for this week. But if you were willing to organize the effort, help well-intentioned users learn how to write tweaks, make apologies for bugs or missing documentation, etc., this would definitely be a great help towards 2.14! :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR 4.4.1: Rewrite. (issue2642043)
http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (right):
http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely#newcode1624
Documentation/notation/spacing.itely:1624: size) will always reset all
its default key-values.
On 2010/10/26 22:28:16, joeneeman wrote:
Everything from the subsubheading until here applies to
any grob property with an alist (eg. Beam 'details, Slur
'details, NonMusicalPaperColumn
'line-break-system-details). It may be more appropriate
(long-term) to put this detailed discussion elsewhere.
Good idea. Can anyone think of a good place for this?
http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely#newcode1662
Documentation/notation/spacing.itely:1662:
@code{after-last-staff-spacing}).
On 2010/10/26 22:28:16, joeneeman wrote:
I find this wording a little confusing, since \override
VerticalAxisGroup #'next-staff-spacing ... has a quite
different effect from \override StaffGrouper #'...
That is, overriding next-staff-spacing does not override
any StaffGrouper properties for the usual use of
override in lilypond.
I see. What's a better way to word it?
http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely#newcode1679
Documentation/notation/spacing.itely:1679: either side. Adjacent
staff-like contexts should have
On 2010/10/26 22:28:16, joeneeman wrote:
I'm not sure how precise you want to be here, but this
isn't quite true: if the upper staff, for example, has a
very low note then a lyrics line with CENTER affinity
might be placed closer to the lower staff.
Also, by equidistant between the ... staves, you mean
equidistant between the refpoints of the staves, right?
That's what I meant, but based on your previous statement, I
assume even that would be incorrect. In fact, this is
clearly wrong, since the refpoints of the staves are the
midlines, right? So is it centered between the skylines?
http://codereview.appspot.com/2642043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: T1247 - Conditionally do (use-modules (ice-9 curried-definitions)) if running with Guile V2, (issue2219044)
New patch-set uploads (well two actually, but please review the latest). Code in display-lily.scm to support Guile V2 now tested on Guile 1.8.7 system. Cheers, Ian http://codereview.appspot.com/2219044/diff/15001/scm/lily.scm File scm/lily.scm (right): http://codereview.appspot.com/2219044/diff/15001/scm/lily.scm#newcode227 scm/lily.scm:227: (use-modules (ice-9 curried-definitions On 2010/10/21 00:12:21, Patrick McCarty wrote: In this section, the parenthesis nesting needs some adjustment. It should be ((guile-v2) (if (ly:get-option 'verbose) (ly:message (_ Using (ice-9 curried-definitions) module\n))) (use-modules (ice-9 curried-definitions))) Done. http://codereview.appspot.com/2219044/diff/15001/scm/lily.scm#newcode231 scm/lily.scm:231: (_ Guile 1.8\n) On 2010/10/20 21:58:07, Patrick McCarty wrote: Okay, I can live with this. :) Ta http://codereview.appspot.com/2219044/diff/15001/scm/lily.scm#newcode271 scm/lily.scm:271: (debug-enable 'debug) On 2010/10/20 21:58:07, Patrick McCarty wrote: On 2010/10/20 21:42:06, ianhulin44 wrote: This causes a deprecation warning from Guile V1.9.13 with $ declare -x GUILE_WARN_DEPRECATED=detailed [/home/ian/lilypond/out/share/lilypond/current/scm/lily.scm] `(debug-enable 'debug)' is obsolete and has no effect. Remove it from your code. Go ahead. There is another instance of `(debug-enable 'debug)' earlier in this file, so you can remove that too. Done. http://codereview.appspot.com/2219044/diff/15001/scm/lily.scm#newcode332 scm/lily.scm:332: (set-module-name! iface (module-name mod)) On 2010/10/20 21:58:07, Patrick McCarty wrote: Please change this so that it uses a tab again. Done. http://codereview.appspot.com/2219044/diff/15001/scm/lily.scm#newcode338 scm/lily.scm:338: (fresh-interface! On 2010/10/20 21:58:07, Patrick McCarty wrote: This line too. Done. http://codereview.appspot.com/2219044/ ___ 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: Remove arabic.ly from common note name languages. (issue2755041)
On Wed, Oct 27, 2010 at 10:28 AM, Valentin Villenave
v.villen...@gmail.com wrote:
If it's half-baked, then please do comment on it.
I would have rather commented in the codereview interface, but oh well.
- pitches.itely, line 600 in new version: was there supposed to be a
newline here? I'm not certain why you started a new sentence on a new
line, so I thought it was worth checking this. (I don't think that it
_should_ be a new paragraph, but it's not clear what your intention
was)
- same place, but more generally: I'm not certain quite what these
paragraphs are getting at (perhaps seeing it in a bit more context
would have helped), but I think they could be improved.
- world.itely, line 20: I *really* don't like the comment. If it's a
TODO, then make sure you add a TODO string for ease of greppiness.
That said, I don't like seeing TODOs; I'd rather have a new issue in
the tracker. That said*2, wtf don't you just add the music glossary
entries yourself? If you don't know what to write in the Glossary,
you can still add the entry as a stub. And then add a doc item for
fill in stubs: makam, maqam, makamlarasdqrs. Remember that new doc
writers find @nodes and @ref{}s confusing, so if old-timers prepare
the general layout of the text files, it can save newbies literally
hours. I've added stubs a few times for new doc contributors.
- More generally, I'd rather see more clarity about languages vs.
music styles. It's not really clear to me (as a quick+ineffectual
reader) why Arabic isn't just one more language.
- finally, yes, I'm wanting the patch to be *better*-quality than the
original material. And I don't make any apology for that.
Whilst I understand the need to make it a matter of principles, if you
don't mind me asking: have you *looked* at the patch?
Yes.
On a subject
(removing arabic.ly) that we already discussed at length, and where we
all agreed (AFAICR).
Yes, we did.
Hadn't I ever heard anything from you on this
subject, then of course I wouldn't have dreamt of pushing this patch
without your blessing.
Umm, didn't you hear from me here:
http://lists.gnu.org/archive/html/lilypond-devel/2010-10/msg00401.html
For clarity:
1. Yes, I agree with the general aim of the new language format, and
treating arabic.ly separately from those.
2. I think the current direction of the code is fantastic, and I'm
really really glad to see you working on it.
3. However, I don't want to rush in. In particular, I want to review
any doc changes.
4. In particular*2, I want to review the FINAL version of any doc
patch. After you've made any changes that other people asked.
5. In particular*3, I'm not going to drop everything and look at a new
patch as soon as it goes online. I want at least a 24-hour period to
look at the patch.
In case #4 sounds like I'm being arrogant and disregarding other
developers: no, not at all. Basically, whenever you have a final
draft, I want it to be on codereview, and to get nothing but LGTM
or +1 from people, for at least 24 hours. Once that's done, go
ahead and push.
If you get ANY comments other than LGTM/+1 -- even if it's just
hey, there's a typo over here; you should replace teh with the --
then I want to see an updated patch on codereview. Which waits for
another 24-hour period.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Wrong version number listed in startup file for 2.13.37
hello,
I have just downloaded 2.13.37-1 for windows and to check I always
double click the LilyPond icon to see if I can compile the start up file.
I noticed just now that it says
\version 2.12.0
\header{
title = A scale in LilyPond
subtitle = For more information on using LilyPond, please see
http://lilypond.org/web/help/;
}
etc. etc.
---
Just to check again I commented out the \version number and compiled the
file and got
---
# -*-compilation-*-
Processing `C:/Users/jlowe/Desktop/hello.ly'
Parsing...
C:/Users/jlowe/Desktop/hello.ly:0: warning: no \version statement found,
please add
\version 2.13.37
for future compatibility
Interpreting music...
---
I won't have access to a Mac to see if it is just an installer issue.
Could someone else verify this in case I have some residual files on
this system. I have just done a clean uninstall and reinstall though.
James
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Remove arabic.ly from common note name languages. (issue2755041)
On 2010/10/27 10:27:30, graham_percival-music.ca wrote:
- same place, but more generally: I'm not certain quite what these
paragraphs are getting at (perhaps seeing it in a bit more context
would have helped), but I think they could be improved.
I think it's best if we treat non-Western stuff as notations and
tunings rather than just note names. Here's a new patch set, please
have a look.
- world.itely, line 20: I *really* don't like the comment. If it's a
TODO, then make sure you add a TODO string for ease of greppiness.
That said, I don't like seeing TODOs; I'd rather have a new issue in
the tracker. That said*2, wtf don't you just add the music glossary
entries yourself? If you don't know what to write in the Glossary,
you can still add the entry as a stub. And then add a doc item for
fill in stubs: makam, maqam, makamlarasdqrs. Remember that new doc
writers find @nodes and @ref{}s confusing, so if old-timers prepare
the general layout of the text files, it can save newbies literally
hours. I've added stubs a few times for new doc contributors.
Indeed. However, it's pretty hard to draw the line between what we add
and what we disregard. What I'd suggest (see patch) is to open a new
chapter within the MG. I think
- we have enough material to afford that,
- these terms are specialized enough to allow for really elaborate MG
entries,
- it avoids cluttering the Classical/Western MG with totally unrelated
terms and concepts,
- if anything, having a new @chapter to fill *might* encourage users to
help us expand it.
- More generally, I'd rather see more clarity about languages vs.
music styles. It's not really clear to me (as a quick+ineffectual
reader) why Arabic isn't just one more language.
Hence my proposal of not mentioning note names anymore in the
non-Western section's title.
- finally, yes, I'm wanting the patch to be *better*-quality than the
original material. And I don't make any apology for that.
Well, Trevor did mention that it looked better :)
In case #4 sounds like I'm being arrogant and disregarding other
developers: no, not at all. Basically, whenever you have a final
draft, I want it to be on codereview, and to get nothing but LGTM
or +1 from people, for at least 24 hours. Once that's done, go
ahead and push.
I don't blame you for wanting to review stuff and have the final say.
(Well, let me rephrase that: Wanting to review stuff and have the final
say, is not what I blame you for. :-)
OK, now all I have to do is find something to do for the next 24
hours... :)
Cheers.
http://codereview.appspot.com/2755041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Wrong version number listed in startup file for 2.13.37
On Wed, Oct 27, 2010 at 01:44:09PM +0100, James wrote: I have just downloaded 2.13.37-1 for windows and to check I always double click the LilyPond icon to see if I can compile the start up file. That's fine; it doesn't hurt to have a file with an old version string. The number will be updated before 2.14.0. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Wrong version number listed in startup file for 2.13.37
On Wed, Oct 27, 2010 at 2:44 PM, James james.l...@datacore.com wrote: Could someone else verify this in case I have some residual files on this system. I have just done a clean uninstall and reinstall though. No, it's normal actually: http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=blob;f=ly/Welcome_to_LilyPond.ly;hb=HEAD http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=blob;f=ly/Welcome-to-LilyPond-MacOS.ly;hb=HEAD This file is a nightmare to me, to be honest; it has the wrong version number, it isn't localized... That's what prompted me to open http://code.google.com/p/lilypond/issues/detail?id=698 a long time ago. Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update docstring for ly:gulp-file (issue2754041)
http://codereview.appspot.com/2754041/diff/1/lily/general-scheme.cc
File lily/general-scheme.cc (right):
http://codereview.appspot.com/2754041/diff/1/lily/general-scheme.cc#newcode84
lily/general-scheme.cc:84: If @var{size} is @code{SCM_UNDEFINED}, the
entire file is read.
To be in sync with the rest of the scheme function documentation, please
just say `undefined' and not `...@code{scm_undefined}'. Besides that, it
looks fine.
http://codereview.appspot.com/2754041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganize language files and add a new \language command. (issue2699041)
On 2010/10/27 00:48:09, Valentin Villenave wrote: Greetings everybody, new patch set. Please have a look! \version statements: I have put 2.13.38 in the regtest, but 2.14.0 in the .ly init files. Putting a minor version number in these files just didn't feel right. And 2.14 is near, isn't it? (Color me optimistic. :-) We need to have 2.13.38, so that the automatic update will work properly. http://codereview.appspot.com/2699041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganize language files and add a new \language command. (issue2699041)
Looks good! See my comments on the UTF-8 characters in the names getting mangled. Thanks, Carl http://codereview.appspot.com/2699041/diff/24001/ly/norsk.ly File ly/norsk.ly (right): http://codereview.appspot.com/2699041/diff/24001/ly/norsk.ly#newcode4 ly/norsk.ly:4: Copyright (C) 1998--2010 Arvid Grøtting arv...@ifi.uio.no Looks like the UTF-8 got mangled here. I think this should say Copyright (C) 2010 Valentin Villenave since none of the code remaining in this file belongs to Arvid. And I think that you should add all of the individual file authors to the formal statement at the top of language-init.ly. And I agree with keeping the authors in the block comments for each language -- but maybe not the copyright statement (since it's at the top of the file). http://codereview.appspot.com/2699041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganize language files and add a new \language command. (issue2699041)
Greetings everybody,
updated patch set.
Something keeps removing traling newlines at the end of files, I'm not
sure what does that (I have configured git core.whitespace properly,
though: could git cl or codereview be the culprit?).
On Wed, Oct 27, 2010 at 9:08 AM, percival.music...@gmail.com wrote:
That sentence has a clause: clause, clause (clause). This seems a bit
convoluted. How about:
Note names can be selected with a new @code{\language italiano}
command, which can be used in safe mode. The old syntax is still
supported for now, but will be deprecated in the future.
Thanks, that's better indeed. (In case you hadn't noticed, I do have a
thing for long sentences with lots of commas :)
Won't this break compiling? I'd expect lilypond to quit with a file
too new; update your version of lilypond message.
It doesn't quit, but it does complain.
Make it 2.13.37.
Done.
Carl, thanks for your advice. I have updated all copyright notices
accordingly to what you suggested.
Cheers,
Valentin.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Remove arabic.ly from common note name languages. (issue2755041)
On 27 Oct 2010, at 14:53, v.villen...@gmail.com wrote: I think it's best if we treat non-Western stuff as notations and tunings rather than just note names. Here's a new patch set, please have a look. As it now stands in the manual, it looks out of context to me. So it should be changed, I think: The situation in world music is the same as in CPP: there is a set of pitches that strictly speaking can refer to different tunings. Then people may choose different ways to name those notes. For example in gamelan music, some may use English and others Indonesian names. So strictly speaking, I think there should be headers: CPP, Arabic, Persian, Turkish, etc., and under each, there might be one or more files producing those. Also, I prefer CPP (Common Practice Period) to Western, as it becomes complicated to explain Western music traditions outside CPP. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Remove arabic.ly from common note name languages. (issue2755041)
A few editorial suggestions ... some apply to other similar instances,
which I've not marked.
http://codereview.appspot.com/2755041/diff/10001/Documentation/notation/pitches.itely
File Documentation/notation/pitches.itely (left):
http://codereview.appspot.com/2755041/diff/10001/Documentation/notation/pitches.itely#oldcode579
Documentation/notation/pitches.itely:579: Many non-Western musics (and
some Western folk and
Other types of non-Western music
http://codereview.appspot.com/2755041/diff/10001/Documentation/notation/pitches.itely#oldcode580
Documentation/notation/pitches.itely:580: traditional musics) employ
alternative or extended tuning
music
http://codereview.appspot.com/2755041/diff/10001/Documentation/notation/pitches.itely
File Documentation/notation/pitches.itely (right):
http://codereview.appspot.com/2755041/diff/10001/Documentation/notation/pitches.itely#newcode590
Documentation/notation/pitches.itely:590: systems. Some of these
musics, like Arabic music, may
Some of these, like
http://codereview.appspot.com/2755041/diff/10001/Documentation/notation/pitches.itely#newcode593
Documentation/notation/pitches.itely:593: implicitely determined by
context. Other types of music,
implicitly ... Others, however
http://codereview.appspot.com/2755041/diff/10001/Documentation/notation/vocal.itely
File Documentation/notation/vocal.itely (right):
http://codereview.appspot.com/2755041/diff/10001/Documentation/notation/vocal.itely#newcode632
Documentation/notation/vocal.itely:632: Ky -- ri -- e __
Quite correct! But it shouldn't be part of this patch.
http://codereview.appspot.com/2755041/diff/10001/Documentation/notation/world.itely
File Documentation/notation/world.itely (right):
http://codereview.appspot.com/2755041/diff/10001/Documentation/notation/world.itely#newcode93
Documentation/notation/world.itely:93:
Music Glossary should come before Notation Reference
http://codereview.appspot.com/2755041/diff/10001/Documentation/notation/world.itely#newcode261
Documentation/notation/world.itely:261: @notation{rast},
@rglos{ } ??
http://codereview.appspot.com/2755041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Spacing anomoly
Hello, On 26/10/2010 23:12, Francisco Vila wrote: 2010/10/26 James Lowejames.l...@datacore.com: \version 2.13.35 I can not reproduce your symptoms on current Git version, compiled today. You could always try 2.13.37. I did try 2.13.37 and you are correct. The issue has 'gone away'. Thanks James ___ 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: non-technical help for spacing issues
On Wed, 27 Oct 2010 00:24:33 -0700, Graham Percival gra...@percival-music.ca
wrote:
On Tue, Oct 26, 2010 at 01:23:01PM -0700, Keith E OHara wrote:
However, I have no familiarity with how vocal music is supposed
to look, and I tend to avoid tweaks myself. Graham's request
seems quite easy for a few people to cooperate on, if we test
the union of the overrides that we collectively need.
That would also be great! Would you be willing to organize such
an effort, particularly including lilypond-user?
Yes, but only at a 1-2 email per day pace, which should about right for this.
On Wed, 27 Oct 2010 16:57:29 +0200, Janek wrote:
As for familiarity with a moderately large body of scores - i have only
vocal scores, mostly short SATB choir pieces. If anyone would provide me
with some other scores, i'll experiment with them as well. And i'll take a
look on mutopia.
[...]
The problems with the bad version, compiled with 2.13.35 default settings,
are: [...]
Jan,
Version 2.13.37 resolves some major spacing problems, and its version of the
spacing engine is likely to go into 2.14, except for some changes to variable
names, and whatever we find necessary in changes to default settings.
I took a quick look at the overrides in the -ly files you provided, and
would guess that you will still want some of these in .37. One goal will be
learn to use the new system and find single values of the various settings that
work in combination to space all staves reasonably.
I hope you can install 2.13.37 and find what changes remain necessary for
your scores, in the next couple of days.
Yesterday I tried .37 on my mostly-piano scores, and will report on it this
evening (American pacific coast time) over on lilypond-user. I will try to
collect our needed settings into a single \layout{} on that mailing list.
-
Keith
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix #888: Add ly:stencil-scale. (issue2275042)
On 2010/10/26 08:21:41, Mark Polesky wrote:
Well... Okay, yeah, but see this:
http://kainhofer.com/%7Elilypond/Documentation/contributor/syntax-survey.html#miscellany
I'm the one that wrote the @var description there. And yes,
the rationale is simplistic: This improves readability in
the PDF and HTML output. But I think Neil's impulse to
format it that way matches the spirit of the rationale, no?
And I certainly wouldn't be opposed to instituting the same
policy for A.17, though of course that would be best left
for a different patch than this one.
I think that wrapping a variable declaration in a code declaration is
undesirable. It complicates the format of the documentation, for very
little benefit (if any).
If we want to change the format of @var{} in HTML and PDF format, we
ought to be able to do that in our texinfo program.
Or alternatively, we should get a different texinfo macro, e.g. @var{}
for outside of code, and @codevar{} for use inside of code.
THanks,
Carl
http://codereview.appspot.com/2275042/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Remove arabic.ly from common note name languages. (issue2755041)
Thanks Trevor! New patch set.
http://codereview.appspot.com/2755041/diff/10001/Documentation/notation/pitches.itely
File Documentation/notation/pitches.itely (left):
http://codereview.appspot.com/2755041/diff/10001/Documentation/notation/pitches.itely#oldcode579
Documentation/notation/pitches.itely:579: Many non-Western musics (and
some Western folk and
On 2010/10/27 17:41:18, Trevor Daniels wrote:
Other types of non-Western music
Er... no. Actually, These types music are not opposite to the former,
but even do include Arabic music! Please read again and tell me what I
could do to make it more clear...
http://codereview.appspot.com/2755041/diff/10001/Documentation/notation/pitches.itely#oldcode580
Documentation/notation/pitches.itely:580: traditional musics) employ
alternative or extended tuning
On 2010/10/27 17:41:18, Trevor Daniels wrote:
music
Done.
http://codereview.appspot.com/2755041/diff/10001/Documentation/notation/pitches.itely
File Documentation/notation/pitches.itely (right):
http://codereview.appspot.com/2755041/diff/10001/Documentation/notation/pitches.itely#newcode590
Documentation/notation/pitches.itely:590: systems. Some of these
musics, like Arabic music, may
On 2010/10/27 17:41:18, Trevor Daniels wrote:
Some of these, like
Done.
http://codereview.appspot.com/2755041/diff/10001/Documentation/notation/pitches.itely#newcode593
Documentation/notation/pitches.itely:593: implicitely determined by
context. Other types of music,
On 2010/10/27 17:41:18, Trevor Daniels wrote:
implicitly ... Others, however
Done.
http://codereview.appspot.com/2755041/diff/10001/Documentation/notation/vocal.itely
File Documentation/notation/vocal.itely (right):
http://codereview.appspot.com/2755041/diff/10001/Documentation/notation/vocal.itely#newcode632
Documentation/notation/vocal.itely:632: Ky -- ri -- e __
On 2010/10/27 17:41:18, Trevor Daniels wrote:
Quite correct! But it shouldn't be part of this patch.
Oops, my git branches got messed up.
http://codereview.appspot.com/2755041/diff/10001/Documentation/notation/world.itely
File Documentation/notation/world.itely (right):
http://codereview.appspot.com/2755041/diff/10001/Documentation/notation/world.itely#newcode93
Documentation/notation/world.itely:93:
On 2010/10/27 17:41:18, Trevor Daniels wrote:
Music Glossary should come before Notation Reference
Are you sure? I thought that what should come first were links to the
same manual (i.e. @ref links).
http://codereview.appspot.com/2755041/diff/10001/Documentation/notation/world.itely#newcode261
Documentation/notation/world.itely:261: @notation{rast},
On 2010/10/27 17:41:18, Trevor Daniels wrote:
@rglos{ } ??
Indeed.
http://codereview.appspot.com/2755041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Remove arabic.ly from common note name languages. (issue2755041)
On Wed, Oct 27, 2010 at 9:11 PM, v.villen...@gmail.com wrote: Are you sure? I thought that what should come first were links to the same manual (i.e. @ref links). Oh, I wasn't looking at the right section: I was looking at http://lilypond.org/doc/v2.13/Documentation/contributor/syntax-survey#cross-references instead of http://lilypond.org/doc/v2.13/Documentation/contributor/section-organization Sorry! Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Remove arabic.ly from common note name languages. (issue2755041)
On 27 Oct 2010, at 19:41, tdanielsmu...@googlemail.com wrote: A few editorial suggestions ... some apply to other similar instances, which I've not marked. The description of Turkish music is rather cursory: there are several descriptions. See for example Ozan Yarman, A Comparative Evaluation of Pitch Notations in Turkish Makam Music. The LilyPond text refers, I take it, to the Arel-Ezgi-Uzdilek (AEU) system. It does divide the major second M into 9 parts, but the minor second m is divided into 4; so it is 2*m + 5*M = 2*4 + 5*9 = 53 equal temperament. The file makam.ly, I recall, departs from E12 dividing the major second into 9 parts. So it should be in E108. So I avoid using the terms whole and half tones, because the half tone is not in general a half of the whole tone. :-) Also, when listing the note names as c, d, e, ..., then that refers to the octave numbering of major scales which I think was introduced by Helmholtz, possibly influenced by Romantic period centralizing CPP major/minor harmony. At the Maqam World site http://www.maqamworld.com/, they number the octaves according to the minor scale. I do not know why, but perhaps they have never started using the Helmholtz system. So perhaps the notes should be named a, b, c, ... in this context. Just mentioning it. When LilyPond expand being capable of handling more music outside CPP, there might be more such details pooping up. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problematic commit
On Wed, Oct 27, 2010 at 09:02:48PM +0200, Valentin Villenave wrote: On Wed, Oct 27, 2010 at 6:49 PM, Jonathan Wilkes jancs...@yahoo.com wrote: I'm interested to know how successful your sales pitch has been. I did a free software talk a few weeks ago but talked mostly about Pure Data and Ardour, plus music-oriented distros of GNU/Linux. I suspect that it may be (ever so slightly!) easier than selling LilyPond, since graphical applications have a little more bling than austere text-oriented apps like LilyPond. (Oh, you were referring to Pure Data. Ok, never mind.) Zing! That was a cheap shot. If your audience cringes at \include italiano.ly, what do they do when they learn how to put ca. in front of a metronome marking, or change the direction of a tie after a line break? ? I have no idea what you're referring to. Is that something you need to do with Finale? (If so, it may give me a nice argument when people object that LilyPond is too complex :-) He means if your audience is so text-hostile that they can't understand \include, then there's no bloody way that they can write scheme code and overrides, so they won't like lilypond anyway. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problematic commit
On Wed, Oct 27, 2010 at 10:54 PM, Graham Percival gra...@percival-music.ca wrote: Zing! That was a cheap shot. What can I say? You taught me well, Master :-) He means if your audience is so text-hostile that they can't understand \include, then there's no bloody way that they can write scheme code and overrides, so they won't like lilypond anyway. Putting ca. in front of a metronome marking is something I've never done (Jon, I assume you mean ca. as an abbreviation for circa? If you meant ca. as in a French word, then proper spelling is ça :-). As for changing direction of ties, I really really doubt that it's more easily achieved in Finale than in Lily. At least, it wasn't back when I did use these apps. Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problematic commit
Am Mittwoch, 27. Oktober 2010, um 23:13:14 schrieb Valentin Villenave: Putting ca. in front of a metronome marking is something I've never done (Jon, I assume you mean ca. as an abbreviation for circa? If you meant ca. as in a French word, then proper spelling is ça :-). Ah, do I love those French-speaking! Not everything derives from your great language ;-) No, ca. comes from the Latin word circa, meaning around, both in a spacial sense, as well as about (as in about 15 minutes)... BTW, adding ca. or ranges to tempo marks is something I would like to have eventually, but right now that's a little out of reach (save using explicit markups)... 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: problematic commit
On Wed, Oct 27, 2010 at 11:13:14PM +0200, Valentin Villenave wrote: On Wed, Oct 27, 2010 at 10:54 PM, Graham Percival gra...@percival-music.ca wrote: Zing! That was a cheap shot. What can I say? You taught me well, Master :-) Yeah, but I keep it classy, Valentine! I mean, making fun of somebody's girly name is high culture, whereas pointing out a lack of bling in an open-source project is just plain rude. As for changing direction of ties, I really really doubt that it's more easily achieved in Finale than in Lily. At least, it wasn't back when I did use these apps. Dude, there's a ton of things that Finale does easier. You want some symbol somewhere? Just drag it there with the mouse, look at it, drag it somewhere else. Now, you know, and I know, that this doesn't scale nicely to dealing with a hundred-page score, particularly if you want to change margins or page sizes or whatnot -- you'd need to manually redo all your absolutely positioned marks. But I'd bet that most Finale users don't do anything more complicated than a 3-page arrangement of Jingle Bells for SATB+piano, so the scaling argument is hard to make. LilyPond is not the best tool for every person in the world, and there's nothing wrong with admitting that. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problematic commit
--- On Wed, 10/27/10, Valentin Villenave valen...@villenave.net wrote: From: Valentin Villenave valen...@villenave.net Subject: Re: problematic commit To: Jonathan Wilkes jancs...@yahoo.com Cc: lilypond-devel@gnu.org Date: Wednesday, October 27, 2010, 9:02 PM On Wed, Oct 27, 2010 at 6:49 PM, Jonathan Wilkes jancs...@yahoo.com wrote: I'm interested to know how successful your sales pitch has been. I did a free software talk a few weeks ago but talked mostly about Pure Data and Ardour, plus music-oriented distros of GNU/Linux. I suspect that it may be (ever so slightly!) easier than selling LilyPond, since graphical applications have a little more bling than austere text-oriented apps like LilyPond. (Oh, you were referring to Pure Data. Ok, never mind.) Actually Pd has an ever-growing set of GUI objects-- you can see some of them being shown off in the image on Pd's Wikipedia page. If your audience cringes at \include italiano.ly, what do they do when they learn how to put ca. in front of a metronome marking, or change the direction of a tie after a line break? ? I have no idea what you're referring to. Is that something you need to do with Finale? (If so, it may give me a nice argument when people object that LilyPond is too complex :-) Well, no, I'm referring to Lilypond here. What I mean is that a) \tempo 4=72 looks easy, but if someone asks how to get that tempo but have it display as quarter note = ca. 72, as far as I know one has to have two two \tempo commands, one as above, and then followed with the \tempo \markup idiom. Then you have to deal with why \note has two different arg types (one string and one number). b) There are situations where a slur starts above the notes, and after a line break it would look better going in the opposite direction. I don't see that in many professional scores, so maybe this is just my own little peculiarity, but the same problem holds for slurs over linebreaks where there is a collision or spacing issue and one wants to adjust the slur only after the break. I'm just curious in general how your audience has responded to the way in which some small details are tweaked in Lilypond. -Jonathan Cheers, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Remove arabic.ly from common note name languages. (issue2755041)
On Wed, Oct 27, 2010 at 10:40 PM, Hans Aberg haber...@telia.com wrote: Hi Hans, Just mentioning it. When LilyPond expand being capable of handling more music outside CPP, there might be more such details pooping up. (no comment) The description of Turkish music is rather cursory: there are several descriptions. See for example Ozan Yarman, A Comparative Evaluation of Pitch Notations in Turkish Makam Music. The LilyPond text refers, I take it, to the Arel-Ezgi-Uzdilek (AEU) system. It does divide the major second M into 9 parts, but the minor second m is divided into 4; so it is 2*m + 5*M = 2*4 + 5*9 = 53 equal temperament. The file makam.ly, I recall, departs from E12 dividing the major second into 9 parts. So it should be in E108. So I avoid using the terms whole and half tones, because the half tone is not in general a half of the whole tone. :-) Also, when listing the note names as c, d, e, ..., then that refers to the octave numbering of major scales which I think was introduced by Helmholtz, possibly influenced by Romantic period centralizing CPP major/minor harmony. At the Maqam World site http://www.maqamworld.com/, they number the octaves according to the minor scale. I do not know why, but perhaps they have never started using the Helmholtz system. So perhaps the notes should be named a, b, c, ... in this context. Hans, you always have very interesting things to say on these subjects. However, since we're drifting waaay beyond my area of expertise here (if I ever had one), could you please be a tad more specific and suggest, concretely, how I can improve the documentation for makam tunings and maqam modes? I'm fine with adding precise references and explaining what the different systems are, why we use AEU/E108 tuning, etc. The Turkish music section is not very detailed right now, and could certainly be improved (possibly by adding a new section, I'm not sure yet). But please do keep in mind that I'm driving blind here, so to say. Moreover, the patch we're discussing adds a whole chapter to the music Glossary, dedicated to non-Western languages (even though I now understand it could be more accurately named non-CPP). Thanks! Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Remove arabic.ly from common note name languages. (issue2755041)
On 28 Oct 2010, at 00:20, Valentin Villenave wrote: Just mentioning it. When LilyPond expand being capable of handling more music outside CPP, there might be more such details [popping] up. (no comment) Sorry, a typo. :-) Hans, you always have very interesting things to say on these subjects. That is kind said of you. However, since we're drifting waaay beyond my area of expertise here (if I ever had one), could you please be a tad more specific and suggest, concretely, how I can improve the documentation for makam tunings and maqam modes? Perhaps by pointing out the specifics of the LilyPond implementation. I'm fine with adding precise references and explaining what the different systems are, why we use AEU/E108 tuning, etc. The Turkish music section is not very detailed right now, and could certainly be improved (possibly by adding a new section, I'm not sure yet). But please do keep in mind that I'm driving blind here, so to say. Basically, LilyPond makam.ly is a hack, but it may be fine if you are only interested in the typesetting and not having the MIDI files tuned exactly right. The difference might be considered slight, too. The same applies to arabic.ly - I recall it uses E24. The Arabic microtonal symbols are from E24, but the tuning use in actual performance is different. The Persian LilyPOnd file uses E60, I think. It has to do with the limitations of LilyPond at the time it was made, encouraging multiples of E12. Graham Breed made extensions to any tuning he said, but that has not yet found its way into these files. Moreover, the patch we're discussing adds a whole chapter to the music Glossary, dedicated to non-Western languages (even though I now understand it could be more accurately named non-CPP). I have found that some can be confused over that Western folk music and Medieval music are non-Western in the sense you use the term. So gradually, over the years, I found CPP captures it more accurately. Since the LilyPond project tries to some extend inform about musical usage, it might be best for it to stick to terms that best captures it, and then, in additional, indicate informal usage. That is the principle I see here. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Remove arabic.ly from common note name languages. (issue2755041)
Nearly there :)
http://codereview.appspot.com/2755041/diff/22001/Documentation/notation/pitches.itely
File Documentation/notation/pitches.itely (right):
http://codereview.appspot.com/2755041/diff/22001/Documentation/notation/pitches.itely#newcode588
Documentation/notation/pitches.itely:588: Many non-Western musics (and
some Western folk and
Many types of non-Western music (and ...
[It's musics I don't like]
http://codereview.appspot.com/2755041/diff/22001/Documentation/notation/pitches.itely#newcode652
Documentation/notation/pitches.itely:652: @rglos{makamlar}.
Music Glossary is placed before Notation Reference
http://codereview.appspot.com/2755041/diff/22001/Documentation/notation/world.itely
File Documentation/notation/world.itely (right):
http://codereview.appspot.com/2755041/diff/22001/Documentation/notation/world.itely#newcode92
Documentation/notation/world.itely:92: @rglos{maqam}.
Music Glossary comes before Notation Reference
http://codereview.appspot.com/2755041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problematic commit
2010/10/28 Jonathan Wilkes jancs...@yahoo.com: Well, no, I'm referring to Lilypond here. What I mean is that a) \tempo 4=72 looks easy, but if someone asks how to get that tempo but have it display as quarter note = ca. 72, as far as I know one has to have two two \tempo commands, one as above, and then followed with the \tempo \markup idiom. Then you have to deal with why \note has two different arg types (one string and one number). (...) I'm just curious in general how your audience has responded to the way in which some small details are tweaked in Lilypond. Compare LaTeX. No matter how crazy a hack can be, you can always copy/paste the code from a document that already works and uses it. Complicated things in a GUI can only be reproduced by someone else by using the GUI, so in a certain sense, the knowledge of language-based apps like LilyPond and LaTeX flows smoothly by the web, irc, email or whatever. Tips and tricks for GUI based apps consist on lots of screenshots, arrows, red circles and the like. That puts me sick sometimes. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problematic commit
--- On Thu, 10/28/10, Graham Percival gra...@percival-music.ca wrote: From: Graham Percival gra...@percival-music.ca Subject: Re: problematic commit To: Valentin Villenave valen...@villenave.net Cc: Jonathan Wilkes jancs...@yahoo.com, lilypond-devel@gnu.org Date: Thursday, October 28, 2010, 12:11 AM On Wed, Oct 27, 2010 at 11:13:14PM +0200, Valentin Villenave wrote: On Wed, Oct 27, 2010 at 10:54 PM, Graham Percival gra...@percival-music.ca wrote: Zing! That was a cheap shot. What can I say? You taught me well, Master :-) Yeah, but I keep it classy, Valentine! I mean, making fun of somebody's girly name is high culture, whereas pointing out a lack of bling in an open-source project is just plain rude. As for changing direction of ties, I really really doubt that it's more easily achieved in Finale than in Lily. At least, it wasn't back when I did use these apps. It's just ctrl-f for flip. Dude, there's a ton of things that Finale does easier. You want some symbol somewhere? Just drag it there with the mouse, look at it, drag it somewhere else. Now, you know, and I know, that this doesn't scale nicely to dealing with a hundred-page score, particularly if you want to change margins or page sizes or whatnot -- you'd need to manually redo all your absolutely positioned marks. In Finale, text, tempi, articulations, etc. are all connected to notes or staves. Well, there's a tool to position absolutely but it's only used for titles. But I'd bet that most Finale users don't do anything more complicated than a 3-page arrangement of Jingle Bells for SATB+piano, so the scaling argument is hard to make. They did a study about that and it has been scientifically proven. LilyPond is not the best tool for every person in the world, and there's nothing wrong with admitting that. That's true, but LilypondTool + Lily is a GUI. If the ruler tool could automatically fill in the context/grob/property for markup and articulations, one would have pretty much the same feature as click-dragging stuff in Finale. And if that feature were present, I doubt anyone would complain about the resulting efficiency in score entry. It's simply a useful tool whether it's in Finale, Lilypond, or Microsoft ScoreKeeper Pro*. -Jonathan * (tm) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problematic commit
On Thu, Oct 28, 2010 at 12:18 AM, Jonathan Wilkes jancs...@yahoo.com wrote: Actually Pd has an ever-growing set of GUI objects-- you can see some of them being shown off in the image on Pd's Wikipedia page. Well, that was kinda my point :-D Nah, just kidding. Pure Data looks simply gorgeous. For a Plan-9 application. Well, no, I'm referring to Lilypond here. What I mean is that a) \tempo 4=72 looks easy, but if someone asks how to get that tempo but have it display as quarter note = ca. 72, as far as I know one has to have two two \tempo commands, one as above, and then followed with the \tempo \markup idiom. Then you have to deal with why \note has two different arg types (one string and one number). It's interesting that you mention that (since I was the one who first tried to rethink the \tempo command a couple years ago, albeit much less nicely than Reinhold's implementation). I was a Sibelius power-user for, like, five years (from Sibelius 2 to Sibelius 5). And before that, I used Encore for a few years and wrote dozens of scores using these programs. And I do remember that the F***ing tempo marks were an absolute nightmare in each one of them. Mixing note-glyphs with text, giving up on any hope that the MIDI stuff would understand the indications, and (above all) never bloody knowing which exact Staff, which exact bar, the mark was going to be attached to (let alone proofreading separate instrumental parts)... (And: Yes, I do know that these objects have (supposedly) anchor points, etc. In theory it sounds great, but concretely it's always somewhere between unreliable and rubbish.) What will your average user do with these programs? Something crappy, that remotely looks like an appropriate tempo indication. What will your average user do with Lily? - first off, let's print a text indication. OK; (most users won't never go past that stage, and will live happily ever after) c'^Allegro - Oh, I need bold. OK, then I need a markup. OK; c'^\markup \bold Allegro - Oh, then I could very well put this as a proper tempo mark. OK; \tempo \markup \bold Allegro etc. Don't get me wrong: there *is* a learning curve. However, that's the difference with our contenders: in a Free Software /project/, the learning curves never ends (unless you reach the zen-master/buddha/stallman stage, I guess). Whereas a proprietary program is but a /product/: once you've reached its limits, there's just nothing beyond. Live with it, suck it up and stfu. b) There are situations where a slur starts above the notes, and after a line break it would look better going in the opposite direction. I don't see that in many professional scores, so maybe this is just my own little peculiarity, but the same problem holds for slurs over linebreaks where there is a collision or spacing issue and one wants to adjust the slur only after the break. I think Graham already made my point. With Sibelius, I used to spend roughly an hour per *system*, tweaking everything, pushing accidentals, solving collisions, manually removing tuplet numbers, faking stuff using invisible voices that, in turn, caused new collisions etc. And if (heavens forbid) I ever had *one* measure to insert or to remove, then I just add to start over (I had long lost all hope of automatic spacing or automatic system breaks: if I ever used auto-spacing, that was on *one* measure at a time, and even then I had to manually tweak things afterwards). The shape of slurs and ties was precisely one of my most excruciating and frustrating obsessions. So, hell no, having the ability to move stuff with your mouse is certainly not a plus. It merely allows you to repair the stupid mistakes that the software should *not* make in the first place. LilyPond does make mistakes, of course. However repairing those mistakes is quite easier than using your mouse (especially now that we have predefined shortcuts like \stemUp and the like). And most of all, you can rely on the fact that your tweaks will *stay* if you ever change the page layout. LilyPond (unlike *all* graphical software I've ever tested, even MuseScore) does NOT suddenly decide to change stuff without your consent, just because you have added one measure somewhere. I'm just curious in general how your audience has responded to the way in which some small details are tweaked in Lilypond. Well, it does require a progressive approach. (beware: long story long) The audience is generally divided in two categories before we even start: there are those who are confident that they know better, and that their Finale/Sibelius/whatever they already have on their computer is just unmatchable and they're wasting their time anyway. This group is actually my main target, because the other group (those who are genuinely eager to learn, either because they've never seen a computer produce music scores at all or either because they find graphical notation software unappealing, complicated or unsatisfying) is
(tuplet . around) causes regtests to fail to compile
The recent improve positioning of TupletNumber and Slur patch breaks the doc and regtest compile. I don't understand to understand how or why, but it does, so I've reverted that commit. Sorry, I don't have an exact error message for you, because somebody thought it would be funny to spam tons of thumb messages to the console during the regtest builds. I've added an issue for that separate problem: http://code.google.com/p/lilypond/issues/detail?id=1370 However, I do have the original doc-build error, which would presumably be the same problem as the regtest failure: Drawing systems... Element count 39 [Backtrace: In unknown file: ?: 0* [lilypond-main #] In /home/jlowe/lilypond-git/out/share/lilypond/current/scm/lily.scm: 785: 1* (let* ((failed #)) (if (ly:get-option #) (begin #)) ...) 785: 2* [lilypond-all #] 798: 3 (let* ((failed #) (separate-logs #) (ping-log #) ...) (gc) ...) 809: 4* [for-each #procedure #f # #] In unknown file: ?: 5* [#procedure #f (x) c7/lily-4bb72c87.ly] In /home/jlowe/lilypond-git/out/share/lilypond/current/scm/lily.scm: 811: 6* (let* (# # #) (if separate-logs #) (if ping-log #) ...) 822: 7* [lilypond-file #procedure #f (key failed-file) c7/lily-4bb72c87.ly] 847: 8 [catch ly-file-failed #procedure #f () #procedure #f (x . args)] In unknown file: ?: 9* [#procedure #f ()] In /home/jlowe/lilypond-git/out/share/lilypond/current/scm/lily.scm: 848: 10* [ly:parse-file c7/lily-4bb72c87.ly] In /home/jlowe/lilypond-git/out/share/lilypond/current/ly/init.ly: 48: 11* (let* ((book-handler #)) (cond (# #) (# #))) 51: 12 (cond (# #) (# #)) In /home/jlowe/lilypond-git/out/share/lilypond/current/scm/lily-library.scm: ... 210: 13 [ly:book-process-to-systems #Book # Output_def ...] In unknown file: ?: 14* [ly:system::height #Grob System ] ?: 15* [ly:axis-group-interface::calc-skylines #Grob System ] ?: 16* [ly:grob::y-parent-positioning #Grob VerticalAxisGroup ] ?: 17* [ly:align-interface::align-to-ideal-distances #Grob VerticalAlignment ] ?: 18* [ly:hara-kiri-group-spanner::calc-skylines #Grob VerticalAxisGroup ] ?: 19* [number? #undefined] ERROR: In procedure number?: ERROR: Wrong number of arguments to #primitive-procedure number? command failed: /home/jlowe/lilypond-git/out/bin/lilypond -I ./ -I ./out-www -I ../../input -I /home/jlowe/lilypond-git/Documentation -I /home/jlowe/lilypond-git/Documentation/snippets -I ../../input/regression/ -I /home/jlowe/lilypond-git/Documentation/included/ -I /home/jlowe/lilypond-git/mf/out/ -I /home/jlowe/lilypond-git/mf/out/ -I /home/jlowe/lilypond-git/Documentation/pictures -I /home/jlowe/lilypond-git/Documentation/pictures/./out-www -dbackend=eps --formats=ps,png,pdf -dinclude-eps-fonts -dgs-load-fonts --header=doctitle --header=doctitlede --header=doctitlees --header=doctitlefr --header=doctitlehu --header=doctitleit --header=doctitleja --header=doctitlenl --header=texidoc --header=texidocde --header=texidoces --header=texidocfr --header=texidochu --header=texidocit --header=texidocja --header=texidocnl -dcheck-internal-types -ddump-signatures -danti-alias-factor=2 -I /home/jlowe/lilypond-git/out/lybook-db -I /home/jlowe/lilypond-git/input/regression -I /home/jlowe/lilypond-git/input/regression -I /home/jlowe/lilypond-git/input/regression/out-www -I /home/jlowe/lilypond-git/input -I /home/jlowe/lilypond-git/Documentation -I /home/jlowe/lilypond-git/Documentation/snippets -I /home/jlowe/lilypond-git/input/regression -I /home/jlowe/lilypond-git/Documentation/included -I /home/jlowe/lilypond-git/mf/out -I /home/jlowe/lilypond-git/mf/out -I /home/jlowe/lilypond-git/Documentation/pictures -I /home/jlowe/lilypond-git/Documentation/pictures/out-www --formats=eps --verbose -deps-box-padding=3.00 -dread-file-list -dno-strip-output-dir /home/jlowe/lilypond-git/out/lybook-db/snippet-names--350604469.ly Child returned 1 In case it's relevant, this is on a 32-bit linux OS. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: CG: clarify convert-ly usage policy. (issue2687043)
On 2010/10/26 17:19:51, Carl wrote: L Great TM. this has now been pushed. http://codereview.appspot.com/2687043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganize language files and add a new \language command. (issue2699041)
LGTM http://codereview.appspot.com/2699041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Remove arabic.ly from common note name languages. (issue2755041)
comments.
http://codereview.appspot.com/2755041/diff/22001/Documentation/notation/pitches.itely
File Documentation/notation/pitches.itely (left):
http://codereview.appspot.com/2755041/diff/22001/Documentation/notation/pitches.itely#oldcode447
Documentation/notation/pitches.itely:447: use default (Nederlands) note
names, the @co...@bs{}include}
Incidently, does your language change mean that this limitation is no
longer true? That would be awesome.
http://codereview.appspot.com/2755041/diff/22001/Documentation/notation/pitches.itely
File Documentation/notation/pitches.itely (right):
http://codereview.appspot.com/2755041/diff/22001/Documentation/notation/pitches.itely#newcode41
Documentation/notation/pitches.itely:41: * Non-Western notations and
tunings::
WTM is notations ?
http://codereview.appspot.com/2755041/diff/22001/Documentation/notation/pitches.itely#newcode444
Documentation/notation/pitches.itely:444: @co...@w{@bs{}include
english.ly}} to the input file.
If you're going to change this, then you might as well change it
properly.
---
For example, to use English note names, use:
@lilypond[quote,verbatim]
\language english
\relative c'' {
c4 cs cf css
}
@end lilypond
-
I thought you were only doing the arabic stuff here, but oh well.
http://codereview.appspot.com/2755041/diff/22001/Documentation/notation/pitches.itely#newcode570
Documentation/notation/pitches.itely:570: @unnumberedsubsubsec
Non-Western notations and tunings
Why have an @unnumberedsubsubsec here at all? I suggest a single
sentence in the previous bit, saying something like Some types of
non-Western music use alternate pitches; these are discussed in
@ref{World music}.
Then we can safely isolate all that stuff to the relevant Specialist 2.x
section. Your job as a programmer and doc writer is over -- as long as
it's clear where this weird stuff should be discussed, you're fine. Let
somebody who cares about the alternate notations write the descriptions.
You're not expected to care about everything that your work touches.
And even if you *do* care about it, I'd rather see any music theory
descriptions as a separate patch, anyway. Focus on the _specific_ topic
at hand and get the patch approved+pushed. There's always time for more
patches later on.
http://codereview.appspot.com/2755041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganize language files and add a new \language command. (issue2699041)
Looks pretty good to me. Just a tiny style nitpick indicated below. Thanks for your work on this! Regards, Patrick http://codereview.appspot.com/2699041/diff/33001/input/regression/note-names.ly File input/regression/note-names.ly (right): http://codereview.appspot.com/2699041/diff/33001/input/regression/note-names.ly#newcode20 input/regression/note-names.ly:20: (set! pitchnames(ly:assoc-get 'nederlands language-pitch-names)) There should be a space between pitchnames and (ly:assoc-get http://codereview.appspot.com/2699041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
FW: [frogs] display-lily.scm question
Copied from frogs to devel, because I don't think the frog people can answer. Carl -- Forwarded Message From: Ian Hulin i...@hulin.org.uk Date: Wed, 27 Oct 2010 15:31:13 -0600 To: Lilypond Frogs List fr...@lilynet.net Conversation: [frogs] display-lily.scm question Subject: [frogs] display-lily.scm question -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I've just done some stuff with this file to ensure it compiles OK when running using Guile V1.9. It declares all it stuff in a module (define-module (scm dislplay-lily) It currently gets loaded by lily.scm as part of the dynamic load list near the end of the file. However, things declared as modules for use in the base 'lily' module are pulled in via a (use-modules) statement near the start of the file. Should display-lily.scm move from the ly:load list to the (use-modules) list? Cheers, Ian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMyJoNAAoJEBqidDirZqASPpAIAN46q+gWGsBtW9eCn6urABaz fXKLcbLu2rgOexl+RA0rrTamLPc5YKm9Eu2lSs3b9sfDi8f7SUYrTIcP276L4NHI 6R0CuFSJKgpMmmYfdd52+IHaItHwKGttCR1YyUOREdGLgR9s4Wg1acO3ZggDeQTU G1aNrXE2uvzH6HH4Yqw9fDNCTS3Ygv12SQsvflpNdMs1bA4fOi4zVh/VxJJp9zas iwbVTBfyuLLGykDe+R0KrY74qZTg4SC5ESIGK+vjH6fOUelifBPwyKhqcc1sGblJ A7viUnIVEsgqyX0WVEJRlQ3NhHrHU8PgqPYJSxjRGReBjYkT5A71/dkhs8fWM7k= =2zEo -END PGP SIGNATURE- --- Join the Frogs! -- End of Forwarded Message ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] display-lily.scm question
Hi Ian, On Wed, Oct 27, 2010 at 2:31 PM, Ian Hulin i...@hulin.org.uk wrote: I've just done some stuff with this file to ensure it compiles OK when running using Guile V1.9. It declares all it stuff in a module (define-module (scm dislplay-lily) It currently gets loaded by lily.scm as part of the dynamic load list near the end of the file. However, things declared as modules for use in the base 'lily' module are pulled in via a (use-modules) statement near the start of the file. Should display-lily.scm move from the ly:load list to the (use-modules) list? I'm a bit confused by this question... As I understand it, module (scm display-lily) is loaded via (use-modules ...) in music-functions.scm, on line 216. So, when the Guile 1.9 scheme compiler compiles music-functions.scm, it compiles display-lily.scm automatically at that point. Then, at the bottom of display-lily.scm, define-music-display-methods.scm is loaded. Is this the spot you are asking about? Thanks, Patrick PS. I can't review your latest curried-definitions patch until this weekend, at the earliest. Sorry about that. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LyricText #'font-series = #'bold-narrow ?!
I'm directing this primarily to bug-list folks. This was submitted over a week ago, and I see no action. Did I miss something? Yes. I've already fixed this in the git repository. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
