Re: How should tupletSpannerDuration actually work?

On 12 Jan 2013, at 12:53, David Kastrup d...@gnu.org wrote: Phil Holmes m...@philholmes.net writes: I have a hard time considering the output of \version 2.16.0 \relative c' { \set tupletSpannerDuration = #(ly:make-moment 1 2) \times 2/3 { c8 d e f g a g f e d c d } \set

Re: LilyPond & Guile 2

> On 22 Jan 2016, at 16:26, Simon Albrecht <simon.albre...@mail.de> wrote: > > On 22.01.2016 16:23, David Kastrup wrote: >> Hans Åberg <haber...@telia.com> writes: >> >>> What are the technical problems when trying to integrate Guile 2.0 >>&g

LilyPond & Guile 2

What are the technical problems when trying to integrate Guile 2.0 into LilyPond? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: midi2ly will not launch on OSX 10.11.4

> On 13 Apr 2016, at 23:20, Simon Albrecht <simon.albre...@mail.de> wrote: > > On 13.04.2016 23:13, Hans Åberg wrote: >>> On 13 Apr 2016, at 22:56, David Kastrup <d...@gnu.org> wrote: >>>>>> What makes you think that i’m doing that ? >>>&g

Re: midi2ly will not launch on OSX 10.11.4

> On 13 Apr 2016, at 23:19, v...@klankschap.nl wrote: > > Just tried to report an issue. > Sorry for being the messenger, it won’t happen again. > What ever it is, it is not my cup of tea. > Best regards, and good luck with the project. Don’t worry about it. When doing a “Reply-To”, the mail

Re: midi2ly will not launch on OSX 10.11.4

> > On 13 Apr 2016, at 22:18, David Kastrup wrote: > > v...@klankschap.nl writes: > >>> On 13 Apr 2016, at 20:49, Simon Albrecht wrote: >>> >>> On 13.04.2016 18:38, Floris van Manen wrote: midi2ly does not launch on OSX 10.11.4 >>> >>> That is a

Re: midi2ly will not launch on OSX 10.11.4

> On 13 Apr 2016, at 22:56, David Kastrup wrote: > What makes you think that i’m doing that ? The subject is a new topic. >>> >>> That's why you should not have told your mail program that it is a reply >>> to >> >> Such metadata copied into the mail message is not a

Re: 5027: NR example with bad engraving practice

> On 5 Jan 2017, at 23:16, Simon Albrecht <simon.albre...@mail.de> wrote: > >>> On 04.01.2017 15:01, Hans Åberg wrote: >>>> This is just a quirk of the 4/4 [meter], also mentioned in Hindemith, >>>> "Elementary Training", p. 30. In other

Re: 5027: NR example with bad engraving practice

> On 5 Jan 2017, at 23:55, Simon Albrecht <simon.albre...@mail.de> wrote: > > On 05.01.2017 23:42, Hans Aikema wrote: >>> On 5 Jan 2017, at 23:16, Simon Albrecht <simon.albre...@mail.de> wrote: >>>>> On 04.01.2017 15:01, Hans Åberg wrote: >>

Re: 5027: NR example with bad engraving practice

> On 3 Jan 2017, at 23:57, Simon Albrecht wrote: > I know this is a bit on the edge of being too keen on my part, but I don’t > consider this controversial at all from my engraving experience and knowledge > of current best practice. > > NR 1.2.1.d >

Re: 5027: NR example with bad engraving practice

> On 4 Jan 2017, at 19:58, Simon Albrecht <simon.albre...@mail.de> wrote: > > On 04.01.2017 15:01, Hans Åberg wrote: >> This is just a quirk of the 4/4 [meter], also mentioned in Hindemith, >> "Elementary Training", p. 30. In other words, the note should

Re: Update copyright for 2016/17 files, and script (issue 320390043 by g...@ursliska.de)

> On 23 Mar 2017, at 11:18, Andrew Bernard wrote: > My understanding of copyright is that the date range applies to the > published work as a whole, and does not operate on the granularity of > individual components. I am told there should be all years it has been

Re: Copyright update script

