Re: Turkish makam

> On 15 Jan 2023, at 14:45, Adam Good wrote: > > Hans and Werner, > For a couple reasons, I deliberately used the name turkish-makam.ly to make > a distinction and clarity between the Arabic and Turkish varieties of > (respectively) maqam and makam theory and notation systems. Also I do have >

Re: Turkish makam

> On 16 Jan 2023, at 02:29, Adam Good wrote: > > On Sun, Jan 15, 2023 at 9:49 AM Hans Åberg wrote: > > As the full number of Turkish makam is very large, perhaps too many to have > in this file, there might be a turkish-makam-extended for the less common > ones. >

Re: Turkish makam

> On 16 Jan 2023, at 10:30, Luca Fascione wrote: > >> On Sun, Jan 15, 2023 at 3:49 PM Hans Åberg wrote: >> As the full number of Turkish makam is very large, perhaps too many to have >> in this file, there might be a turkish-makam-extended for the less common >&

Re: Turkish makam

> On 18 Jan 2023, at 05:07, Adam Good wrote: > > Let's take the makam Rast: > > g a bfc c d e fb > > the pitch g just happens to be the finalis...every song or instrumental > composition will have a melody that must end on that pitch. And the > accidentals say "b one koma flat" and "f four ko

Re: MacPorts builds for 'Yosemite' and 'El Capitan' fail

> On 5 Feb 2023, at 13:54, Werner LEMBERG wrote: > > I see the following error: > > rational.cc:68:33: error: call to 'abs' is ambiguous > num_ = static_cast (::abs (n)); >^ > /usr/include/stdlib.h:129:6: note: candidate function > int abs(int) __pure2

Re: Flex on macOS

> On 31 Jul 2023, at 01:15, Jean Abou Samra wrote: > > I noticed that the macOS-provided flex version (on the MacStadium node > provided > by Marnen, which runs the unsupported macOS Catalina) was ~10 years old, so I > installed Flex from Homebrew (required setting CPPFLAGS + LDFLAGS + PATH as

Re: Flex on macOS

illet 2023 à 22:29 +0200, Hans Åberg a écrit : >> >> >> Apple has patched their version of Flex so that the generated .cc file must >> be used with their header FlexLexer.h. > > I don't think this is the problem. Before I installed Flex from Homebrew, the > on

Re: search for better regtest comparison algorithm

> On 27 Jul 2024, at 18:56, Werner LEMBERG wrote: > > I've posted a question on StackExchange, searching for a better > regtest comparison algorithm > > > https://computergraphics.stackexchange.com/questions/14143/search-for-special-image-difference-metric I made a net search on “image comp

Re: search for better regtest comparison algorithm

> On 28 Jul 2024, at 12:05, Werner LEMBERG wrote: … > Anyway, AFAICS, it doesn't provide what we need for LilyPond. It seems hard to find what you are asking for, as most programs are GUI oriented. Some inputs, though: A program switching the images so that differences like in your example ca

Re: search for better regtest comparison algorithm

> On 28 Jul 2024, at 16:26, Werner LEMBERG wrote: > > >>> Anyway, AFAICS, it doesn't provide what we need for LilyPond. >> >> It seems hard to find what you are asking for, as most programs are >> GUI oriented. > > I'm quite sure that behind the scene, for all GUIs, a metric gets > computed

Re: search for better regtest comparison algorithm

> On 28 Jul 2024, at 19:49, Werner LEMBERG wrote: > >>> I'm quite sure that behind the scene, for all GUIs, a metric gets >>> computed to decide whether there are differences at all. We 'just' >>> have to find one that fits our needs. >> >> It looks like you want a different property than an

Re: search for better regtest comparison algorithm

> On 28 Jul 2024, at 20:43, Werner LEMBERG wrote: > >>> On top of the MAE algorithm we currently use, another algorithm >>> might increase the penalty for small feature differences so that it >>> is above our threshold. >> >> It gets into the construction of image comparison algorithms. >> Per

Re: How should tupletSpannerDuration actually work?

On 12 Jan 2013, at 12:53, David Kastrup wrote: > "Phil Holmes" 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 tupletSpannerDu

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: LilyPond & Guile 2

> On 22 Jan 2016, at 16:26, Simon Albrecht wrote: > > On 22.01.2016 16:23, David Kastrup wrote: >> Hans Åberg writes: >> >>> What are the technical problems when trying to integrate Guile 2.0 >>> into LilyPond? >> The same that were extensively dis

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 question about usage, hence to be asked o

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 part of any >> o

Re: midi2ly will not launch on OSX 10.11.4

> On 13 Apr 2016, at 23:20, Simon Albrecht wrote: > > On 13.04.2016 23:13, Hans Åberg wrote: >>> 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. >>&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 edi

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 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 not cross the >> 2nd and

Re: 5027: NR example with bad engraving practice

> On 5 Jan 2017, at 23:16, Simon Albrecht 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 not cross

Re: 5027: NR example with bad engraving practice

> On 5 Jan 2017, at 23:55, Simon Albrecht wrote: > > On 05.01.2017 23:42, Hans Aikema wrote: >>> On 5 Jan 2017, at 23:16, Simon Albrecht wrote: >>>>> On 04.01.2017 15:01, Hans Åberg wrote: >>>>>> This is just a quirk of the 4/4 [meter], also m

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: 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 published. > Furthermore, the

Re: Compiling on MacOS

> On 29 Dec 2024, at 04:27, Saul Tobin wrote: > > … This is after compiling using Xcode > clang-16, which should be the same as used by Homebrew for Guile. On MacPorts, guile-2.2 depends on clang-17, not the Apple in-house version.

<    1   2   3