RE: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
From: lilypond-devel-bounces+c_sorensen=byu@gnu.org [lilypond-devel-bounces+c_sorensen=byu@gnu.org] On Behalf Of Benkő Pál [benko@gmail.com] Sent: Tuesday, February 22, 2011 2:11 PM To: Felipe Gonçalves Assis Cc: lilypond-devel@gnu.org Subject: Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044) Felipe, I'm still far from digesting the whole, but this is really great work! > 2. int vs Rational > >> Why not use a sequence of Rationals (rather than ints) to represent >> the alteration? > >> If we use rational numbers, we can maintain backward compatibility. > >> The re-scaling of the alterations is interesting but >> unnecessary. They could still be rationals. > > That is a very reasonable idea. Its main advantage would be, as pointed, in > more robust backwards compatibility, as well as ease of implementation. > > If you decide for that, I can work on a new patch. > > Further considerations of mine might be found below question 1.1 in > http://lists.gnu.org/archive/html/lilypond-devel/2010-12/msg00729.html > and after the last quote in > http://lists.gnu.org/archive/html/lilypond-devel/2010-12/msg00737.html I'm wholeheartedly for Int's, both as mathematician and as musician. math: if rationals are used, I'd expect to be able to use not only 1/2 but 3/5 etc. mus: I don't care too much for quarter tones, but I do care for e.g. meantone tuning, where graphical output is the same, but MIDI manipulations are very different: the enharmonic interval gis-as is a bit more than half of g-gis. Using hard-coded 1/2 is plain ugly, OTOH I know that 1 is just the coefficient of the augmented prime (aka chromatic half-note). as a programmer: since we switch from numbers to pairs, users using exotic constructs ouside FLAT or SEMI-SHARP should anyway think carefully about converting to the new representation. p ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
Felipe, I'm still far from digesting the whole, but this is really great work! > 2. int vs Rational > >> Why not use a sequence of Rationals (rather than ints) to represent >> the alteration? > >> If we use rational numbers, we can maintain backward compatibility. > >> The re-scaling of the alterations is interesting but >> unnecessary. They could still be rationals. > > That is a very reasonable idea. Its main advantage would be, as pointed, in > more robust backwards compatibility, as well as ease of implementation. > > If you decide for that, I can work on a new patch. > > Further considerations of mine might be found below question 1.1 in > http://lists.gnu.org/archive/html/lilypond-devel/2010-12/msg00729.html > and after the last quote in > http://lists.gnu.org/archive/html/lilypond-devel/2010-12/msg00737.html I'm wholeheartedly for Int's, both as mathematician and as musician. math: if rationals are used, I'd expect to be able to use not only 1/2 but 3/5 etc. mus: I don't care too much for quarter tones, but I do care for e.g. meantone tuning, where graphical output is the same, but MIDI manipulations are very different: the enharmonic interval gis-as is a bit more than half of g-gis. Using hard-coded 1/2 is plain ugly, OTOH I know that 1 is just the coefficient of the augmented prime (aka chromatic half-note). as a programmer: since we switch from numbers to pairs, users using exotic constructs ouside FLAT or SEMI-SHARP should anyway think carefully about converting to the new representation. p ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
Hey, lilypond-devel complained about the recipient list of this message, so I am resending it. Sorry for those who are receiving it for the second time. -- Forwarded message -- Hello everyone, First of all, thanks for the extensive comments made on this. I will try to address the major topics in this mail. Sorry if I miss anything. === 1. Issue header > Nitpick: if this were called something like "change internal pitch > representation" in the first line of the patch, I would have looked > earlier. From a casual glance at my mailbox, it looked like it would > be a simple bugfix patch for issue 1278. I should remind you that this patch was at first only casually posted as a background for a discussion I started by the end of the last year, see http://lists.gnu.org/archive/html/lilypond-devel/2010-12/msg00726.html I am taking this review as a continuation of that discussion. So, for those of you who did not follow that, I will give relevant pointers below. For now, I think you really should check the attachments in http://lists.gnu.org/archive/html/lilypond-devel/2010-12/msg00730.html I will occasionally make references to towards123, which is attached in http://lists.gnu.org/archive/html/lilypond-devel/2010-12/msg00729.html - 2. int vs Rational > Why not use a sequence of Rationals (rather than ints) to represent > the alteration? > If we use rational numbers, we can maintain backward compatibility. > The re-scaling of the alterations is interesting but > unnecessary. They could still be rationals. That is a very reasonable idea. Its main advantage would be, as pointed, in more robust backwards compatibility, as well as ease of implementation. If you decide for that, I can work on a new patch. Further considerations of mine might be found below question 1.1 in http://lists.gnu.org/archive/html/lilypond-devel/2010-12/msg00729.html and after the last quote in http://lists.gnu.org/archive/html/lilypond-devel/2010-12/msg00737.html - 3. Transposition > you have to set a rule that (0 . 1) + (0 . 1) = (1 . 0). No, we don't. Transposing c to cis takes cis to cisis, not to d. If you are not using arrow notation, you can define a quarter tone to be (1 . 0). Also, see the next topic, for further discussion. - 4. Normalisation Many objections regarding transposition in my current patch, or in LilyPond's current behaviour, are related to what I am calling normalisation. This is what may cause musical transposition to look complicated, it really is not. My considerations on the subject can be found in Section 3 of towards123. - 5. Scale 1 > I think that the arguments to make-scale should not have implicit steps > (which they currently do) Steps _mean_ position on Scale, which in its turn means position in the staff. I assume this to uniquely determine one of the coefficients in the group representation of the pitch. The vector argument to make-scale then just specifies what alteration is attached to each position when no accidental is added to it. This well models every notation system I have come across. Besides, a notation system in which this did not work would either need some specific algorithm to determine the staff position of a pitched note, or not work with transpositions well. - 6. Scale 2 > The alteration sizes aren't part of the default scale. > It's counter intuitive to set them in that function. Firstly, the default scale effectively is just the static part of the C++ Pitch class, except when you instantiate a Pitch, then reset the default scale, and then use that Pitch (which will refer to the old scale). Secondly, see my considerations on Section 1 of towards123. - 7. Default arguments in ly:make-pitch > I don't see why ly:make-pitch can't take a single rational > as the alteration, and assign it as the first alteration in > the majority of cases where that's what you want. Whether we to decide for ints or for Rationals, I completely agree that make-pitch should have optional arguments. Even the alteration itself should be optional. The single reason why I chose not to enable that in this patch was to track parts of the code that would need rewriting, by making the code break until I edited them. I was particularly concerned with the commits made after my patch, that could silently invalidate it. Of course, none of this would have to be undertaken with a Rational pair/list representation. === If you have any further questions, or if you think that I forgot something, please write. Also: Should I write a new version of this patch using Rational instead of int? I look forward to hearing from you. Regards, Felipe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
On Fri, Feb 18, 2011 at 7:46 PM, wrote: >> Why not use a sequence of Rationals [..] to represent the alteration? > > A single Rational can hold the series as a sum, and preserve the > separability of the terms, if we use mutually prime denominators. > In scales where cih is identical to ciseh, ciseh can be +1/2 - 1/4 = > 1/4. > In scales where cih is logically distinct from ciseh, ciseh can be +1/2 > - 1/5. I know that, but 1. The separability will go out the window if people start transposing by these amounts. +1/1 - 1/5 = 3/10. Transpose by that 5 times, and you have 15/10 = 3; the quarter tones have gone. I realize this concern is mostly academic. 2. If what we really want to represent is a sequence of numbers (and I gather it is), we should make the internal representation a sequence too. If we use rational numbers, we can maintain backward compatibility. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
On 2/18/11, Han-Wen Nienhuys wrote: > On Fri, Jan 28, 2011 at 12:17 PM, wrote: >> >> I'm very sorry about the delay, but at least I'm looking at it now, and >> I'll take care of badgering people to review it once it's ready. > > Nitpick: if this were called something like "change internal pitch > representation" in the first line of the patch, I would have looked > earlier. From a casual glance at my mailbox, it looked like it would > be a simple bugfix patch for issue 1278. Sorry, and thanks for the suggestion. I've made a note to check the patch subject as part of my "obvious" checks before making something "patch-review", in particular to avoid subjects like "fix 123". Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
On Fri, Jan 28, 2011 at 12:17 PM, wrote: > Hi Felipe, > > I'm very sorry about the delay, but at least I'm looking at it now, and > I'll take care of badgering people to review it once it's ready. > Nitpick: if this were called something like "change internal pitch representation" in the first line of the patch, I would have looked earlier. From a casual glance at my mailbox, it looked like it would be a simple bugfix patch for issue 1278. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
On Fri, Feb 18, 2011 at 3:43 AM, wrote: > I advise against changing the internal representation of pitches. I am rather skeptic against patches that would want to do this, but from a casual glance, it looks thorough at least, and I understand that the current system is too limited still. What makes me uncomfortable that this looks like a non-backward compatible change. Why not use a sequence of Rationals (rather than ints) to represent the alteration? You could maintain the current system in a backward compatible way (using 1/2 and 1/4 as the only element in the alteration sequence) or have a system with tuples: +1/2 for the first element and +1/4 for the second element. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
"Keith OHara" writes: > In the end, I'm a physicist, and pitch is a scalar, so a > one-dimensional real-valued representation seems wisest to me. Since "real-valued" means a fuzzy and undefined set of rational numbers with denominators of the form 2^k for which not even associative law holds, I strongly disagree. Rationals are fine. "real-valued" isn't. Things don't compare sensibly, things don't add up sensibly. Transposition would be gambling, as would be most other manipulations. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
On Thu, 17 Feb 2011 21:58:28 -0800, wrote:
On 2011/02/18 05:43:36, Keith wrote:
The extra complication, for which the care was given, makes the system
more difficult to learn, understand, use, and repair.
Unfortunately, I believe that the extra complication is necessary. The
commit message didn't clarify the background or our previous discussions
on the topic, but it boils down to composers wanting to distinguish
between cis+1/4 and cisis-1/4
I read the emails, and understand wanting cisih distinct from cisiseh.
The current representation can store them as distinct pitches :
-isih = 1/2 + 1/5 = 7/10
-isiseh = 1/2 + 1/2 - 1/5 = 8/10
This would be consistent with notations (extended Helmholtz-Ellis) that use
natural-up to represent a pitch somewhat flatter than sharp-down.
The only request I saw for cisiseh and cisih to be in some sense the 'same
pitch', was for transpositions. The request
(http://lists.gnu.org/archive/html/lilypond-user/2009-04/msg00649.html) is for :
\transpose c cih { cisih } == cisis
and analogously
\transpose c cis { cisis } == dis
Neither the current representation, nor the patch's, makes the identities above
happen. Either would need (later) a different flavor of \transpose that
'normalizes' (and maybe rounds) its output, to serve the equal-temperament
users, while the current \transpose serves the just-intonation camp.
NB: most requests were for *arbitrary* tunings, such as 31-tone or IIRC
even 78-tone.
There current system has no trouble representing 66 pitches in an octave in
makam.ly.
In the end, I'm a physicist, and pitch is a scalar, so a one-dimensional
real-valued representation seems wisest to me.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
On 2011/02/18 05:43:36, Keith wrote: The extra complication, for which the care was given, makes the system more difficult to learn, understand, use, and repair. Unfortunately, I believe that the extra complication is necessary. The commit message didn't clarify the background or our previous discussions on the topic, but it boils down to composers wanting to distinguish between cis+1/4 and cisis-1/4 On a personal note, I am completely uninterested in microtonal notation; I don't even care about the difference between equal temperament and just intonation. But on a "professional" note, we have heard repeated requests from composers "in the field" -- including people who make a living from composing and/or music academia -- so I consider it a very valid request. Given the multiple long discussions about the topic, I don't think we can dismiss it. NB: most requests were for *arbitrary* tunings, such as 31-tone or IIRC even 78-tone. As far as I understand microtonal composers and their academic circles, mere quarter-tones is far too mainstream to even consider. :) http://codereview.appspot.com/3789044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
I advise against changing the internal representation of pitches. I say that even though this looks like very good and careful code, and after spending two hours studying it. The extra complication, for which the care was given, makes the system more difficult to learn, understand, use, and repair. Maybe convert the patch to distinguish quarter-tones using the existing Rational alterations: sharp-down = 1/2 - 1/5 = 3/10 natural-up =+1/5 = 2/10 These sort in the same order as the solution in this patch. It should be fine if the internal representation is not exactly 1/4; some people use the up-arrow to indicate pitches in just-intonation schemes. Also, for most instruments 'ces' is not really 1/2 a tone above 'c' but there no harm from representing the sharp as 1/2. The email chain linked in the patch mentions a similar method, saying the 'problem' was that method was that transposing from the key of C to the key of C-natural-up fails to convert a natural-up to a sharp. However we do not ask Lilypond to convert 'fisis' to 'g' in a\transpose. Also, the proposed representation in this patch has the same 'problem'. Transposition with automatic conversion (of 2/10 + 2/10 to 1/2, for example) should be done by a function distinct form the current \transpose, possibly written in Scheme using Mike Ellis' modal transposition as a model. http://codereview.appspot.com/3789044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
On 2/17/11 1:34 PM, "Felipe Gonçalves Assis" wrote: > Hi Carl, > > The denominators are not implicit. > They are set in the file scm/lily.scm via the call to ly:set-default-scale. > > Also see lily/scale.cc, lily/include/scale.hh and lily/pitch.cc:89 > for how this is implemented. Ahh, OK. Now I understand. I think that the arguments to make-scale should not have implicit steps (which they currently do). They should be lists instead of pairs (or else they should be (step . alteration) pairs. And the value of each number in the list should correspond to the weights in the values list. ((0 0 0) (1 0 0) (2 0 0) (3 -1 0) (4 -1 0) (5 -1 0) (6 -1 0) (6 0 0)) (1 1/2 1/4) That way there is a one-to-one correspondence between the pitch declarations and the weightings. As long as we're adjusting things, I think we ought to be consistent. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
http://codereview.appspot.com/3789044/diff/29001/python/musicexp.py File python/musicexp.py (right): http://codereview.appspot.com/3789044/diff/29001/python/musicexp.py#newcode308 python/musicexp.py:308: return '(ly:make-pitch %d %d \'(%d . 0))' % (self.octave, On 2011/02/17 20:01:25, Carl wrote: Why is the 0 for the second alteration hard-coded? IIUC, this python code only deals with semitones. By the way, the corresponding line in the current version is a bug (I sent a mail to the frogs last week about that). http://codereview.appspot.com/3789044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
Hi Carl, The denominators are not implicit. They are set in the file scm/lily.scm via the call to ly:set-default-scale. Also see lily/scale.cc, lily/include/scale.hh and lily/pitch.cc:89 for how this is implemented. ly/makam.ly gives an example of how to modify the denominators. If you need further clarification, just ask me. I will reply to the other comments, and possibly upload a new revision by the weekend. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
On 2/17/11, carl.d.soren...@gmail.com wrote: > I have one question, I think. Right now, the alteration consists of two > integers, which have implied denominators of 1/2 and 1/4, if I > understand correctly. > > Would it be more general to have the alteration consist of two > rationals? Or could we have some way of defining a base-alteration pair > that would be rationals? And then the implied denominators of 1/2 and > 1/4 would no longer be implicit, but would be explicit in either the > alteration or the base-alteration? > > I think (but am not sure) that such an implementation would meet the > needs that Hans Aberg has defined for appropriate microtonal support. Very good point! I've cc'd Hans and Graham Breed to inquire about this. Current patch is here: http://codereview.appspot.com/3789044/ Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
This work looks good to me, but I'm not an expert in this area. I have one question, I think. Right now, the alteration consists of two integers, which have implied denominators of 1/2 and 1/4, if I understand correctly. Would it be more general to have the alteration consist of two rationals? Or could we have some way of defining a base-alteration pair that would be rationals? And then the implied denominators of 1/2 and 1/4 would no longer be implicit, but would be explicit in either the alteration or the base-alteration? I think (but am not sure) that such an implementation would meet the needs that Hans Aberg has defined for appropriate microtonal support. Of course, this entire suggestion could be garbage, because I am not an expert on this topic, as I mentioned above. Thanks, Carl http://codereview.appspot.com/3789044/diff/29001/lily/accidental-placement.cc File lily/accidental-placement.cc (right): http://codereview.appspot.com/3789044/diff/29001/lily/accidental-placement.cc#newcode239 lily/accidental-placement.cc:239: Alteration last_alteration (0); Why is this last_alteration (0), instead of last_alteration () or last_alteration (NATURAL)? http://codereview.appspot.com/3789044/diff/29001/lily/include/pitch.hh File lily/include/pitch.hh (right): http://codereview.appspot.com/3789044/diff/29001/lily/include/pitch.hh#newcode60 lily/include/pitch.hh:60: Pitch (int octave, int notename, int alt1, int alt2); I'm somewhat hesitant about this code that limits an alteration to two integers. Are we sure that this is general enough given the fact that we're moving to an Alteration datatype? http://codereview.appspot.com/3789044/diff/29001/lily/scale.cc File lily/scale.cc (right): http://codereview.appspot.com/3789044/diff/29001/lily/scale.cc#newcode36 lily/scale.cc:36: " arguments are rational numbers giving the weigth in" spelling: weigth -> weight http://codereview.appspot.com/3789044/diff/29001/lily/scale.cc#newcode94 lily/scale.cc:94: " scale. The number of pitches in this scale minus one" "The number of scale steps in an octave is the number of pitches in the global scale minus one." http://codereview.appspot.com/3789044/diff/29001/python/musicexp.py File python/musicexp.py (right): http://codereview.appspot.com/3789044/diff/29001/python/musicexp.py#newcode308 python/musicexp.py:308: return '(ly:make-pitch %d %d \'(%d . 0))' % (self.octave, Why is the 0 for the second alteration hard-coded? http://codereview.appspot.com/3789044/diff/29001/scm/define-markup-commands.scm File scm/define-markup-commands.scm (right): http://codereview.appspot.com/3789044/diff/29001/scm/define-markup-commands.scm#newcode2418 scm/define-markup-commands.scm:2418: (interpret-markup layout props (markup #:musicglyph (assoc-get '(2 . 0) standard-alteration-glyph-name-alist "" Can this use SHARP, instead of (2 . 0)? http://codereview.appspot.com/3789044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
Hi, In fact, this patch is divided in a few commits in my local branch. The ones which change the pitch representation are most of the diff. The rest are trivial additions that enable the new notation to be used. If this patch is approved, there will be no problem in separating the work in two or three commits. If you want me to upload just part of the patch, I will do so, but that wouldn't simplify the diffs much. On 17 February 2011 17:03, wrote: > LGTM. > > I admittedly don't know this part of the source well, so I'll leave > comments about that to other programmers. > > My only concern is about the scope of this patch. It seems like this > patch is doing two things: implementing a new type of quarter tone > notation & implementing alterations as a replacement for rationals in > certain scenarios. From the headache that sometimes comes with having > to go upstream with the code after something accidentally breaks, it > seems that patches should generally be confined to one and only one > functionality that is modified. > > Would it be possible, then, to separate out you work with accidentals > from your work with alterations so that, if something like git bisect > needs to be done, any eventual problem can be localized. > > http://codereview.appspot.com/3789044/ > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
LGTM. I admittedly don't know this part of the source well, so I'll leave comments about that to other programmers. My only concern is about the scope of this patch. It seems like this patch is doing two things: implementing a new type of quarter tone notation & implementing alterations as a replacement for rationals in certain scenarios. From the headache that sometimes comes with having to go upstream with the code after something accidentally breaks, it seems that patches should generally be confined to one and only one functionality that is modified. Would it be possible, then, to separate out you work with accidentals from your work with alterations so that, if something like git bisect needs to be done, any eventual problem can be localized. http://codereview.appspot.com/3789044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
I think it's ready for review now. http://codereview.appspot.com/3789044/diff/29001/ly/makam.ly File ly/makam.ly (right): http://codereview.appspot.com/3789044/diff/29001/ly/makam.ly#newcode9 ly/makam.ly:9: #(ly:set-default-scale (ly:make-scale '#((0 . 0) (0 . 0) (0 . 0) (-9 . 0) (-9 . 0) (-9 . 0) (-9 . 0) (-18 . 0)) 1 1/18 0)) Could we get some linebreaks in here? http://codereview.appspot.com/3789044/diff/29001/scm/lily.scm File scm/lily.scm (right): http://codereview.appspot.com/3789044/diff/29001/scm/lily.scm#newcode387 scm/lily.scm:387: (ly:set-default-scale (ly:make-scale #((0 . 0) (0 . 0) (0 . 0) (-1 . 0) (-1 . 0) (-1 . 0) (-1 . 0) (-2 . 0)) 1 1/2 1/4)) linebreaks here could be helpful. http://codereview.appspot.com/3789044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
Hi, A new patch set was uploaded, now including the scm files. On 10 February 2011 20:32, wrote: > Thanks! Regtests look fine, and there's nothing obviously wrong with > the code. > > However, none of the scm files managed to get uploaded. I remember > hearing about problems about this, and the CG now contains: > - > Note: Some installations of git-cl fail when uploading a patch set that > includes a .scm file. When this happens, it can generally be fixed by > editing the file ‘/etc/mime.types’. Add a line to this file containing > text/x-script.scheme scm. > - > on page: > http://lilypond.org/doc/v2.13/Documentation/contributor/commits-and-patches#uploading-a-patch-for-review > > Could you try going that, then uploading again? > > http://codereview.appspot.com/3789044/ > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
Thanks! Regtests look fine, and there's nothing obviously wrong with the code. However, none of the scm files managed to get uploaded. I remember hearing about problems about this, and the CG now contains: - Note: Some installations of git-cl fail when uploading a patch set that includes a .scm file. When this happens, it can generally be fixed by editing the file ‘/etc/mime.types’. Add a line to this file containing text/x-script.scheme scm. - on page: http://lilypond.org/doc/v2.13/Documentation/contributor/commits-and-patches#uploading-a-patch-for-review Could you try going that, then uploading again? http://codereview.appspot.com/3789044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
Uploaded. Please check if it is all right now. 2011/2/10 Felipe Gonçalves Assis : > Hi, > > In fact, yesterday's "make key cancellations independent of extraNatural" > introduced a simple conflict with my patch, which I have just resolved. > > Other files were automatically merged. > > After some testing, I will upload a new patch-set. > > Regards, > Felipe > > On 10 February 2011 16:13, wrote: >> Sorry, I still can't apply this cleanly to git master. Are you sure you >> did a rebase? (I admit that I'm not totally certain about how to do >> this, but I've seen people in lilypond-devel talking about it -- maybe >> look through the mailing list archives for tips?) >> >> At the moment, I see failures in >> lily/key-engraver.cc >> and warnings in >> lily/parser.yy >> ly/engraver-init.ly >> scm/translation-functions.scm >> >> >> http://codereview.appspot.com/3789044/ >> > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
Hi, In fact, yesterday's "make key cancellations independent of extraNatural" introduced a simple conflict with my patch, which I have just resolved. Other files were automatically merged. After some testing, I will upload a new patch-set. Regards, Felipe On 10 February 2011 16:13, wrote: > Sorry, I still can't apply this cleanly to git master. Are you sure you > did a rebase? (I admit that I'm not totally certain about how to do > this, but I've seen people in lilypond-devel talking about it -- maybe > look through the mailing list archives for tips?) > > At the moment, I see failures in > lily/key-engraver.cc > and warnings in > lily/parser.yy > ly/engraver-init.ly > scm/translation-functions.scm > > > http://codereview.appspot.com/3789044/ > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
Sorry, I still can't apply this cleanly to git master. Are you sure you did a rebase? (I admit that I'm not totally certain about how to do this, but I've seen people in lilypond-devel talking about it -- maybe look through the mailing list archives for tips?) At the moment, I see failures in lily/key-engraver.cc and warnings in lily/parser.yy ly/engraver-init.ly scm/translation-functions.scm http://codereview.appspot.com/3789044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
Hello, A new patch set has just been uploaded. Sorry for my delay. Felipe 2011/1/29 Felipe Gonçalves Assis : > Right, > > I will have a look at that. > > Thanks! > > Felipe > > On 28 January 2011 12:17, wrote: >> Hi Felipe, >> >> I'm very sorry about the delay, but at least I'm looking at it now, and >> I'll take care of badgering people to review it once it's ready. >> >> Unfortunately due to the delay, we have a few extra regtests, which fail >> when this patch is applied. One is tablature-string-tunings.ly -- I >> think that the old (ly:make-pitch ...) just needs to be updated to use >> the NATURAL thing that you've used elsewhere. >> >> Could you try rebasing this patch from current git master, check for >> anything that's changed from 4 weeks ago, and then upload a new draft? >> >> I promise that we won't ignore the next draft. I'm very sorry about >> this problem. >> - Graham >> >> http://codereview.appspot.com/3789044/ >> > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
Right, I will have a look at that. Thanks! Felipe On 28 January 2011 12:17, wrote: > Hi Felipe, > > I'm very sorry about the delay, but at least I'm looking at it now, and > I'll take care of badgering people to review it once it's ready. > > Unfortunately due to the delay, we have a few extra regtests, which fail > when this patch is applied. One is tablature-string-tunings.ly -- I > think that the old (ly:make-pitch ...) just needs to be updated to use > the NATURAL thing that you've used elsewhere. > > Could you try rebasing this patch from current git master, check for > anything that's changed from 4 weeks ago, and then upload a new draft? > > I promise that we won't ignore the next draft. I'm very sorry about > this problem. > - Graham > > http://codereview.appspot.com/3789044/ > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
Hi Felipe, I'm very sorry about the delay, but at least I'm looking at it now, and I'll take care of badgering people to review it once it's ready. Unfortunately due to the delay, we have a few extra regtests, which fail when this patch is applied. One is tablature-string-tunings.ly -- I think that the old (ly:make-pitch ...) just needs to be updated to use the NATURAL thing that you've used elsewhere. Could you try rebasing this patch from current git master, check for anything that's changed from 4 weeks ago, and then upload a new draft? I promise that we won't ignore the next draft. I'm very sorry about this problem. - Graham http://codereview.appspot.com/3789044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Issue 1278: Arrow notation for quarter-tones. (issue3789044)
Reviewers: , Message: This patch is first and foremost a change in the internal Pitch representation. I then suggest that we first discuss that, having it as a reference. Description: Issue 1278: Arrow notation for quarter-tones. We change the internal pitch representation so as to account for two levels of alteration. Basically, instead of representing alterations by a rational number, we represent them by a pair of integers. The main changes are the addition of an Alteration struct, and modifications in the Pitch and Scale classes. The Pitch class was reimplemented. Its interface was mostly preserved. No pitch normalisation policy is implemented, though. (see lily/include/pitch.hh and lily/pitch.cc) Class Scale was completely rewritten. (see lily/include/scale.hh and lily/scale.hh) Finally, new note names are defined, and the arrow style accidentals are made available via the new arrow-alteration-glyph-name-alist. (see scm/lily-library.scm, scm/define-note-names.scm and scm/output-lib.scm) Other changes are basically simple side-effects of these. Please review this at http://codereview.appspot.com/3789044/ Affected files: M input/regression/scheme-book-scores.ly M lily/accidental-engraver.cc M lily/accidental-placement.cc A lily/alteration.cc M lily/ambitus-engraver.cc A lily/include/alteration.hh M lily/include/lily-guile.hh M lily/include/pitch.hh M lily/include/scale.hh M lily/key-engraver.cc M lily/key-performer.cc M lily/key-signature-interface.cc M lily/lily-guile.cc M lily/music-scheme.cc M lily/music.cc M lily/parser.yy M lily/pitch-scheme.cc M lily/pitch.cc M lily/pitched-trill-engraver.cc M lily/scale.cc M lily/slur-scoring.cc M ly/engraver-init.ly M ly/makam.ly M ly/scale-definitions-init.ly scm/chord-entry.scm scm/chord-generic-names.scm scm/chord-ignatzek-names.scm scm/chord-name.scm scm/define-grob-properties.scm scm/define-markup-commands.scm scm/define-music-display-methods.scm scm/define-music-properties.scm scm/define-note-names.scm scm/lily-library.scm scm/lily.scm scm/midi.scm scm/music-functions.scm scm/output-lib.scm scm/tablature.scm scm/translation-functions.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
