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