Thank you Adam for your message.
I am still confused by the usage of 72-TET (see excerpt below)
%{
Define makam alterations 72 ET
%}
#(define-public KOMA 1/12) % KOMA 1/9
#(define-public CEYREK 3/12) % CEYREK quarter 1/4
#(define-public EKSIK-BAKIYE 4/12) % EKSIK-BAKIYE 3/9
#(define-public BAKIYE 5/12) % BAKIYE 4/9
#(define-public KUCUK 6/12) % KUCUK 5/9
#(define-public BUYUKMUCENNEB 10/12) % BUYUKMUCENNEB 8/9
#(define-public TANINI 11/12) % 10/9
The AEU notation is based on 53 TET, so KOMA should be 1/53,
EKSIK-BAKIYE 4/53 etc
Also the natural notes C D E F G A B are different in 53-TET than
in N-TET that are multiple of 12 TET systems like 12-TET, 24-TET
or 72-TET
So with respect to C as tonic, D is not 200 cents, E is not
400 cents etc.
kupirijo
Στις 3/12/19 10:02 pm, ο Adam Good
έγραψε:
Hi Everyone,
Here's Adam Good. My apologies for arriving late to the
party I wasn't aware of this thread! From what I can see this
looks to be the most updated version of
turkish-makam.ly
in the dev channel.
This has been the most practical solution from my view,
until we can get
regular.ly involved.
Best,
Adam
> On 24 Nov 2019, at 22:40, David Kastrup <address@hidden> wrote:
>
> Hans Åberg <address@hidden>
writes:
>
>>> On 24 Nov 2019, at 22:20, David Kastrup <address@hidden> wrote:
>>>
>>> Hans Åberg <address@hidden> writes:
>>>
>>>>> On 24 Nov 2019, at 16:39, kupirijo <address@hidden>
wrote:
>>>>>
>>>>> So the turkish-makam.ly
that I downloaded earlier requires a file
>>>>> called definitions.ily . Is this provided
somewhere?
>>>>
>>>> It is from OpenLilyLib. And the Bravura font
is from SMuFL
>>>> <https://www.smufl.org>;
it must be installed so that lilypond sees
>>>> it. I’ll send them to you together with
Helmholtz-Ellis in E53.
>>>>
>>>>> Also where can I download the latest
version of turkish-makam.ly?
>>>>
>>>> It looked like it was in the LilyPond source
archive, otherwise from Adam.
>>>
>>> And requires OpenLilyLib to run?
>>
>> Just the file definitions.ily. I’ll send you a
sample, so you can try.
>
> No, I am not really interested. But we shouldn't
distribute stuff as
> part of LilyPond that requires OpenLilylib to run.
The development version, that is, not the one submitted. The
components are slowly moving becoming a part of LilyPond.