Re: 48 and 72 ET
On 10/02/2017 04:47, Thomas Richter wrote: > I wrote an extension for 72ET "Ekmelily": > http://www.ekmelic-music.org/en/extra/ekmelily.htm > It uses by default ins own font (Ekmelos) but it should work with e.g. > Bravura, too. > Thanks, Thomas. It looks like excellent work. It should be merged into LilyPond. Also LilyPond should improve its default font to work with it. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
> On 10 Feb 2017, at 10:58, David Kastrup wrote: > > Hans Åberg writes: > >>> On 10 Feb 2017, at 10:24, David Kastrup wrote: >>> >>> Hans Åberg writes: >>> > On 10 Feb 2017, at 00:39, msk...@ansuz.sooke.bc.ca wrote: > > On Fri, 10 Feb 2017, David Kastrup wrote: >> enthused. Why wouldn't we want to have best practices pointed out and >> promoted on the user list? > > Best practices do not include attacking other list users. It is the human interface part that is amiss. >>> >>> Don't hold your breath for a timely revamp. >> >> So then you'll have to accept that people don't use convert-ly. :-) > > I don't _deny_ that people don't use convert-ly but I don't need to > _accept_ it. Where would be the point in any work if you'll instead > "have to accept" that the work isn't done before you start with it? You don't have to accept that the sun is rising every day, but it won't change a thing. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
Hans Åberg writes: >> On 10 Feb 2017, at 10:24, David Kastrup wrote: >> >> Hans Åberg writes: >> On 10 Feb 2017, at 00:39, msk...@ansuz.sooke.bc.ca wrote: On Fri, 10 Feb 2017, David Kastrup wrote: > enthused. Why wouldn't we want to have best practices pointed out and > promoted on the user list? Best practices do not include attacking other list users. >>> >>> It is the human interface part that is amiss. >> >> Don't hold your breath for a timely revamp. > > So then you'll have to accept that people don't use convert-ly. :-) I don't _deny_ that people don't use convert-ly but I don't need to _accept_ it. Where would be the point in any work if you'll instead "have to accept" that the work isn't done before you start with it? -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
Am 09.02.2017 um 20:18 schrieb Bernardo Barros: Hello, Quarter-tones (24ET) work very well and use the most used symbols. Is there any implementation of eighth-tone (48ET) with arrows for the 8th-tone alterations, or even better, 72ET? I know "makam.ly" could be a good start, I'm just wondering if anyone has done it already. Thank you! I wrote an extension for 72ET "Ekmelily": http://www.ekmelic-music.org/en/extra/ekmelily.htm It uses by default ins own font (Ekmelos) but it should work with e.g. Bravura, too. Best, Thomas ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
> On 10 Feb 2017, at 10:24, David Kastrup wrote: > > Hans Åberg writes: > >>> On 10 Feb 2017, at 00:39, msk...@ansuz.sooke.bc.ca wrote: >>> >>> On Fri, 10 Feb 2017, David Kastrup wrote: enthused. Why wouldn't we want to have best practices pointed out and promoted on the user list? >>> >>> Best practices do not include attacking other list users. >> >> It is the human interface part that is amiss. > > Don't hold your breath for a timely revamp. So then you'll have to accept that people don't use convert-ly. :-) ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
> On 10 Feb 2017, at 10:22, David Kastrup wrote: > > Hans Åberg writes: > >>> On 10 Feb 2017, at 00:35, David Kastrup wrote: >>> >>> Hans Åberg writes: >>> > On 10 Feb 2017, at 00:16, David Kastrup wrote: > > So is there any reason people don't use convert-ly when upgrading to > a newer version? For libraries, you would want to keep track of the changes, but running convert-ly and do a diff is a good suggestion. >>> >>> convert-ly -d inserts an updated \version header. >> >> You wouldn't want to do that with library headers, in case something >> goes wrong. Better to create a separate file, and check file dates, as >> in a Makefile. >> Though doing it by hand was quicker, as I remembered the issue and which files needed to be fixed. >>> >>> How does _this_ "keep track of the changes"? Maybe you consider your >>> biological memory part of the data on your computer? >> >> I cannot parse this. > > You said "you would want to keep track of the changes" as a reason to do > changes manually rather than by convert-ly. I tried reading some sense > into that statement but apparently we have very little common ground > regarding what we consider making sense. See the letter from Urs Liska, how he works. It is the human brain that makes sure things are correct. Also see the letter by Graham Breed: it is great that convert-ly can do the job. But also see the letter by Simon Albrecht: convert-ly does not always do it right. So it is good to make that sure, especially in a library. Even though it could do it in this case, as you found out, I did not need it, and in the past, a very long time ago, I think that convert-ly failed, and I haven't needed it since. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
> On 10 Feb 2017, at 04:20, Bernardo Barros wrote: > > On 09/02/2017 17:22, Hans Åberg wrote: > >> 1. >> https://secure2.storegate.com/Shares/Home.aspx?ShareID=35e0b920-6910-4e4f-8340-7d8290115dda > thank you! Let me know if it works! ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
> On 10 Feb 2017, at 00:34, Urs Liska wrote: > > Am 10.02.2017 um 00:22 schrieb Hans Åberg: >>> So is there any reason people don't use convert-ly when upgrading to a >>> newer version? >>> >> For libraries, you would want to keep track of the changes, but running >> convert-ly and do a diff is a good suggestion. Though doing it by hand was >> quicker, as I remembered the issue and which files needed to be fixed. >> >> In general, though, perhaps people maybe do not think or know about it, so >> the process might be automated. >> >> > > When maintaining libraries one should want to make them compatible with > multiple LilyPond versions, IMO at least with the current stable and devel > version, but depending on the use case and target audience one might even > support the previous stable release. > In order to be able to do that in openLilyLib I created the version > comparison operators/predicates > (https://github.com/openlilylib/oll-core/blob/master/internal/lilypond-version-predicates.scm) > which make it easy to write switches based on the currently run LilyPond > version. > > I intend to create a patch to include this functionality into LilyPond, but > so far I'm not really sure *where* these functions should be defined and > where they could adequately be documented. For regular.ly, Graham made it originally for an earlier LilyPond version only. I then was able to make it for latest LilyPond, but not updating it. But now, it works for latest LilyPond again. So there a certain span of versions, here. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
Hans Åberg writes: >> On 10 Feb 2017, at 00:39, msk...@ansuz.sooke.bc.ca wrote: >> >> On Fri, 10 Feb 2017, David Kastrup wrote: >>> enthused. Why wouldn't we want to have best practices pointed out and >>> promoted on the user list? >> >> Best practices do not include attacking other list users. > > It is the human interface part that is amiss. Don't hold your breath for a timely revamp. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
> On 10 Feb 2017, at 00:55, Simon Albrecht wrote: > > On 10.02.2017 00:19, Hans Åberg wrote: >> If LilyPond knows how to run the code via convert-ly, why does it not do it? > > LilyPond itself doesn’t change the code it is reading. convert-ly is a > separate Python script. > It might be a valid feature request, though, to have a command-line option > which makes LilyPond call convert-ly, if the \version statement points to an > older version, and then read the resulting code. If a .ly file is outdated, LilyPond might run convert-ly to create a new .lyo file, if it not already exists and is newer than the original (as in a Makefile). Then run the .lyo file instead if it is newer. > That would leave some things to be designed though, e.g. what would happen if > convert-ly issues ‘Not smart enough to update…’ – which happens? Then one would get an error message, as if there was only a direct compile. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
Hans Åberg writes: >> On 10 Feb 2017, at 00:35, David Kastrup wrote: >> >> Hans Åberg writes: >> On 10 Feb 2017, at 00:16, David Kastrup wrote: So is there any reason people don't use convert-ly when upgrading to a newer version? >>> >>> For libraries, you would want to keep track of the changes, but >>> running convert-ly and do a diff is a good suggestion. >> >> convert-ly -d inserts an updated \version header. > > You wouldn't want to do that with library headers, in case something > goes wrong. Better to create a separate file, and check file dates, as > in a Makefile. > >>> Though doing it by hand was quicker, as I remembered the issue and >>> which files needed to be fixed. >> >> How does _this_ "keep track of the changes"? Maybe you consider your >> biological memory part of the data on your computer? > > I cannot parse this. You said "you would want to keep track of the changes" as a reason to do changes manually rather than by convert-ly. I tried reading some sense into that statement but apparently we have very little common ground regarding what we consider making sense. >> It's a common fallacy of young programmers that may take a few decades >> to cure. > > Nor this. Basically the same idea. Young programmers don't need to write comment or documentation since "it's all in their heads" where they keep track of changes. But since that apparently wasn't what you were getting at, never mind. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
> On 10 Feb 2017, at 00:39, msk...@ansuz.sooke.bc.ca wrote: > > On Fri, 10 Feb 2017, David Kastrup wrote: >> enthused. Why wouldn't we want to have best practices pointed out and >> promoted on the user list? > > Best practices do not include attacking other list users. It is the human interface part that is amiss. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
> On 10 Feb 2017, at 00:35, David Kastrup wrote: > > Hans Åberg writes: > >>> On 10 Feb 2017, at 00:16, David Kastrup wrote: >>> >>> So is there any reason people don't use convert-ly when upgrading to >>> a newer version? >> >> For libraries, you would want to keep track of the changes, but >> running convert-ly and do a diff is a good suggestion. > > convert-ly -d inserts an updated \version header. You wouldn't want to do that with library headers, in case something goes wrong. Better to create a separate file, and check file dates, as in a Makefile. >> Though doing it by hand was quicker, as I remembered the issue and >> which files needed to be fixed. > > How does _this_ "keep track of the changes"? Maybe you consider your > biological memory part of the data on your computer? I cannot parse this. > It's a common fallacy of young programmers that may take a few decades > to cure. Nor this. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
Graham Breed writes: > It's unfortunate that my library is out of date. It's good that > convert-ly fixes it. One issue with this is that libraries (at least > the way I use them, which may also be out of date) don't declare the > Lilypond version. It's in the including score file and if the > included file also declares a version there is (or was) an error. % \version "2.19.28" should work fine. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
Simon Albrecht writes: > On 10.02.2017 00:19, Hans Åberg wrote: >> If LilyPond knows how to run the code via convert-ly, why does it not do it? > > LilyPond itself doesn’t change the code it is reading. convert-ly is a > separate Python script. > It might be a valid feature request, though, to have a command-line > option which makes LilyPond call convert-ly, if the \version statement > points to an older version, and then read the resulting code. > That would leave some things to be designed though, e.g. what would > happen if convert-ly issues ‘Not smart enough to update…’ – which > happens? The problem is more that point-and-click and error messages no longer correspond to the actual source code. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
I'm answering the whole thread here. You should be able to do 48 ET with the standard Lilypond font. You can, for example, start with 12 ET and add arrowed accidentals to get 12*3=36. Then add 12 quartertones to get 48 ET. All you need is to define new note names. I found the font wasn't good enough for 72 ET, and I don't think that's changed. Which is a shame, because it should be easy for somebody familiar with Lilypond's font workflow to add the arrows to quartertone symbols and that's all you need to get 72 (24*3). I did find enough symbols for 60-ET and I use 60 and 72 as output formats for tripod notation as it happens. From what I remember, there are a lot of flat symbols that can be interpreted in different ways, but not so many sharps. It would be nice for regular.ly to be included in the standard distribution, but that's irrelevant here. What regular.ly does is retune the note names for a different size of fifth. 48 and 72 ET keep the same fifth as 12 ET. What you need is a new "language" for the note names and appropriate glyphs. I have files to support arbitrary fonts but there are issues with the spacing. I have an experimental branch for Extended Helmholtz-Ellis JI Pitch Notation with Bravura but it doesn't solve any problems with the dedicated HE font. (This is the "eheji" branch in the microlily repository.) This particular notation always needs "text" fonts because it builds glyphs into strings to make the accidentals. The standard accidental code only uses one glyph at a time which is good enough for 72 but not Helmholtz-Ellis. Still, having Bravura blessed as a Lilypond font would be both a good thing and quite a bit of work. It's unfortunate that my library is out of date. It's good that convert-ly fixes it. One issue with this is that libraries (at least the way I use them, which may also be out of date) don't declare the Lilypond version. It's in the including score file and if the included file also declares a version there is (or was) an error. Anybody can fork the repository and keep it up do date. I can add the license of your choice if you care about such things. Graham ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
On 09/02/2017 17:22, Hans Åberg wrote: > 1. > https://secure2.storegate.com/Shares/Home.aspx?ShareID=35e0b920-6910-4e4f-8340-7d8290115dda > > thank you! ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
On 10.02.2017 00:19, Hans Åberg wrote: If LilyPond knows how to run the code via convert-ly, why does it not do it? LilyPond itself doesn’t change the code it is reading. convert-ly is a separate Python script. It might be a valid feature request, though, to have a command-line option which makes LilyPond call convert-ly, if the \version statement points to an older version, and then read the resulting code. That would leave some things to be designed though, e.g. what would happen if convert-ly issues ‘Not smart enough to update…’ – which happens? Best, Simon ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
On Fri, 10 Feb 2017, David Kastrup wrote: > enthused. Why wouldn't we want to have best practices pointed out and > promoted on the user list? Best practices do not include attacking other list users. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
Hans Åberg writes: >> On 10 Feb 2017, at 00:16, David Kastrup wrote: >> >> So is there any reason people don't use convert-ly when upgrading to >> a newer version? > > For libraries, you would want to keep track of the changes, but > running convert-ly and do a diff is a good suggestion. convert-ly -d inserts an updated \version header. > Though doing it by hand was quicker, as I remembered the issue and > which files needed to be fixed. How does _this_ "keep track of the changes"? Maybe you consider your biological memory part of the data on your computer? It's a common fallacy of young programmers that may take a few decades to cure. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
Am 10.02.2017 um 00:22 schrieb Hans Åberg: >> So is there any reason people don't use convert-ly when upgrading to a >> newer version? > For libraries, you would want to keep track of the changes, but running > convert-ly and do a diff is a good suggestion. Though doing it by hand was > quicker, as I remembered the issue and which files needed to be fixed. > > In general, though, perhaps people maybe do not think or know about it, so > the process might be automated. > When maintaining libraries one should want to make them compatible with multiple LilyPond versions, IMO at least with the current stable and devel version, but depending on the use case and target audience one might even support the previous stable release. In order to be able to do that in openLilyLib I created the version comparison operators/predicates (https://github.com/openlilylib/oll-core/blob/master/internal/lilypond-version-predicates.scm) which make it easy to write switches based on the currently run LilyPond version. I intend to create a patch to include this functionality into LilyPond, but so far I'm not really sure *where* these functions should be defined and where they could adequately be documented. Urs -- u...@openlilylib.org https://openlilylib.org http://lilypondblog.org ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
msk...@ansuz.sooke.bc.ca writes: > On Thu, 9 Feb 2017, David Kastrup wrote: >> I'll stick with my "that doesn't even make sense" verdict, thank you >> very much. > > Don't ask the question if you're going to attack the answer. When I ask for a reason why one would _not_ use documented best practices (which by the way required days of work to implement and test), chances are that my last contribution will not end up being enthused. Why wouldn't we want to have best practices pointed out and promoted on the user list? > Your contributions to LilyPond development don't excuse you from > practicing basic civility. I have yet to see a reason for not using convert-ly when upgrading LilyPond that _does_ make any sense. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
> On 10 Feb 2017, at 00:16, David Kastrup wrote: > > Hans Åberg writes: > >>> On 9 Feb 2017, at 23:53, David Kastrup wrote: >>> >>> Hans Åberg writes: >>> > On 9 Feb 2017, at 23:44, David Kastrup wrote: > > Hans Åberg writes: > >>> On 9 Feb 2017, at 23:24, David Kastrup wrote: >>> >>> Hans Åberg writes: >>> > On 9 Feb 2017, at 23:10, David Kastrup wrote: > > Hans Åberg writes: > >>> On 9 Feb 2017, at 22:47, Cole Ingraham >>> wrote: >>> >>> I've used Sagittal notation based on http://x31eq.com/lilypond/ >>> before. I don't know if that still works with more recent versions >>> though. Haven't touched it in a while. >> >> I get an error in LilyPond 2.19.45, with an unbound variable >> "parser": >> >> error: GUILE signaled an error for the expression beginning here >> # (ly:parser-set-note-names parser EqualFiftythreePitchNames) >> Unbound variable: parser > > Is there any reason people don't use convert-ly when upgrading to a > newer version? Maybe because it is in some library files. >>> >>> That doesn't even make sense. >> >> The code makes use of three different external libraries. > > So? Why wouldn't you upgrade the libraries when upgrading LilyPond? Those are not my libraries. I updated some, that is hacked them to work, but that was a year ago. >>> >>> And that means that you are not allowed to run convert-ly on them but >>> have to edit them by hand instead? >>> >>> I'll stick with my "that doesn't even make sense" verdict, thank you >>> very much. >> >> Why don't you do it? I have posted the code. So all you have to do is >> to hack it back, as indicated above, > > The code you uploaded is already fixed. Taking regular.ly from > x31eq.com and running convert-ly -ed -f 2.18.0 on it fixes the syntax. > >> and then run convert-ly on them to see if it works. > > It does. > > So is there any reason people don't use convert-ly when upgrading to a > newer version? For libraries, you would want to keep track of the changes, but running convert-ly and do a diff is a good suggestion. Though doing it by hand was quicker, as I remembered the issue and which files needed to be fixed. In general, though, perhaps people maybe do not think or know about it, so the process might be automated. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
> On 10 Feb 2017, at 00:05, msk...@ansuz.sooke.bc.ca wrote: > > On Thu, 9 Feb 2017, David Kastrup wrote: >> I'll stick with my "that doesn't even make sense" verdict, thank you >> very much. > > Don't ask the question if you're going to attack the answer. Your > contributions to LilyPond development don't excuse you from practicing > basic civility. Though it is a good question: why don't people run convert-ly when they know how to fix it by hand? Perhaps the process should be automated somehow. If LilyPond knows how to run the code via convert-ly, why does it not do it? ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
Hans Åberg writes: >> On 9 Feb 2017, at 23:53, David Kastrup wrote: >> >> Hans Åberg writes: >> On 9 Feb 2017, at 23:44, David Kastrup wrote: Hans Åberg writes: >> On 9 Feb 2017, at 23:24, David Kastrup wrote: >> >> Hans Åberg writes: >> On 9 Feb 2017, at 23:10, David Kastrup wrote: Hans Åberg writes: >> On 9 Feb 2017, at 22:47, Cole Ingraham >> wrote: >> >> I've used Sagittal notation based on http://x31eq.com/lilypond/ >> before. I don't know if that still works with more recent versions >> though. Haven't touched it in a while. > > I get an error in LilyPond 2.19.45, with an unbound variable "parser": > > error: GUILE signaled an error for the expression beginning here > # (ly:parser-set-note-names parser EqualFiftythreePitchNames) > Unbound variable: parser Is there any reason people don't use convert-ly when upgrading to a newer version? >>> >>> Maybe because it is in some library files. >> >> That doesn't even make sense. > > The code makes use of three different external libraries. So? Why wouldn't you upgrade the libraries when upgrading LilyPond? >>> >>> Those are not my libraries. I updated some, that is hacked them to >>> work, but that was a year ago. >> >> And that means that you are not allowed to run convert-ly on them but >> have to edit them by hand instead? >> >> I'll stick with my "that doesn't even make sense" verdict, thank you >> very much. > > Why don't you do it? I have posted the code. So all you have to do is > to hack it back, as indicated above, The code you uploaded is already fixed. Taking regular.ly from x31eq.com and running convert-ly -ed -f 2.18.0 on it fixes the syntax. > and then run convert-ly on them to see if it works. It does. So is there any reason people don't use convert-ly when upgrading to a newer version? -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
On Thu, 9 Feb 2017, David Kastrup wrote: > I'll stick with my "that doesn't even make sense" verdict, thank you > very much. Don't ask the question if you're going to attack the answer. Your contributions to LilyPond development don't excuse you from practicing basic civility. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
> On 9 Feb 2017, at 23:53, David Kastrup wrote: > > Hans Åberg writes: > >>> On 9 Feb 2017, at 23:44, David Kastrup wrote: >>> >>> Hans Åberg writes: >>> > On 9 Feb 2017, at 23:24, David Kastrup wrote: > > Hans Åberg writes: > >>> On 9 Feb 2017, at 23:10, David Kastrup wrote: >>> >>> Hans Åberg writes: >>> > On 9 Feb 2017, at 22:47, Cole Ingraham > wrote: > > I've used Sagittal notation based on http://x31eq.com/lilypond/ > before. I don't know if that still works with more recent versions > though. Haven't touched it in a while. I get an error in LilyPond 2.19.45, with an unbound variable "parser": error: GUILE signaled an error for the expression beginning here # (ly:parser-set-note-names parser EqualFiftythreePitchNames) Unbound variable: parser >>> >>> Is there any reason people don't use convert-ly when upgrading to a >>> newer version? >> >> Maybe because it is in some library files. > > That doesn't even make sense. The code makes use of three different external libraries. >>> >>> So? Why wouldn't you upgrade the libraries when upgrading LilyPond? >> >> Those are not my libraries. I updated some, that is hacked them to >> work, but that was a year ago. > > And that means that you are not allowed to run convert-ly on them but > have to edit them by hand instead? > > I'll stick with my "that doesn't even make sense" verdict, thank you > very much. Why don't you do it? I have posted the code. So all you have to do is to hack it back, as indicated above, and then run convert-ly on them to see if it works. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
Hans Åberg writes: >> On 9 Feb 2017, at 23:44, David Kastrup wrote: >> >> Hans Åberg writes: >> On 9 Feb 2017, at 23:24, David Kastrup wrote: Hans Åberg writes: >> On 9 Feb 2017, at 23:10, David Kastrup wrote: >> >> Hans Åberg writes: >> On 9 Feb 2017, at 22:47, Cole Ingraham wrote: I've used Sagittal notation based on http://x31eq.com/lilypond/ before. I don't know if that still works with more recent versions though. Haven't touched it in a while. >>> >>> I get an error in LilyPond 2.19.45, with an unbound variable "parser": >>> >>> error: GUILE signaled an error for the expression beginning here >>> # (ly:parser-set-note-names parser EqualFiftythreePitchNames) >>> Unbound variable: parser >> >> Is there any reason people don't use convert-ly when upgrading to a >> newer version? > > Maybe because it is in some library files. That doesn't even make sense. >>> >>> The code makes use of three different external libraries. >> >> So? Why wouldn't you upgrade the libraries when upgrading LilyPond? > > Those are not my libraries. I updated some, that is hacked them to > work, but that was a year ago. And that means that you are not allowed to run convert-ly on them but have to edit them by hand instead? I'll stick with my "that doesn't even make sense" verdict, thank you very much. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
> On 9 Feb 2017, at 23:44, David Kastrup wrote: > > Hans Åberg writes: > >>> On 9 Feb 2017, at 23:24, David Kastrup wrote: >>> >>> Hans Åberg writes: >>> > On 9 Feb 2017, at 23:10, David Kastrup wrote: > > Hans Åberg writes: > >>> On 9 Feb 2017, at 22:47, Cole Ingraham wrote: >>> >>> I've used Sagittal notation based on http://x31eq.com/lilypond/ >>> before. I don't know if that still works with more recent versions >>> though. Haven't touched it in a while. >> >> I get an error in LilyPond 2.19.45, with an unbound variable "parser": >> >> error: GUILE signaled an error for the expression beginning here >> # (ly:parser-set-note-names parser EqualFiftythreePitchNames) >> Unbound variable: parser > > Is there any reason people don't use convert-ly when upgrading to a > newer version? Maybe because it is in some library files. >>> >>> That doesn't even make sense. >> >> The code makes use of three different external libraries. > > So? Why wouldn't you upgrade the libraries when upgrading LilyPond? Those are not my libraries. I updated some, that is hacked them to work, but that was a year ago. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
Hans Åberg writes: >> On 9 Feb 2017, at 23:24, David Kastrup wrote: >> >> Hans Åberg writes: >> On 9 Feb 2017, at 23:10, David Kastrup wrote: Hans Åberg writes: >> On 9 Feb 2017, at 22:47, Cole Ingraham wrote: >> >> I've used Sagittal notation based on http://x31eq.com/lilypond/ >> before. I don't know if that still works with more recent versions >> though. Haven't touched it in a while. > > I get an error in LilyPond 2.19.45, with an unbound variable "parser": > > error: GUILE signaled an error for the expression beginning here > # (ly:parser-set-note-names parser EqualFiftythreePitchNames) > Unbound variable: parser Is there any reason people don't use convert-ly when upgrading to a newer version? >>> >>> Maybe because it is in some library files. >> >> That doesn't even make sense. > > The code makes use of three different external libraries. So? Why wouldn't you upgrade the libraries when upgrading LilyPond? -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
> On 9 Feb 2017, at 23:24, David Kastrup wrote: > > Hans Åberg writes: > >>> On 9 Feb 2017, at 23:10, David Kastrup wrote: >>> >>> Hans Åberg writes: >>> > On 9 Feb 2017, at 22:47, Cole Ingraham wrote: > > I've used Sagittal notation based on http://x31eq.com/lilypond/ > before. I don't know if that still works with more recent versions > though. Haven't touched it in a while. I get an error in LilyPond 2.19.45, with an unbound variable "parser": error: GUILE signaled an error for the expression beginning here # (ly:parser-set-note-names parser EqualFiftythreePitchNames) Unbound variable: parser >>> >>> Is there any reason people don't use convert-ly when upgrading to a >>> newer version? >> >> Maybe because it is in some library files. > > That doesn't even make sense. The code makes use of three different external libraries. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
Hans Åberg writes: >> On 9 Feb 2017, at 23:10, David Kastrup wrote: >> >> Hans Åberg writes: >> On 9 Feb 2017, at 22:47, Cole Ingraham wrote: I've used Sagittal notation based on http://x31eq.com/lilypond/ before. I don't know if that still works with more recent versions though. Haven't touched it in a while. >>> >>> I get an error in LilyPond 2.19.45, with an unbound variable "parser": >>> >>> error: GUILE signaled an error for the expression beginning here >>> # (ly:parser-set-note-names parser EqualFiftythreePitchNames) >>> Unbound variable: parser >> >> Is there any reason people don't use convert-ly when upgrading to a >> newer version? > > Maybe because it is in some library files. That doesn't even make sense. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
> On 9 Feb 2017, at 23:13, Bernardo Barros wrote: > > On 09/02/2017 16:46, Hans Åberg wrote: >> Yes, I have. I use it for E53 Helmholtz-Ellis notation, which >> requires the Bravura font... > > Have you publish this code somewhere? I just put it up at [1]. You need to have the Bravura font installed somewhere so that LilyPond can find it. On MacOS, it suffices as System font. Then go to the directory, and do 'lilypond maqam.ly' to get the Arabic maqam in E53 Helmholtz-Ellis notation, or uncomment in the file regularE53.ly and compile it to see available notes. 1. https://secure2.storegate.com/Shares/Home.aspx?ShareID=35e0b920-6910-4e4f-8340-7d8290115dda ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
On 09/02/2017 16:46, Hans Åberg wrote: > Yes, I have. I use it for E53 Helmholtz-Ellis notation, which > requires the Bravura font... Have you publish this code somewhere? ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
Hans Åberg writes: >> On 9 Feb 2017, at 22:47, Cole Ingraham wrote: >> >> I've used Sagittal notation based on http://x31eq.com/lilypond/ >> before. I don't know if that still works with more recent versions >> though. Haven't touched it in a while. > > I get an error in LilyPond 2.19.45, with an unbound variable "parser": > > error: GUILE signaled an error for the expression beginning here > # (ly:parser-set-note-names parser EqualFiftythreePitchNames) > Unbound variable: parser Is there any reason people don't use convert-ly when upgrading to a newer version? -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
> On 9 Feb 2017, at 23:10, David Kastrup wrote: > > Hans Åberg writes: > >>> On 9 Feb 2017, at 22:47, Cole Ingraham wrote: >>> >>> I've used Sagittal notation based on http://x31eq.com/lilypond/ >>> before. I don't know if that still works with more recent versions >>> though. Haven't touched it in a while. >> >> I get an error in LilyPond 2.19.45, with an unbound variable "parser": >> >> error: GUILE signaled an error for the expression beginning here >> # (ly:parser-set-note-names parser EqualFiftythreePitchNames) >> Unbound variable: parser > > Is there any reason people don't use convert-ly when upgrading to a > newer version? Maybe because it is in some library files. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
> On 9 Feb 2017, at 23:00, Hans Åberg wrote: > > >> On 9 Feb 2017, at 22:47, Cole Ingraham wrote: >> >> I've used Sagittal notation based on http://x31eq.com/lilypond/ before. I >> don't know if that still works with more recent versions though. Haven't >> touched it in a while. > > I get an error in LilyPond 2.19.45, with an unbound variable "parser": > > error: GUILE signaled an error for the expression beginning here > # (ly:parser-set-note-names parser EqualFiftythreePitchNames) > Unbound variable: parser I go it working: just take away "parser". Some change they made in the LilyPond syntax. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
> On 9 Feb 2017, at 22:47, Cole Ingraham wrote: > > I've used Sagittal notation based on http://x31eq.com/lilypond/ before. I > don't know if that still works with more recent versions though. Haven't > touched it in a while. I get an error in LilyPond 2.19.45, with an unbound variable "parser": error: GUILE signaled an error for the expression beginning here # (ly:parser-set-note-names parser EqualFiftythreePitchNames) Unbound variable: parser ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
> On 9 Feb 2017, at 22:47, Bernardo Barros wrote: > > On 09/02/2017 16:29, Bernardo Barros wrote: >> It indeed looks like LilyPond default font doesn't have all the >> necessary glyphs. > > You're right, SMuFL implements Sims’s accidental system for 72-ET, and > "Extended Stein-Zimmermann" which could be used for 48-ET. SMuFL seems to be rather comprehensive. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
> On 9 Feb 2017, at 22:47, Cole Ingraham wrote: > > I've used Sagittal notation based on http://x31eq.com/lilypond/ before. I > don't know if that still works with more recent versions though. Haven't > touched it in a while. I was able to tweak regular.ly so it worked on latest LilyPond, but also that was some time ago. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
I've used Sagittal notation based on http://x31eq.com/lilypond/ before. I don't know if that still works with more recent versions though. Haven't touched it in a while. -Cole On Thu, Feb 9, 2017 at 4:29 PM, Bernardo Barros wrote: > On 09/02/2017 14:59, Hans Åberg wrote: > > Multiples of 12 are straightforward, though LilyPond glyphs are > > limited. For other ETs, use Graham Breed's regular.ly. More glyphs > > can be gotten using SMuFL.org with OpenLilyPond. > > Thank you for your reply, Hans > > Yes, it looks like all the tools are already on the table. > > But no one has used regular.ly in conjunction with Bravura/SMuFL font? > It indeed looks like LilyPond default font doesn't have all the > necessary glyphs. > > Maybe if regular.ly is included in OpenLilyLib, one could easily combine > both and implement a new extension package in OpenLilyLib for 48ET and > 72ET. > > ___ > lilypond-user mailing list > lilypond-user@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-user > -- DMA Music Composition - University of Colorado at Boulder MFA Electronic Music and Recording Media - Mills College BM Music Composition - University of the Pacific http://www.coleingraham.com http://www.glitchlich.com https://soundcloud.com/coledingraham http://www.facebook.com/coleingrahammusic ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
On 09/02/2017 16:29, Bernardo Barros wrote: > It indeed looks like LilyPond default font doesn't have all the > necessary glyphs. You're right, SMuFL implements Sims’s accidental system for 72-ET, and "Extended Stein-Zimmermann" which could be used for 48-ET. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
> On 9 Feb 2017, at 22:29, Bernardo Barros wrote: > > On 09/02/2017 14:59, Hans Åberg wrote: >> Multiples of 12 are straightforward, though LilyPond glyphs are >> limited. For other ETs, use Graham Breed's regular.ly. More glyphs >> can be gotten using SMuFL.org with OpenLilyPond. > > Thank you for your reply, Hans > > Yes, it looks like all the tools are already on the table. > > But no one has used regular.ly in conjunction with Bravura/SMuFL font? Yes, I have. I use it for E53 Helmholtz-Ellis notation, which requires the Bravura font... > It indeed looks like LilyPond default font doesn't have all the > necessary glyphs. ...as you note, LilyPond doesn't have enough glyphs. > Maybe if regular.ly is included in OpenLilyLib, one could easily combine > both and implement a new extension package in OpenLilyLib for 48ET and 72ET. It was suggested to have it in LilyPond, but it did not happen. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
On 09/02/2017 14:59, Hans Åberg wrote: > Multiples of 12 are straightforward, though LilyPond glyphs are > limited. For other ETs, use Graham Breed's regular.ly. More glyphs > can be gotten using SMuFL.org with OpenLilyPond. Thank you for your reply, Hans Yes, it looks like all the tools are already on the table. But no one has used regular.ly in conjunction with Bravura/SMuFL font? It indeed looks like LilyPond default font doesn't have all the necessary glyphs. Maybe if regular.ly is included in OpenLilyLib, one could easily combine both and implement a new extension package in OpenLilyLib for 48ET and 72ET. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
> On 9 Feb 2017, at 22:18, Simon Albrecht wrote: > > On 09.02.2017 20:59, Hans Åberg wrote: >> Multiples of 12 are straightforward, though LilyPond glyphs are limited. For >> other ETs, use Graham Breed's regular.ly. More glyphs can be gotten using >> SMuFL.org with OpenLilyPond. > > read: openLilyLib, right? Right. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
On 09.02.2017 20:59, Hans Åberg wrote: Multiples of 12 are straightforward, though LilyPond glyphs are limited. For other ETs, use Graham Breed's regular.ly. More glyphs can be gotten using SMuFL.org with OpenLilyPond. read: openLilyLib, right? Best, Simon ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 48 and 72 ET
> On 9 Feb 2017, at 20:18, Bernardo Barros wrote: > Quarter-tones (24ET) work very well and use the most used symbols. > > Is there any implementation of eighth-tone (48ET) with arrows for the > 8th-tone alterations, or even better, 72ET? Multiples of 12 are straightforward, though LilyPond glyphs are limited. For other ETs, use Graham Breed's regular.ly. More glyphs can be gotten using SMuFL.org with OpenLilyPond. So what exactly do you want? > I know "makam.ly" could be a good start, I'm just wondering if anyone > has done it already. If you want to transpose, the implementation is incorrect. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
48 and 72 ET
Hello, Quarter-tones (24ET) work very well and use the most used symbols. Is there any implementation of eighth-tone (48ET) with arrows for the 8th-tone alterations, or even better, 72ET? I know "makam.ly" could be a good start, I'm just wondering if anyone has done it already. Thank you! ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
