Re: Turkish makam using regular.ly

[Hans Åberg]

> On 23 Oct 2018, at 04:56, Adam Good <address@hidden> wrote:
> 
> On Sun, Oct 21, 2018 at 12:28 PM Hans Åberg <address@hidden> wrote:
> 
>> 
>> I made a version that allows one to switch to Helmholtz-Ellis notation,
>> with arrow accidentals: Just uncomment the line
>>  %    \bravuraOn
>> and recompile, making sure that the files definitions.ily and
>> smufldata.ily are present, along with the Bravura.otf font.
>> 
> 
> Hans very nice! Could you please see the attached pdf of Hicazkar Pesrev
> from Cemil Bey I created and confirm the Bravura fonts are correct in the
> key signature and throughout the piece?

Yes, and the the Turkish microtonal sharp not there should have a plain Western 
sharp in the Helmholtz-Ellis version.

> I'm completely unfamiliar with
> Helmholtz-Ellis.

It originally refers to Pythagorean tuning with syntonic commas 81/80, but is 
the same as the Turkish in E53. In Turkish music, when using Pythagorean 
tuning, it should probably originally be Pythagorean commas, but the difference 
is so small that it can only be heard when doing harmony, and then syntonic 
commas are better, as it is the difference to 5-limit Just Intonation.

>> So the extra work to get this feature is minimal.
> 
> For this to work, dependencies are on:
> smufldata.ily
> definitions.ily
> 
> Are you proposing that they also go into the main Lilypond distribution?

Since Torsten Hämmerle said the new glyphs will be available in just a few 
weeks, he even gave the names, it would be better to just set it there: all 
that is needed is an alternative to makamGlyphs. A problem is though that is 
cannot be tested just today, so I do that with Smufl instead.

>>> One thing to work on and it should be spelled out in the file is the use
>> of
>>> 2.5 koma...I haven't yet figured that one out. Any thoughts?
>> 
>> What does this refer to?
> 
> Have a look at the original makam.ly file. When Han-Wen Nienhuys created
> our makam.ly file so many years ago, he was asked to include extra pitch
> levels for 2.5 koma and 3 koma for the "Uşşak si" that is often referred to
> in Turkish music. I wasn't sold on the idea but others were and for midi,

Does it sound lower in standard Turkish performance, that is, which does not 
refer to a MIDI? —The original makam.ly is in a multiple of E12, and in 
addition, its accidentals are not correct, so its pitches will be off relative 
to E53.

> it makes a difference. Makam Uşşak needs the pitch segah (1k backwards flat
> on pitch B) in its standard Turkish notation. Since Uşşak-si actually
> sounds much flatter in makam Uşşak, some folks notate it as such and
> consider 2.5 or 3 komas.
> 
> I've taken care of it, see attached. in makamGlyphs = #`( etc the glyphs
> are defined.

What does the Makam Uşşak MIDI sound now that you have proper E53 without that 
addition?

Also note that the regular.ly file retunes around E12 C4, so its A4 will be 
slightly higher than 440 Hz.

>> You have:
>>  #(ly:parser-set-note-names parser makamPitchNames)
>> In later versions of LilyPond, the "parser" part has been deprecated, so
>> it should be:
>>  #(ly:parser-set-note-names makamPitchNames)
> 
> Right that was working for me on current stable Lilypond. I'll work in Dev
> from here on out.

That could be the difference. —I just remove it when I get compile error, which 
was with the unstable version.

> BTW I just added glyph definitions on my end for 54/53, sharp and flat (9
> komas. Didn't have those defined yet).
> 
> What else?? I feel as though we're incredibly close here.
> 
> Further testing to be done:
> 1. keyAlterationOrder - working very well for all the common makam key
> signatures though some crazy transpositions of those give some errors.
> Something to test down the road slowly.

Turkish notation does not have glyphs for all E53 notes, so you might fill them 
in with something, to get that instead of an error.

> 2. Hans, on your end, are there any keyAlterationOrder issues using bravura
> font?

No, it does not have anything with the font to do. Just choose an order that 
you deem right.

> 3. Many of the not so obvious \override KeySignature #'padding-pairs = #'(
> are incomplete but these issues come up during weird transpositions. A bit
> time consuming to test.

The standard key signatures should now work, if you just find a suitable 
keyAlterationOrder. If you can, check with the unstable version.