> On 21 Mar 2017, at 13:56, Urs Liska wrote: > So please review this script carefully and look for unintended behaviour… Depending on the setup you have, if the Flex & Bison source files are altered, their generated files might need to be regenerated.

Re: Terminology of baseMoment, beats, groups

> On 11 Nov 2017, at 12:52, Urs Liska wrote: > > > > Am 11.11.2017 um 12:30 schrieb David Kastrup: >> I find "grouping" without "beat" fine. I could have been responsible >> for the terminology in the code (pretty sure I wasn't, but it matches >> the terminology I use

Re: Terminology of baseMoment, beats, groups

> On 11 Nov 2017, at 12:52, Urs Liska wrote: > > > > Am 11.11.2017 um 12:30 schrieb David Kastrup: >> I find "grouping" without "beat" fine. I could have been responsible >> for the terminology in the code (pretty sure I wasn't, but it matches >> the terminology I use

Re: Terminology of baseMoment, beats, groups

> On 11 Nov 2017, at 12:52, Urs Liska wrote: > > > > Am 11.11.2017 um 12:30 schrieb David Kastrup: >> I find "grouping" without "beat" fine. I could have been responsible >> for the terminology in the code (pretty sure I wasn't, but it matches >> the terminology I use

Re: Microrhythm

> On 15 May 2018, at 04:12, Dave Tremblay wrote: > > Thanks a lot! I’m not very proficient with lilypond just yet, but when I have > some time to myself and work with it I’ll go back to this message and try it > out! Thanks! You are welcome. Keep the CC so that

Re: Microrhythm

> On 19 May 2018, at 12:13, Torsten Hämmerle wrote: > > Dave Tremblay wrote >> However, I wonder if it would be possible to make it play, or at least >> display, microrhythms, [...] > > MIDI playback of microrhythms (including interpolation between the two > notated

Re: Rational

> On 23 May 2018, at 00:41, David Kastrup <d...@gnu.org> wrote: > > Hans Åberg <haber...@telia.com> writes: > >>> On 22 May 2018, at 23:28, David Kastrup <d...@gnu.org> wrote: >>> >>> Hans Åberg <haber...@telia.com> writes: >&

Re: Rational

> On 23 May 2018, at 10:39, David Kastrup <d...@gnu.org> wrote: > > Hans Åberg <haber...@telia.com> writes: > >>> On 23 May 2018, at 00:41, David Kastrup <d...@gnu.org> wrote: >>> >>> Hans Åberg <haber...@telia.com> writes: &

Re: Rational

> On 23 May 2018, at 11:04, Werner LEMBERG wrote: > >> The ultimate in self-assertion is to disagree with those that agree >> with you. > > Hans, such remarks aren't helpful. You sound like you are lecturing. > Maybe this is not your intention and you have serious questions – if

Re: Rational

> On 23 May 2018, at 12:20, David Kastrup wrote: > > ... work on "the problem" has moved beyond the > stage where one can just propose a generic solution, everybody slaps his > forehead and gets to work and does what it takes to do. How about using what I suggested and what you

Re: Rational

> On 23 May 2018, at 13:10, David Kastrup <d...@gnu.org> wrote: > > Hans Åberg <haber...@telia.com> writes: > >>> On 23 May 2018, at 12:20, David Kastrup <d...@gnu.org> wrote: >>> >>> ... work on "the problem" has moved

Re: Rational

> On 23 May 2018, at 14:34, David Kastrup <d...@gnu.org> wrote: > > Hans Åberg <haber...@telia.com> writes: > >> I mentioned that the GC supports traditional allocations/deallocation, >> but they must be traced so as to not end up with dead pointers. > &g

Re: Rational

> On 23 May 2018, at 15:46, David Kastrup wrote: > > Try actually reading the code. lily/include/smobs* are not that many > files and nowadays pretty exclusively encapsulate all Scheme-related > memory management. As long you don't have pointers into that, as you suggested with

Re: Rational

> On 22 May 2018, at 22:07, David Kastrup <d...@gnu.org> wrote: > > Hans Åberg <haber...@telia.com> writes: > >>> On 22 May 2018, at 20:45, David Kastrup <d...@gnu.org> wrote: >>> >>> LilyPond's "rational" type should inde

Re: Rational

> On 22 May 2018, at 22:53, David Kastrup wrote: > >>> This was somewhat complicated by some Midi classes being heap-allocated >>> and containing Rational/Moment members: those Midi classes would have to >>> become SCM-connected. I did some work on that, don't remember how >>>

Re: Rational

> On 22 May 2018, at 23:28, David Kastrup <d...@gnu.org> wrote: > > Hans Åberg <haber...@telia.com> writes: > >>> On 22 May 2018, at 22:53, David Kastrup <d...@gnu.org> wrote: >>> >>>>> This was somewhat complicated by some Midi cl

Re: Rational

> On 22 May 2018, at 21:10, Hans Åberg <haber...@telia.com> wrote: > > >> On 22 May 2018, at 20:45, David Kastrup <d...@gnu.org> wrote: >> >> LilyPond's "rational" type should indeed get replaced >> by Guile's rational types which wo

Re: Microrhythm

> On 26 May 2018, at 08:35, metachromatic wrote: > > ... let's calculate the > difference in time twixt a tuplet like 7919/4451 against a tuplet > 7909/4447 over the course of two minutes and 13 seconds of 4/4 time at > a tempo of metronome marking 90: > >The

Re: Microrhythm

> On 26 May 2018, at 08:35, metachromatic wrote: > > ... let's calculate the > difference in time twixt a tuplet like 7919/4451 against a tuplet > 7909/4447 over the course of two minutes and 13 seconds of 4/4 time at > a tempo of metronome marking 90: > > The

Re: Rational

> On 23 May 2018, at 16:15, David Kastrup <d...@gnu.org> wrote: > > Hans Åberg <haber...@telia.com> writes: > >>> On 23 May 2018, at 15:46, David Kastrup <d...@gnu.org> wrote: >>> >>> Try actually reading the code. lily/inclu

Re: Rational

> On 23 May 2018, at 18:12, David Kastrup <d...@gnu.org> wrote: > > Hans Åberg <haber...@telia.com> writes: > >> I ended up using GC_malloc_uncollectable, because it turned out too >> tricky to use malloc. > > This is C++, so we basically end up w

Re: Rational

> On 23 May 2018, at 18:36, David Kastrup <d...@gnu.org> wrote: > > Hans Åberg <haber...@telia.com> writes: > >>> On 23 May 2018, at 18:12, David Kastrup <d...@gnu.org> wrote: >>> >>> Hans Åberg <haber...@telia.com> writes: >&g

Rational

> On 22 May 2018, at 20:45, David Kastrup wrote: > > LilyPond's "rational" type should indeed get replaced > by Guile's rational types which would seriously shift the threshold > where things start breaking apart at the cost of efficiency. > > That's quite a lot of tedious work

Re: Microrhythm

[Adding reference that dropped out.] I used continued fractions; see [1], which gives some useful algorithms. They converge very quickly, and one can refine to a suitable degree. In music, one does not need very large denominators, as the timing quickly becomes fine enough. 1.

Re: Rational

> On 23 May 2018, at 18:58, David Kastrup <d...@gnu.org> wrote: > > Hans Åberg <haber...@telia.com> writes: > >>> On 23 May 2018, at 18:36, David Kastrup <d...@gnu.org> wrote: >>> >>> Hans Åberg <haber...@telia.com> writes: &

Re: Rational

> On 23 May 2018, at 19:32, David Kastrup <d...@gnu.org> wrote: > > Hans Åberg <haber...@telia.com> writes: > >> But scm_malloc does not use GC_malloc_uncollectable, it seems, so it >> too would require explicit markups in order to get internally in >>

Re: Microrhythm

> On 22 May 2018, at 06:01, metachromatic wrote: > Different percentages of microrhythm will require correspondingly > larger tuplets, and, due to the bad design decision to represent > rhythms internally in Lilypond as integers, you'll soon run out of > integers to

Re: Error Messages in wrong language

> On 26 Jan 2018, at 16:05, Joseph Austin wrote: > > Hans, > From Mac terminal, I run the locale command and get the following: > joemacbook:~ josephaustin$ locale > LANG="en_US.UTF-8" > LC_COLLATE="en_US.UTF-8" > LC_CTYPE="en_US.UTF-8" > LC_MESSAGES="en_US.UTF-8" >

Re: Error Messages in wrong language

> On 24 Jan 2018, at 18:46, David Kastrup wrote: > > Joseph Austin writes: > >> I asked this question on the user forum but got no answers. >> >> My lilypond error messages are in Spanish, but my language is English. >> I do have the Spanish keyboard

Re: Error Messages in wrong language

> On 24 Jan 2018, at 18:46, David Kastrup wrote: > > Joseph Austin writes: > >> I asked this question on the user forum but got no answers. >> >> My lilypond error messages are in Spanish, but my language is English. >> I do have the Spanish keyboard

Re: Error Messages in wrong language

> On 27 Jan 2018, at 17:51, Joseph Austin wrote: > > When I run from Terminal, I get messages in English. > When I run through Frescobaldi, I get messages in English > > When I run by clicking the app name in the Applications folder, I get > messages in Spanish, > even

Re: Add and use a Transform data type (issue 344970043 by d...@gnu.org)

> On 21 Jun 2018, at 00:30, nine.fierce.ball...@gmail.com wrote: > Maybe a function would help: > >Transform make_transform(const Transform *t) > { >return t ? Transform (*t) : Transform (); > } > > You could also do it as a constructor, if you prefer its syntax and >

Re: Add and use a Transform data type (issue 344970043 by d...@gnu.org)

> On 22 Jun 2018, at 11:09, David Kastrup wrote: > > Hans Åberg writes: > >>> You could also do it as a constructor, if you prefer its syntax and >>> don't mind implementing yet another one: >>> >>> explicit Transform(const Transform *t)

Re: C++ standards

> On 5 Jul 2018, at 20:02, David Kastrup wrote: > > What C++ standard should we be able to ask for? I think that at the > current point of time, C++11 should be reasonably fine for the asking. The g++7 default, and clang++6, is C++14, but supports C++17 with the --std=c++17 flag. > Should

Re: C++ standards

> On 6 Jul 2018, at 00:17, Dan Eble wrote: > > On Jul 5, 2018, at 15:20, Hans Åberg wrote: >> >>> On 5 Jul 2018, at 20:02, David Kastrup wrote: >>> >>> What C++ standard should we be able to ask for? I think that at the >>> cur

Re: Issue 5368: Reduce allocations in Grob dimension caching (issue 359770043 by nine.fierce.ball...@gmail.com)

> On 7 Jul 2018, at 09:35, David Kastrup wrote: > > Hans Åberg writes: > >>> On 6 Jul 2018, at 11:12, d...@gnu.org wrote: >>> >>> On 2018/07/05 21:32:25, Dan Eble wrote: >>> >>>> The rationale is that std::optional is fit for this

Re: Issue 5368: Reduce allocations in Grob dimension caching (issue 359770043 by nine.fierce.ball...@gmail.com)

> On 7 Jul 2018, at 10:04, David Kastrup wrote: > > Hans Åberg writes: > >> The idea is to do it all now, then the change is automatic and the old >> code can just be removed at some point in time, but you would need a >> compiler that can do C++17, too. >

Re: Issue 5368: Reduce allocations in Grob dimension caching (issue 359770043 by nine.fierce.ball...@gmail.com)

> On 7 Jul 2018, at 12:14, David Kastrup wrote: > > Hans Åberg writes: > >> The first step would probably to switch to a later compiler with a >> flag for an older C++ version. Then one can test later C++ versions in >> independent builds. > > We are not

Re: Issue 5368: Reduce allocations in Grob dimension caching (issue 359770043 by nine.fierce.ball...@gmail.com)

> On 7 Jul 2018, at 13:12, David Kastrup wrote: > > Hans Åberg writes: > >> There is a danger in using an older compiler that is not supported, as >> there might be bugs that are not going to be fixed. > > Well, that's the point, isn't it? If a si

Re: Issue 5368: Reduce allocations in Grob dimension caching (issue 359770043 by nine.fierce.ball...@gmail.com)

> On 6 Jul 2018, at 11:12, d...@gnu.org wrote: > > On 2018/07/05 21:32:25, Dan Eble wrote: > >> The rationale is that std::optional is fit for this situation and if > LilyPond >> were built with C++17 I would simply have used it. > > Any C++17 lookalike package is _not_ "simply using it" but

Re: Issue 5368: Reduce allocations in Grob dimension caching (issue 359770043 by nine.fierce.ball...@gmail.com)

> On 7 Jul 2018, at 00:13, nine.fierce.ball...@gmail.com wrote: > > On Jul 6, 2018, at 18:02, Hans Åberg wrote: > One can do it the other way around, too: > #if __cplusplus < 201703L > namespace std { > using optional = Optional; > } > #endif > > Ugh.

Re: Issue 5368: Reduce allocations in Grob dimension caching (issue 359770043 by nine.fierce.ball...@gmail.com)

> On 7 Jul 2018, at 22:02, Werner LEMBERG wrote: > >> It took long time to get C++11 right, so it is best to avoid older >> compilers I think. > > I disagree. The proper way is to test various C++11 features to check > whether a compiler really supports this standard. The macro >

Re: Issue 5368: Reduce allocations in Grob dimension caching (issue 359770043 by nine.fierce.ball...@gmail.com)

> On 8 Jul 2018, at 08:00, Werner LEMBERG wrote: > > >>> I disagree. The proper way is to test various C++11 features to >>> check whether a compiler really supports this standard. The macro >>> AX_CXX_COMPILE_STDCXX does such checks, BTW. >> >> Full C++11 support was first in GCC 4.8.1,

Re: Add and use a Transform data type (issue 344970043 by d...@gnu.org)

> On 22 Jun 2018, at 14:27, David Kastrup wrote: > > What would that be good for concerning this issue? Only you know that: you did not like the explicit constructor for some reason, but didn't detail. ___ lilypond-devel mailing list

Re: Turkish makam using regular.ly

> On 21 Oct 2018, at 10:56, Torsten Hämmerle wrote: > > Hans Åberg-2 wrote >> One only needs two extra files (below) that define and call the accidental >> glyphs in the Bravura.otf font, […] > > Hi Hans, > > Nice work! Thanks! > If I understand it corr

Re: Turkish makam using regular.ly

> On 21 Oct 2018, at 14:42, Torsten Hämmerle wrote: > > Hans Åberg wrote >> If one typesets the file regularE53smufl.ly, one gets output below. Some >> single arrow accidentals are also missing in LilyPond, I think. > > Yes, also single arrow accidentals are missing.

Re: Turkish makam using regular.ly

> On 21 Oct 2018, at 10:10, Graham Breed wrote: > > On 2018-10-20 02:24, Adam Good wrote: >> Hi Hans, >> I hope this email finds you well. Some questions for you if you have time >> plus I want to share my close to complete turkish makam file based on the >> file you sent me originally plus

Re: Turkish makam using regular.ly

> On 21 Oct 2018, at 17:34, Torsten Hämmerle wrote: > > Hans Åberg-2 wrote >> You mean i LilyPond? What version. > > Yes, in LilyPond resp. LilyPond's notation font Emmentaler. > Current developments are done in Version 2.21.0. > The new accidentals certai

Re: Turkish makam using regular.ly

> On 21 Oct 2018, at 17:41, Adam Good wrote: > > Hans and everyone, > This is about as much as I can do for a new Turkish Makam .ly file, > see attached: turkish-makam.ly Hans it's very similar to what I sent you > privately, took out some unwanted pitch definitions. > > I can see this

Re: Turkish makam using regular.ly

> On 23 Oct 2018, at 04:56, Adam Good wrote: > > On Sun, Oct 21, 2018 at 12:28 PM Hans Åberg wrote: > >> >> I made a version that allows one to switch to Helmholtz-Ellis notation, >> with arrow accidentals: Just uncomment the line >> %\bra

Re: Turkish makam using regular.ly

> On 31 Oct 2018, at 19:51, Adam Good wrote: > > I have issues in that the tonic of these makams is a microtone. In standard > Turkish notation, "fb" which is "f" 4k sharp > We need > \key fb \bestenigar Is this right? It is traditional to raise the third below the finalis, but not in the

Re: Turkish makam using regular.ly

> On 1 Nov 2018, at 02:40, Adam Good wrote: > > On Wed, Oct 31, 2018 at 5:46 PM Hans Åberg wrote: > Is this right? It is traditional to raise the third below the finalis, but > not in the octave above, and it looks as though is a. I found this [1], it > has an addition

Re: Turkish makam using regular.ly

> On 25 Oct 2018, at 06:02, Adam Good wrote: > > On Tue, Oct 23, 2018 at 9:42 AM Hans Åberg wrote: >> >> > On 23 Oct 2018, at 04:56, Adam Good wrote: >> > >> Does it sound lower in standard Turkish performance, that is, which does not >> refer t

Re: Turkish makam using regular.ly

> On 21 Oct 2018, at 10:56, Torsten Hämmerle wrote: > > Incidentally, I'm planning to fill in the Emmentaler gaps in the (very) near > future directly ... > The Metafont overhaul was, among others, the reason why it took so long (but > it's in the final internal testing phase now, struggling

Re: Turkish makam using regular.ly

> On 3 Nov 2018, at 09:46, Torsten Hämmerle wrote: > > Just leave do not specify the tonic scale step in the scale/key definiton! > That's all! ;) > That way it will never be printed in the key signature. > If we set up the two special key signatures bestenigâr and revnaknüma > completely

Re: Turkish makam using regular.ly

> On 3 Nov 2018, at 17:32, Adam Good wrote: > > On Sat, Nov 3, 2018 at 4:46 AM Torsten Hämmerle > wrote: > >> Just leave do not specify the tonic scale step in the scale/key definiton! >> That's all! ;) >> That way it will never be printed in the key signature. > > Sometimes my cat has a cat

Re: Turkish makam using regular.ly

> On 1 Nov 2018, at 18:37, Adam Good wrote: > > This works though technically it is a cheat. If, for whatever reason one > wanted to transpose the tonic of bestenigar from fb to c, the key signature > will print c4k flat which is of course inaccurate. Why anyone would want to > lock an

Re: Turkish makam using regular.ly

> On 2 Nov 2018, at 14:51, Adam Good wrote: > >> On Thu, Nov 1, 2018 at 3:45 PM Hans Åberg wrote: >> > Again, anything like that or even being able to understand Torston's code >> > is beyond my skills. I wish! Just a musician. >> > He didn't post th

Re: Turkish makam using regular.ly

> On 1 Nov 2018, at 18:37, Adam Good wrote: > > Why anyone would want to > lock an important microtonal pitch like IRAK to C, I don't know other than > to say you can. What do you think? LilyPond may not be able to transpose a microtonal interval correctly, because it has only two interval

Re: Turkish makam using regular.ly

> On 20 Oct 2018, at 03:24, Adam Good wrote: > > Hi Hans, > I hope this email finds you well. Some questions for you if you have time > plus I want to share my close to complete turkish makam file based on the > file you sent me originally plus regular.ly > > here's the new makam include

Re: Turkish makam using regular.ly

> On 20 Oct 2018, at 19:03, David Kastrup wrote: > >> The only difference is that I have 0 in some positions where you have 0/53. > > To Scheme that is no difference. Indeed, I was thinking about 1/53. :-) ___ lilypond-devel mailing list

Re: Turkish makam using regular.ly

> On 20 Oct 2018, at 19:25, Adam Good wrote: > > Hans thank you for passing this along to the dev list, replies below... Yes, it is important to le other to be able to follow, especially with such nice examples! > On Sat, Oct 20, 2018 at 4:40 AM Hans Åberg wrote: >

Re: Turkish makam using regular.ly

> On 20 Oct 2018, at 03:24, Adam Good wrote: > > I hope this email finds you well. Some questions for you if you have time > plus I want to share my close to complete turkish makam file based on the > file you sent me originally plus regular.ly > > here's the new makam include file: >

Re: Turkish makam using regular.ly

> On 20 Oct 2018, at 19:25, Adam Good wrote: > > Could you please show a pdf of your Cemil Bey Hicazkar Pesrev using HE > arrowed accidentals? And how to make that an option? One only needs two extra files (below) that define and call the accidental glyphs in the Bravura.otf font, which in

Re: Turkish makam using regular.ly

> On 14 Nov 2018, at 05:22, Adam Good wrote: > > Hans, Torsten and everyone, > 10 days later I have a finished turkish-makam.ly file that I'm certain has > nothing more for me to do on my end. There's support for 201 makam key > signatures which is A LOT and exhausts what can be found in

Re: Sponsorship available for makam.ly transposition issues

> On 21 Sep 2018, at 00:00, Adam Good wrote: > > Hans this is great, I'm on a roll over here. Will pick up on this in a couple > of days. Start with that. One can also use glyphs that LilyPond does not have using SMuFL.org: With that, the regularE53.ly can for example be set in

Re: Sponsorship available for makam.ly transposition issues

> On 20 Sep 2018, at 17:40, Adam Good wrote: > > Thank you so much for the reply and suggestions! > > Previously I've gone down the route of creating my own makam.ly file and > defining every ratio that comes up as an error but remember it being a bit > endless. Might be a rabbit hole. But

Re: ly: updates to hel-arabic.ly (issue 349810043 by pkxgnugi...@runbox.com)

> On 17 Dec 2018, at 15:35, pkxgnugi...@runbox.com wrote: > >> FYI, Adam Good expressed interest updating the Arabic and Persian > files for >> LilyPond [1]. I have sent him a file with maqam from the site [2]. > >> 1. > https://lists.gnu.org/archive/html/lilypond-devel/2018-11/msg00105.html

Re: ly: updates to hel-arabic.ly (issue 349810043 by pkxgnugi...@runbox.com)

> On 12 Dec 2018, at 09:55, lilyp...@maltemeyn.de wrote: > > I don’t know anything about arabic music but there are some changes that > look strange to me. FYI, Adam Good expressed interest updating the Arabic and Persian files for LilyPond [1]. I have sent him a file with maqam from the site

Re: New LilyPond contributor: Basia Mroczek

> On 21 Nov 2018, at 23:20, Janek Warchoł wrote: > > I'd like to introduce Basia Mroczek, who's joining our team for several > months. Basia is a graduate (is that the correct english term?) of > Mathematics at the University of Warsaw (so, cream of the crop!) who'd like > to steer her career

Arabic maqam and Persian dastgah

> On 22 Nov 2018, at 22:25, Adam Good wrote: > > In the future I'd like to update arabic.ly to arabic-maqam.ly and would > like to contribute something for Persian / Iranian music. I have made the Arabic maqam for E53 and for Helmholtz-Ellis accidentals using Graham's regular.ly, for the

Re: Sponsorship available for makam.ly transposition issues

> On 18 Sep 2018, at 19:01, Adam Good wrote: > > Hi everyone! > I'm assuming no one is currently working on the current issues involving > transposition when using makam.ly ... if so please be in touch with me. > Otherwise, would anyone be willing to work on it? I'm MORE than happy to >

Re: 64-bit version of Lilypond?

> On 24 Feb 2019, at 01:16, Carl Sorensen wrote: > > On 2/23/19, 5:13 PM, "lilypond-devel on behalf of Hans Åberg" > haber...@telia.com> wrote: > >Found this, which is for 10.6: >https://aur.archlinux.org/packages/x86_64-apple-darwin-sdk/ > &

Re: 64-bit version of Lilypond?

> On 23 Feb 2019, at 22:26, Karlin High wrote: > > Full quote: > > " > we use GUB (see ) to > build binaries, not Xcode. We link against > > > > which is based on

Re: 64-bit version of Lilypond?

> On 25 Feb 2019, at 17:23, Carl Sorensen wrote: > > So I think one possibility in providing a functional lilypond 64-bit > executable for OSX is to only provide a command-line version, with a pointer > to use it with Frescobaldi. Not ideal, but perhaps better than saying "build > your

Re: 64-bit version of Lilypond?

> On 25 Feb 2019, at 19:20, Sven Axelsson wrote: > > On Mon, 25 Feb 2019 at 18:07, Hans Åberg wrote: > >> All stuff is already in MacPorts, it seems... > > Yes, I suppose the best thing to do is to make it easy for people to build > Lilypond themselves using Ma

Re: 64-bit version of Lilypond?

> On 24 Feb 2019, at 01:16, Carl Sorensen wrote: > > Still needs to download the SDK from Apple: > > https://github.com/tpoechtrager/osxcross#packaging-the-sdk They are listed at https://developer.apple.com/download/more/ One needs to have an account and log in. Mentioned at the bottom at

Re: 64-bit version of Lilypond?

> On 26 Feb 2019, at 01:19, Karlin High wrote: > > On 2/25/2019 1:22 PM, Hans Åberg wrote: >> I have just installed it, and it is 64 bit > > Curious, does the 64-bit resolve the out-of-memory errors that have been > appearing in 32-bit versions? This thread,

Re: 64-bit version of Lilypond?

> On 24 Feb 2019, at 21:39, David Kastrup wrote: > > Hans Åberg writes: > >>> On 24 Feb 2019, at 20:47, David Kastrup wrote: >>> >>>>> Are there any other considerations here related to software usage >>>>> rights? GPL v2 versus v3

Re: 64-bit version of Lilypond?

> On 25 Feb 2019, at 00:10, David Kastrup wrote: > >> Xcode license: >> https://www.apple.com/legal/sla/docs/xcode.pdf > > Well, I think that one is pretty clear: > >2.5 >Copies > >[...] For clarity, You may copy only the entire package or piece of >the Apple Software and

Re: 64-bit version of Lilypond?

> On 25 Feb 2019, at 01:04, David Kastrup wrote: > >>> So the current Xcode SDK very clearly is off-limits for use within GUB. >>> It's probably either some Darwin SDK or we'll stop providing MacOSX >>> packagers/versions altogether. >> >> US copyright law makes an exception for computer

Re: 64-bit version of Lilypond?

> On 24 Feb 2019, at 19:28, Karlin High wrote: > > On Sun, Feb 24, 2019, 7:26 AM Hans Åberg wrote: > > > On 24 Feb 2019, at 01:16, Carl Sorensen wrote: > > > > Still needs to download the SDK from Apple: > > > > https://github.c

Re: 64-bit version of Lilypond?

> On 24 Feb 2019, at 20:47, David Kastrup wrote: > >>> Are there any other considerations here related to software usage >>> rights? GPL v2 versus v3 was mentioned earlier; can anyone provide >>> an overview of what that change means for a LilyPond 64 bit macOS >>> effort? >> >> Nothing, I

Re: 64-bit version of Lilypond?

> On 25 Feb 2019, at 01:04, Karlin High wrote: > > On Sun, Feb 24, 2019 at 5:48 PM Hans Åberg wrote: > > > On 25 Feb 2019, at 00:10, David Kastrup wrote: > > > So the current Xcode SDK very clearly is off-limits for use within GUB. > > It's probably eit

Re: Turkish makam using regular.ly

> On 21 Oct 2018, at 10:56, Torsten Hämmerle wrote: > > Incidentally, I'm planning to fill in the Emmentaler gaps in the (very) near > future ... > The new glyph names for the tiny-arrowed accidentals (just the ones you > currently use are mentioned here) will be > > accidentals.flatflat.1up

Re: 64-bit version of Lilypond?

> On 14 Mar 2019, at 15:12, David Kastrup wrote: > > Werner LEMBERG writes: > IMHO this wouldn't be a serious problem – it's mainly about easily getting distributable LilyPond binaries for the Mac. We could even re-pack them together with documentation in case this makes

Re: 64-bit version of Lilypond?

> On 14 Mar 2019, at 12:50, Werner LEMBERG wrote: > >>> https://guide.macports.org/chunked/using.binaries.html#using.binaries.binary-packages >> >> Also, the MacPorts does not install any documentation, it seems. > > IMHO this wouldn't be a serious problem – it's mainly about easily > getting

Re: 64-bit version of Lilypond?

> On 14 Mar 2019, at 18:25, David Kastrup wrote: > > The passage in question reads > > 6. Conveying Non-Source Forms. > > You may convey a covered work in object code form under the terms > of sections 4 and 5, provided that you also convey the > machine-readable Corresponding Source under

  1   2   3   >