Re: Towards a new pitch representation
Hi, Are you using a two-element list, or a cons cell? The two are not the same. I seem to remember looking in the code, and seeing scm_cadr calls, which implies that your alterations would be (1 -1), not (1 . -1). In scheme I am using a cons cell, in C++ I am using a new struct with overloaded operators. I was using the terms list and pair in an informal way. Sorry for the confusion. If we are going to move to a list for alterations, the list should probably be rationals, rather than integers, in order to be most general. Thus it should most likely be (1/2 -1/4), rather than (1 -1). Alternatively, you will need a property somewhere which is a list of the base units for each alteration, so that an alteration would be (1 -1), and the alterationMagnitude would be (1/2 1/4). Right. In my patch this alterationMagnitude was sneaked in as new arguments for make-scale. So, by redefining the default-scale, you get what you want (see ly/makam.ly in the patch and dodecaphonic-adapted.ly in my previous message). As I said, if you are going to use only a finite number of rationals, you can always accomplish the same results by using integers and scaling them accordingly. This scaling is only used for things like midi and ambitus. For transposition, and engraving, you only need the integers. In the current patch, you force all alterations to be lists (or cons cells, whichever you have implemented). This will break lots of old scores. It would be cleaner to allow alterations to be numbers (as they were in the past) or lists. Then the old code would work. Otherwise, you'll need to make a convert-ly rule which may be a bit tricky. I think that as long as you *allow* but don't require the extended pitch representation, it's likely to be very well accepted. That is an important point. Below is what can be argued in defense of this. . For code that only uses 1/4 alterations, and does not redefine the default scale, convert-ly will be enough. . The only snippet in the LSR that calls ly:set-default-scale is precisely dodecaphonic.ly. . Integers are faster than rationals. So, admittedly, this idea of using a list of rationals, simple as at is, only occurred to me while writing towards123, yesterday. If the community decides for that, I will start working on a new patch as soon as the order is given. So, unless someone comes up with a completely new idea, what we have to decide is a. Rationals or Integers? ais. How many of them? I look forward to hearing from you. Cheers, Felipe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Towards a new pitch representation
On 30 Dec 2010, at 23:16, Felipe Gonçalves Assis wrote: 1. How should we represent alterations? It is clear to me that the most general representation would be as a list of integers of arbitrary length (see sections 1 and 2 of the attachment). I made a proposal for a representation, and there is Haskell code available if you are interested. In it, the staff positions are expressed by a linear combinations of a sequence of seconds m, M, n_0, ..., n_k (whatever names you want to give them). If one only has a minor second m and a major second M, then sharps raise with the interval M - m and the flats lower with that interval. So I generalized this as to compute for any set of accidentals. The algorithm will depend on the typesetting preferences, but it is possible to compute them without any reference to pitches at all. 1.1. How do we implement the mapping from alterations to tones? A simple idea is to replace the list of integers by a list of rationals, corresponding to the value of the alteration in tones. This is the current approach, except for the fact that the list has length 1. Rational numbers are not sufficient for the theoretically given: one must be able to take roots, for example when computing meantone values. So, for the exact given values, I added those roots. This suffices, as one is never going to add the numbers of the intervals - interval addition correspond to multiplication of numbers. The implementation representation I chose was as a prime factorization - a map from prime numbers to rational numbers. This seems to work well, as one is typically just working with a few small prime numbers. But when working with inexact intervals, like in pitch bends or given s cents, etc., this proved inconvenient. So I added an inexact part, a floating point number (double). The representation is thus (r, x), where r is the exact number above, and x a floating point number. When x = 1.0, the representation is considered exact. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Towards a new pitch representation
On 31 December 2010 04:43, David Kastrup d...@gnu.org wrote: Carl Sorensen c_soren...@byu.edu writes: If we are going to move to a list for alterations, the list should probably be rationals, rather than integers, in order to be most general. Thus it should most likely be (1/2 -1/4), rather than (1 -1). In that case, it would appear that alteration as a separate concept could be eliminated, and instead of pitch x with alteration (y z ...), we could just write (x y z ...). That is a very fine idea! By the way, I look forwards to hearing more advice on how to implement and organize things in Scheme, since I am a beginner in that. It is just a pity that x is not (logarithmically) equispaced in physical pitch. Hey, do not regret that yet! There is a simple procedure f such that pitch (x y z ...) means exactly x tones, (+ y (f x)) semitones, z whatever, etc. This is what is actually implemented by class Scale. This does not change much with the use of rational numbers. You may enjoy checking function Pitch::transpose in lily/pitch.cc:142, as well as the call to ly:set-default-scale in scm/lily.scm:387. Cheers, Felipe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Towards a new pitch representation
2010/12/31 Hans Aberg haber...@telia.com: On 30 Dec 2010, at 23:16, Felipe Gonçalves Assis wrote: I made a proposal for a representation, and there is Haskell code available if you are interested. Hi Hans. I would very much appreciate that code. I should remark that your emails are what inspired me to start this. I take this opportunity to thank you for everything. In it, the staff positions are expressed by a linear combinations of a sequence of seconds m, M, n_0, ..., n_k (whatever names you want to give them). If one only has a minor second m and a major second M, then sharps raise with the interval M - m and the flats lower with that interval. So I generalized this as to compute for any set of accidentals. The algorithm will depend on the typesetting preferences, but it is possible to compute them without any reference to pitches at all. So, my idea is the same, except that I use the differences between the seconds, so that the degree is just the coefficient of the major second, and the calculation of accidentals is simpler (again, see notes on section 2.1 of towards123.txt). Rational numbers are not sufficient for the theoretically given: one must be able to take roots, for example when computing meantone values. Firstly, I repeat that the use of rational numbers would be algebraically equivalent to integers, so this does not come to the theoretical discussion here, it would be just convenient with regards to backwards compatibility. Secondly, taking roots does not change the situation. You can represent that just using one more integer in your representation for each root. Finally, we are primarily concerned with notation here, so the fact that we represent a sharp by +1/2 does not forbid you to write a midi engraver that implements your favourite temperament (as close as midi can get to that). So, for the exact given values, I added those roots. This suffices, as one is never going to add the numbers of the intervals - interval addition correspond to multiplication of numbers. The implementation representation I chose was as a prime factorization - a map from prime numbers to rational numbers. This seems to work well, as one is typically just working with a few small prime numbers. Oh, I see. That is actually what I was talking about in towards123 when I pointed the isomorphism between Z^(inf) and Q*, but that sounds like unnecessary trouble to go with, even though it might look beautiful in your Haskell code. But when working with inexact intervals, like in pitch bends or given s cents, etc., this proved inconvenient. So I added an inexact part, a floating point number (double). The representation is thus (r, x), where r is the exact number above, and x a floating point number. When x = 1.0, the representation is considered exact. That is fine. But once more I remark that we are interested here in notation. What you are attaining is to represent frequencies in a way that is virtually always exact for music concerns (which looks quite promising, by the way). Thank you very much for all the thoughts you have put in this. Cheers, Felipe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Towards a new pitch representation
On 31 Dec 2010, at 10:59, Felipe Gonçalves Assis wrote: I made a proposal for a representation, and there is Haskell code available if you are interested. Hi Hans. I would very much appreciate that code. I have put it up here. https://www-lagring.telia.se/Shares/Home.aspx?ShareID=069b86e6-3f8d-4d4e-a328-f7e9d4a6c121 I run it in Hugs http://haskell.org/hugs/; start it using from the directory above the unpacked one by hugs Score.Staff On a Mac, I add -Eopen, so ':e' opens the file in an editor. This is the file that computes the accidentals from a staff system. Get back to here if you want more info. There is another module Score.Scale with the pitch model. Those are not entirely synced together. The module Score.Intervals contains intervals I got from Scala. I should remark that your emails are what inspired me to start this. I take this opportunity to thank you for everything. It would be nice if it can serve as an inspiration for you tom implement something in LilyPond. In it, the staff positions are expressed by a linear combinations of a sequence of seconds m, M, n_0, ..., n_k (whatever names you want to give them). If one only has a minor second m and a major second M, then sharps raise with the interval M - m and the flats lower with that interval. So I generalized this as to compute for any set of accidentals. The algorithm will depend on the typesetting preferences, but it is possible to compute them without any reference to pitches at all. So, my idea is the same, except that I use the differences between the seconds, so that the degree is just the coefficient of the major second, and the calculation of accidentals is simpler (again, see notes on section 2.1 of towards123.txt). Yes - it gets more complicated when having more accidentals. Musically, one plays on the seconds, and the accidentals only show up to express differences between them: Define a tuning system by some intervals like the fifth P5 having the interval 3/2 and the octave P8 2, which gives the Pythagorean tuning, or replace the fifth with the major third M3 set to 5/4, which gives quarter-comma tuning. Then express these intervals algebraically without their values in linear combinations of the minor second m and the major second M: P5 = m + 3M, P8 = 2m + 5M, M3 = 2M. When computing the tuning system, one expresses the intervals abstractly like this, which is also what the staff system expresses: these algebraic relations. Then this leads to a matrix which should be inverted in order to get actual values for m and M. So what I do is a generalization of this. Rational numbers are not sufficient for the theoretically given: one must be able to take roots, for example when computing meantone values. Firstly, I repeat that the use of rational numbers would be algebraically equivalent to integers, so this does not come to the theoretical discussion here, it would be just convenient with regards to backwards compatibility. Secondly, taking roots does not change the situation. You can represent that just using one more integer in your representation for each root. Finally, we are primarily concerned with notation here, so the fact that we represent a sharp by +1/2 does not forbid you to write a midi engraver that implements your favourite temperament (as close as midi can get to that). I'm not sure exactly what model you have in mind, but this is mostly necessary in order to produce sound files, and possibly if one would want to impose algebraic relation, though for example E12 (12-ET) enharmonic equivalences can be introduced by adding/subtracting muliplse of M - 2m. LilyPond has now 2^r, where is rational, thought that is not fully implemented for example for key signatures, which only accept E24. So I extend this to 2^r_1 3^r_2 5^r_3 ..., which I represent as a map (associative array) (2, r_2) (3, r_3) (5, r_5) ... Since one does not need to add these numbers, one mostly just has to add exponents. This data type then includes not only the rationals, but also all ETs as well other systems like the Bohlen-Pierce scale. So, for the exact given values, I added those roots. This suffices, as one is never going to add the numbers of the intervals - interval addition correspond to multiplication of numbers. The implementation representation I chose was as a prime factorization - a map from prime numbers to rational numbers. This seems to work well, as one is typically just working with a few small prime numbers. Oh, I see. That is actually what I was talking about in towards123 when I pointed the isomorphism between Z^(inf) and Q*, but that sounds like unnecessary trouble to go with, even though it might look beautiful in your Haskell code. Yes, I think this may be a good candidate. The only practical problem would be if one would encounter a large prime, which would happen if say
Re: Towards a new pitch representation
Thanks for the code, Hans! There are many things I am curious about. Now that I have the sources, I will spend some time analysing them, and then contact you. While I need some time to study your considerations, what I can say now is: . If, under a given musical system, what is printed on the score is enough to determine the precise tuning of a pitch, and if LilyPond supports the notation used, then it is possible to write an engraver that produces the correct sound output without changing the pitch representation. As I said, using the number 1/2 to represent a sharp does not bind you to ET. . Otherwise, I need to carefully study tuning systems and their use. So, while I am proposing a somewhat fundamental change, it is still something relatively simple, that will hopefully not break much user code, and might make some microtonalists happy. I have good hope that this job may be finished before the Equinox. That being pointed, I must express that I would very much appreciate to further bridge your ideas into LilyPond so as to make it an even more powerful software. We actually have plenty of time for that, since work for 2.15 has not even officially started yet. I then suggest we proceed with this conversation in a different branch, in private or in public, as you prefer, and keep this thread to discuss how the simpler ideas I am proposing might get into LilyPond. I look forward to keeping in contact with you. Thanks, Felipe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Towards a new pitch representation
On 12/31/10 1:31 AM, Felipe Gonçalves Assis felipeg.as...@gmail.com wrote: Hi, Are you using a two-element list, or a cons cell? The two are not the same. I seem to remember looking in the code, and seeing scm_cadr calls, which implies that your alterations would be (1 -1), not (1 . -1). In scheme I am using a cons cell, in C++ I am using a new struct with overloaded operators. I was using the terms list and pair in an informal way. Sorry for the confusion. If we are going to move to a list for alterations, the list should probably be rationals, rather than integers, in order to be most general. Thus it should most likely be (1/2 -1/4), rather than (1 -1). Alternatively, you will need a property somewhere which is a list of the base units for each alteration, so that an alteration would be (1 -1), and the alterationMagnitude would be (1/2 1/4). Right. In my patch this alterationMagnitude was sneaked in as new arguments for make-scale. So, by redefining the default-scale, you get what you want (see ly/makam.ly in the patch and dodecaphonic-adapted.ly in my previous message). As I said, if you are going to use only a finite number of rationals, you can always accomplish the same results by using integers and scaling them accordingly. This scaling is only used for things like midi and ambitus. For transposition, and engraving, you only need the integers. In the current patch, you force all alterations to be lists (or cons cells, whichever you have implemented). This will break lots of old scores. It would be cleaner to allow alterations to be numbers (as they were in the past) or lists. Then the old code would work. Otherwise, you'll need to make a convert-ly rule which may be a bit tricky. I think that as long as you *allow* but don't require the extended pitch representation, it's likely to be very well accepted. That is an important point. Below is what can be argued in defense of this. . For code that only uses 1/4 alterations, and does not redefine the default scale, convert-ly will be enough. . The only snippet in the LSR that calls ly:set-default-scale is precisely dodecaphonic.ly. . Integers are faster than rationals. For some large percentage of music written (certainly greater than 90%, probably more like 99%), quarter-tone accidentals are irrelevant. If you keep the standard notation for this case, I think you'll get the best possible performance, and you'll make code entry as easy as possible for people -- they can keep doing it the way they've always done it. And it's not hard to code. Why not do it? So, admittedly, this idea of using a list of rationals, simple as at is, only occurred to me while writing towards123, yesterday. If the community decides for that, I will start working on a new patch as soon as the order is given. So, unless someone comes up with a completely new idea, what we have to decide is a. Rationals or Integers? Probably integers, with a rational magnitude list that is used to convert to midi. ais. How many of them? No need to decide how many of them. Just make the argument a list, instead of a cons cell, and give the user access to change the length of the list if they want to. For the default distribution, the list length should be two, because we have symbols for quarter-tone alterations, but no symbols for anything smaller. In makam.ly, we may want to have a different list length. I don't know, because I haven't done anything with turkish music. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Towards a new pitch representation
Carl Sorensen c_soren...@byu.edu writes: No need to decide how many of them. Just make the argument a list, instead of a cons cell, and give the user access to change the length of the list if they want to. Huh? Access to change the length of the list? We are talking about a list, don't we? Not an array? The list is whatever length you need at any particular point of time. If it is a list of alterations, quite possibly length 0. For the default distribution, the list length should be two, because we have symbols for quarter-tone alterations, but no symbols for anything smaller. Huh? What point is there in declaring a certain list length in advance rather than just using what is needed? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Towards a new pitch representation
On 12/31/10 8:46 AM, David Kastrup d...@gnu.org wrote: Carl Sorensen c_soren...@byu.edu writes: No need to decide how many of them. Just make the argument a list, instead of a cons cell, and give the user access to change the length of the list if they want to. Huh? Access to change the length of the list? We are talking about a list, don't we? Not an array? The list is whatever length you need at any particular point of time. If it is a list of alterations, quite possibly length 0. As long as we're talking about a list, not a pair. The current test implementation is a pair. For the default distribution, the list length should be two, because we have symbols for quarter-tone alterations, but no symbols for anything smaller. Huh? What point is there in declaring a certain list length in advance rather than just using what is needed? No point in general. For the midi conversion, the list that defines the magnitude of the alterations needs to be defined at the maximum allowed alteration resolution. If we go with a list of rationals, then there is no need to define any list length in advance. There does need to be some correspondence between the list of alterations and the symbols used for displaying the alterations. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Towards a new pitch representation
On 31 Dec 2010, at 16:19, Felipe Gonçalves Assis wrote: Thanks for the code, Hans! There are many things I am curious about. Now that I have the sources, I will spend some time analysing them, and then contact you. While I need some time to study your considerations, what I can say now is: . If, under a given musical system, what is printed on the score is enough to determine the precise tuning of a pitch, and if LilyPond supports the notation used, then it is possible to write an engraver that produces the correct sound output without changing the pitch representation. As I said, using the number 1/2 to represent a sharp does not bind you to ET. . Otherwise, I need to carefully study tuning systems and their use. So, while I am proposing a somewhat fundamental change, it is still something relatively simple, that will hopefully not break much user code, and might make some microtonalists happy. I have good hope that this job may be finished before the Equinox. Graham Breed haas already extended it to arbitrary ETs within the current LilyPond pitch model - I have added some of his stuff to the link I put up before. In the file regular.ly, he somehow recomputes it. I do not know how it works, only that for key signatures of the form \key ..., there is a problem if the accidentals are not in E24. So those must be written out explicitly. That being pointed, I must express that I would very much appreciate to further bridge your ideas into LilyPond so as to make it an even more powerful software. We actually have plenty of time for that, since work for 2.15 has not even officially started yet. My proposal involve an entirely new model, but I think it would be simpler to use, and also be able to make the most of the staff typesetting system. I then suggest we proceed with this conversation in a different branch, in private or in public, as you prefer, and keep this thread to discuss how the simpler ideas I am proposing might get into LilyPond. Post it to this list so others know, but cc me if you want to be sure I see it. I look forward to keeping in contact with you. Just shoot. Hans ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Towards a new pitch representation
Ok, Carl, You vote for a list of integers, with arbitrary length. There is actually no complication in not specifying its size. Te midi engraver, for example, would just ignore entries for which no value was specified. And in transpositions, the unspecified values would just be considered zero. In makam.ly, as I understand it, we would not need longer lists, just one-sized lists with a different magnitude specification, as in my current patch. At least in order to maintain the current behaviour with regards to transposition. In general, anything that should behave the old way, should use a single alteration level. I look forward to hearing more opinions. Thanks, Felipe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Towards a new pitch representation
On 12/31/10 10:28 AM, Felipe Gonçalves Assis felipeg.as...@gmail.com wrote: Ok, Carl, You vote for a list of integers, with arbitrary length. I'm not sure I vote, yet. I'm still in discussion mode. I *do* vote for either a number or a list, so that the current behavior can continue. I *do* vote for a list, rather than a pair, for the alterations, because that allows extension to arbitrary levels of alterations. I *think* I vote for separating the scale degree from the alterations. The approach of including degree and alterations in a combined list has mathematical elegance, most musicians will think in terms of scale degree with alterations (e.g. d flat is scale degree d with an alteration of flat). I think the current interface is good from the user point of view. Thanks, Carl P.S. I'm so impressed that you came along *making* the change, instead of asking somebody else to make the change for you. That's a great contribution! ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Towards a new pitch representation
Hello, I will be away for about three days, so you might have to wait for replies to any questions to me addressed. When I'm back I'll read every post in this thread, and answer the relevant questions. Happy New Gregorian Year! Felipe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Towards a new pitch representation
Hello, Issue 1278 (http://code.google.com/p/lilypond/issues/detail?id=1278) clarified that, in order to support some microtonal notations, LilyPond needs to use a different pitch representation. I am willing to make that happen. Of course, this will require some contribution from more experienced developers. That being said, this contribution needs to be no more than objective discussions about well-defined questions and, at the end, a patch review. Could you, please, help me with that? This thread is for such discussions. I intend to address issues sequentially and generally in a top-down direction. A useful reference will be the experimental patch I just posted on Rietveld: http://codereview.appspot.com/3789044/ Please try it, and take a look at it if possible, but do not start commenting the code before we agree on the fundamentals. We might end up with a quite different version of that. In follow ups, I will start to bother you with questions. Thanks in advance for your attention and any support provided. Kind regards, Felipe P.S. While I understand that this issue is probably something for 2.15, I must remark that by March I will be very busy. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Towards a new pitch representation
On 12/30/10 2:07 PM, Felipe Gonçalves Assis felipeg.as...@gmail.com wrote: Hello, Issue 1278 (http://code.google.com/p/lilypond/issues/detail?id=1278) clarified that, in order to support some microtonal notations, LilyPond needs to use a different pitch representation. I am willing to make that happen. Of course, this will require some contribution from more experienced developers. That being said, this contribution needs to be no more than objective discussions about well-defined questions and, at the end, a patch review. Hi, Felipe. I've looked at your patch, but I'm having a bit of trouble seeing how the patch resolves the issues that are identified in issue 1278. I must admit that i've not yet fully understood Hans's emails on issue 1278. How do your new two-element alterations improve the situation? Could you, please, help me with that? This thread is for such discussions. I intend to address issues sequentially and generally in a top-down direction. A useful reference will be the experimental patch I just posted on Rietveld: http://codereview.appspot.com/3789044/ Please try it, and take a look at it if possible, but do not start commenting the code before we agree on the fundamentals. We might end up with a quite different version of that. It would be very helpful for me to discuss this patch if you had a test file that shows how the new features are used. It would be even better if there were a test file that compiled but didn't behave properly in 2.13.44, and then a corresponding file that does behave properly in your patch. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Towards a new pitch representation
So, first question 1. How should we represent alterations? It is clear to me that the most general representation would be as a list of integers of arbitrary length (see sections 1 and 2 of the attachment). However, a fixed length list might be more realistic. In my patch, I opted for a pair of integers, which is enough to solve 1278. The enhancement request mentions many other microtonal notations beyond arrow notation for quarter-tones. Advice from anyone acquainted with microtonal notations is needed here. Then we come to 1.1. How do we implement the mapping from alterations to tones? A simple idea is to replace the list of integers by a list of rationals, corresponding to the value of the alteration in tones. This is the current approach, except for the fact that the list has length 1. In this case, the alteration of cesih would be described as (-1/2 . +1/4). One advantage is that this just extends the current version, allowing existing code (both from the software and from users) to be supported without modification (just make some arguments optional). Alternatively, we can separate the Tuning System from the alteration algebra, and realize this map as a function in the program, preferentially configurable. This is what I tried in my patch, using class Scale for that, which works fine, and makes some sense, but I am completely open to suggestions here. The advantage of this approach over the previous one is that it makes the group structure of alterations more evident, and the operations cheaper. On the other hand, some people might dislike the fact that the default-scale has to be redefined in, e.g., ly/makam.ly. I look forward to hearing from you. Kind regards, Felipe General thoughts on pitch representation. 1. Some vocabulary So, first I would like to introduce two simple concepts, the interplay of which is of relevance to what will be discussed: that of a Physical Pitch, and that of an Algebraic Pitch (as I name them). A Physical Pitch is what you sing, and it is perfectly modelled by a real number of tones, or by a frequency in Hertz. An Algebraic Pitch is what you write. It has a name, and corresponds to a specific symbol in the staff. Its representation is one of the central questions here. Transposition makes sense for both of these. (As mathematicians would say, these are both abelian groups) Algebraic Pitches might be realized as Physical Pitches by means of what I will call a Tuning System. Being LilyPond a music engraving program, it is primarily concerned with Algebraic Pitches. Physical Pitches, however, come at play for things like midi output and ambitus, and so some kind of Tuning System needs to be implemented. As things are now, I would describe class Pitch as representing an Algebraic Pitch with an embedded Tuning System, available via the method Pitch::tone_pitch () and its siblings. The Tuning System is partly in class Scale and partly in the fact that an alteration is represented by its value in tones. I am ok with embedding the Tuning System in Pitch objects, as long as that is not hard-coded. But I do not like to bind such algebraic creatures as alterations to a specific value in tones. 2. The algebras of pitches Let us analyse some musical systems, and try to come up with a good mathematical description of Algebraic Pitches in each of them, with an eye on transposition. 2.1 Traditional In common music notation, we work at the level of semitones. But there are two kinds of semitones: chromatic and diatonic. This reflects at notation. A pitch can be perfectly described as a combination of tones (T), chromatic semitones (C) and diatonic ones (D). Actually, any two of these will do, since they are related by T=C+D. I suggest we pick tones and chromatic semitones. The unaltered notes in the diatonic staff would then be 0, T, 2T, 3T-C, 4T-C, 5T-C, 6T-C, 7T-2C, 8T-2C, ... In general, a note in the n-th position of the staff would be represented as nT + f(n)C, where f is a simple function. Altered notes are obtained just adding a C for every sharp and subtracting for every flat. So, a gisis' is just (4T + f(4)C) + 2C = 4T+C. Reciprocally, suppose we want to find the LilyPond name for pitch 5T-3C. From the coefficient of the T we get the basic note name, that is, a'. A natural a' would be 5T-C, so we have to add an alteration of -2C, getting aeses'. In general, the alteration of pitch aT+bC is b-f(a). Transposition is just addition. For example, transposition from c' to des' (T-c) takes e' (2T) to f' (3T-c). (Note: Hans Aberg used tones and diatonic semitones, which he called major and minor seconds, and denoted by M and m, respectively. He called the position of a note in the staff its degree.) (Note: In my patch, the main purpose of class Scale is to implement function f. It is also used to define a simple Tuning System.) 2.2 Turkish classical music (Warning: Everything I know about this comes from the NR) In
Re: Towards a new pitch representation
Hi Carl,
Hi, Felipe.
I've looked at your patch, but I'm having a bit of trouble seeing how the
patch resolves the issues that are identified in issue 1278.
I must admit that i've not yet fully understood Hans's emails on issue 1278.
How do your new two-element alterations improve the situation?
You don't need to go back to those emails. I hope the attachment in my
last email can help. But for a simple example of how my patch works,
when you type, e.g., ciseh' in a LilyPond input file, this is mapped to a
pitch that has as alteration (1 . -1), meaning one semitone minus one
quarter-tone, which might then be typeset as a sharp with a down-arrow.
In contrast, cih' has as alteration (0 . 1), which might be mapped to
a natural with an up-arrow.
The current representation cannot make that distinction, both alterations
would be 1/4 (for this reason ciseh is not even defined).
It would be very helpful for me to discuss this patch if you had a test file
that shows how the new features are used.
I am very sorry for forgetting to provide this. I am attaching some examples.
arrows.ly demonstrates the functionality requested in issue 1278.
dodecaphonic-adapted.ly is an adaptation of the snippet dodecaphonic.ly
using the new interfaces.
It would be even better if there were a test file that compiled but didn't
behave properly in 2.13.44, and then a corresponding file that does behave
properly in your patch.
This is an enhancement request for which we have files that did not
compile in the previous version, but that now produce nice scores
(again, see arrows.ly).
Thanks,
Felipe
\version 2.13.45
music = \relative c' {
ceses4 ceseh ces cesih
ceh c2 cih4
ciseh4 cis cisih cisis
}
\score {
\new Staff {
\override Staff.Accidental #'glyph-name-alist = #arrow-alteration-glyph-name-alist
\music
\transpose c f { \music }
}
\midi { }
\layout { }
}
%LSR originally contributed by Graham Breed for version 2.11.65
% Dodecaphonic notation, after Erv Wilson, but probably an earlier idea.
\include english.ly
% set the nominals to be 12-equal
#(ly:set-default-scale (ly:make-scale '#((0 . 0) (0 . 0) (0 . 0) (0 . 0)
(0 . 0) (0 . 0) (0 . 0) (0 . 0)
(0 . 0) (0 . 0) (0 . 0) (0 . 0)
(0 . 0)) 1/2 1/2 1/4))
% Set the pitches to 12-equal with enharmonic equivalences
% keep the original pitch names.
% Preserves quartertones as half-sharps.
dodecaPitchNames = #(map (lambda (pitchname)
(let* ((pitch (cdr pitchname))
(quartertones (ly:pitch-quartertones pitch))
(fractional-steps (/ quartertones 2))
(steps (inexact-exact (floor fractional-steps))) ;; Not sure if inexact-exact is needed here
(alt (inexact-exact
(floor (* 2 (- fractional-steps steps))
(cons (car pitchname)
(ly:make-pitch 0
steps
(cons 0 alt)
pitchnames)
#(ly:parser-set-note-names parser dodecaPitchNames)
\layout {
\context {
\Score
\override StaffSymbol #'line-positions = #'(-5 -3 0 2 4)
% hack to suppress ledger line, seems to have a lower limit
\override StaffSymbol #'ledger-line-thickness = #'(0.0006 . 0)
}
}
\score{
\new Staff
\relative c' {
c d e f g a b c
c, cs d ds e f fs g gs a as b c1
c4 b bf a af g gf f e ef d df c1
c4 cqs cs dqf d dqs ds eqf e eqs f fqs fs gqf g gqs gs aqf a aqs as bqf b bqs c1
}
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Towards a new pitch representation
On 12/30/10 3:55 PM, Felipe Gonçalves Assis felipeg.as...@gmail.com wrote: Hi Carl, Hi, Felipe. I've looked at your patch, but I'm having a bit of trouble seeing how the patch resolves the issues that are identified in issue 1278. I must admit that i've not yet fully understood Hans's emails on issue 1278. How do your new two-element alterations improve the situation? You don't need to go back to those emails. I hope the attachment in my last email can help. But for a simple example of how my patch works, when you type, e.g., ciseh' in a LilyPond input file, this is mapped to a pitch that has as alteration (1 . -1), meaning one semitone minus one quarter-tone, which might then be typeset as a sharp with a down-arrow. Are you using a two-element list, or a cons cell? The two are not the same. I seem to remember looking in the code, and seeing scm_cadr calls, which implies that your alterations would be (1 -1), not (1 . -1). For (1 . -1), you'd get the 1 with car, and the -1 with cdr. For (1 -1), the car is 1, and the cdr is (-1), or (-1 . ()), so you need cadr to get the -1. If we are going to move to a list for alterations, the list should probably be rationals, rather than integers, in order to be most general. Thus it should most likely be (1/2 -1/4), rather than (1 -1). Alternatively, you will need a property somewhere which is a list of the base units for each alteration, so that an alteration would be (1 -1), and the alterationMagnitude would be (1/2 1/4). In the current patch, you force all alterations to be lists (or cons cells, whichever you have implemented). This will break lots of old scores. It would be cleaner to allow alterations to be numbers (as they were in the past) or lists. Then the old code would work. Otherwise, you'll need to make a convert-ly rule which may be a bit tricky. I think that as long as you *allow* but don't require the extended pitch representation, it's likely to be very well accepted. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Towards a new pitch representation
Carl Sorensen c_soren...@byu.edu writes: If we are going to move to a list for alterations, the list should probably be rationals, rather than integers, in order to be most general. Thus it should most likely be (1/2 -1/4), rather than (1 -1). In that case, it would appear that alteration as a separate concept could be eliminated, and instead of pitch x with alteration (y z ...), we could just write (x y z ...). It is just a pity that x is not (logarithmically) equispaced in physical pitch. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
