Turkish makam using regular.ly

classic Classic list List threaded Threaded
47 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Turkish makam using regular.ly

Adam Good-3
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 replacing the current makam.ly file since it uses the same
pitch names and glyphs etc.

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?

Attached is also a file showing all of the key signatures
defined, turkish-makam-KEYSIGNATURE-DEMO.ly

Adam

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel

turkish-makam.ly (21K) Download Attachment
turkish-makam-KEYSIGNATURE-DEMO.ly (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Turkish makam using regular.ly

Hans Åberg-2
In reply to this post by Torsten Hämmerle

> On 21 Oct 2018, at 17:34, Torsten Hämmerle <[hidden email]> 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 certainly will not make their way in the soon-to-come
> stable release 2.20, but I think they should be contained in the first or
> second official unstable release.

So when this comes by, the 2.21 comes about the same time, I gather.


_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Turkish makam using regular.ly

Hans Åberg-2
In reply to this post by Adam Good-3

> On 21 Oct 2018, at 17:41, Adam Good <[hidden email]> 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 replacing the current makam.ly file since it uses the same
> pitch names and glyphs etc.

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.

With the work that Torsten Hämmerle mentioned, somewhere in LilyPond 2.21, Smufl will not be needed.

So the extra work to get this feature is minimal.

> 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?

> Attached is also a file showing all of the key signatures
> defined, turkish-makam-KEYSIGNATURE-DEMO.ly

It calls the version of turkish-makam.ly with your first name suffixed.

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)





_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel

turkish-makam.ly (17K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Turkish makam using regular.ly

Adam Good-3
On Sun, Oct 21, 2018 at 12:28 PM Hans Åberg <[hidden email]> 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? I'm completely unfamiliar with
Helmholtz-Ellis.


> 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?


> > 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,
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.


> > Attached is also a file showing all of the key signatures
> > defined, turkish-makam-KEYSIGNATURE-DEMO.ly
>
> It calls the version of turkish-makam.ly with your first name suffixed.
>

True, my error...see attached turkish-makam-KEYSIGNATURE-DEMO.ly


> 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.

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.
2. Hans, on your end, are there any keyAlterationOrder issues using bravura
font?
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.

Adam

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Hicazkar+P+Mu-TanburiCemilBey_RK+VD.pdf (391K) Download Attachment
turkish-makam.ly (23K) Download Attachment
turkish-makam-KEYSIGNATURE-DEMO.ly (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Turkish makam using regular.ly

Hans Åberg-2

> On 23 Oct 2018, at 04:56, Adam Good <[hidden email]> wrote:
>
> On Sun, Oct 21, 2018 at 12:28 PM Hans Åberg <[hidden email]> 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.



_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Turkish makam using regular.ly

Adam Good-3
On Tue, Oct 23, 2018 at 9:42 AM Hans Åberg <[hidden email]> wrote:

>
> > On 23 Oct 2018, at 04:56, Adam Good <[hidden email]> wrote:
> >
> Does it sound lower in standard Turkish performance, that is, which does
> not refer to a MIDI? —


I just listened to some midi output. Assuming I did this correctly,
#(define-public EKSIK-IKI 5/20)
#(define-public EKSIK-UC 3/10)

...which would be 2.5k vs. 3k as far as I know, do sound strikingly
different from one another, surprisingly so. That's the mechanical part. In
practice of Turkish performance by the masters, they simply do what ussak
needs to do according to their ears and lots of that has to do with
glissando. Fairly impossible to notate and reproduce via synthesis.


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

At least closer to what makam Ussak needs by the availability of 3
different segah pitches but of course not perfect. But this isn't a concern
to me.


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

True and weird! Any idea where that would put A4?



> 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.
>

I'm fairly reluctant to add glyphs and in fact already added one for -18/53
because makam Huzzam needed it for the key signature. I'll come up with
better fixes by way of errors rather than shoot in the dark.

Also added -15/53 for the ussak si


> > 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.
>

Between the stable vs. dev versions I'm not finding inconsistent behavior
of key sig padding.

Check the attached for makamGlyphs definitions, note blanks as unneeded
placeholders for future errors. Is that acceptable?

Adam

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel

turkish-makam.ly (24K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Turkish makam using regular.ly

Hans Åberg-2

> On 25 Oct 2018, at 06:02, Adam Good <[hidden email]> wrote:
>
> On Tue, Oct 23, 2018 at 9:42 AM Hans Åberg <[hidden email]> wrote:
>>
>> > On 23 Oct 2018, at 04:56, Adam Good <[hidden email]> wrote:
>> >
>> Does it sound lower in standard Turkish performance, that is, which does not refer to a MIDI? —
>
> I just listened to some midi output. Assuming I did this correctly,
> #(define-public EKSIK-IKI 5/20)
> #(define-public EKSIK-UC 3/10)
>
> ...which would be 2.5k vs. 3k as far as I know, do sound strikingly different from one another, surprisingly so. That's the mechanical part. In practice of Turkish performance by the masters, they simply do what ussak needs to do according to their ears and lots of that has to do with glissando. Fairly impossible to notate and reproduce via synthesis.

Anyway, such values risks may not work with transposition, so an alternative might be using a higher ET (see below). For example, Ozan Yarman has an idea to use what essentially is 159 = 3*53, I think. He has a video here.
  https://www.youtube.com/watch?v=y4XuVBuGa08

>> What does the Makam Uşşak MIDI sound now that you have proper E53 without that addition?
>
> At least closer to what makam Ussak needs by the availability of 3 different segah pitches but of course not perfect. But this isn't a concern to me.

In LilyPond, pitches are tied to the notation, so one would have to use a higher ET to ensure transposition. I think that is in effect what you already do: all numbers are multiple of 6, so you can experiment with intermediate values until the MIDI sounds right. For example, -15/53 is one half comma between -18/53 and -12/53. Then add suitable glyphs to work with transposition.

From what I can see, Ussak is the same Arabic Bayati, and in the latter the average is two commas. So perhaps there is an influence, there, the Turkish microtonal values have drifted so as to become larger.

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

Indeed, but in fact the same in the microtonal program Scala!

> Any idea where that would put A4?

In terms of logarithmic fractions of an octave rational interval 2, the E12 C4 is 9/12 = 3/4 below the E12 A4 at 440 Hz, and then the E53 A4 is 40/53 above that C4, so it is 40/53 - 3/4 = 1/(4*53) =  of an octave. This is 1200/212 5.660 cents, or the pitch 400*2^(1/212) = 441.441 Hz.

>> 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.
>
> I'm fairly reluctant to add glyphs and in fact already added one for -18/53 because makam Huzzam needed it for the key signature. I'll come up with better fixes by way of errors rather than shoot in the dark.

I thought of it as a debugging tool, so one can see in the score if something went wrong (see below).

> Also added -15/53 for the ussak si

You might add the new Helmholtz-Ellis accidentals, which will kick in LilyPond 2.21. It seems nothing happens if there is not glyph available for the glyph name, so adding them now. From the names that Torsten Hämmerle gave, I get:

% For LilyPond 2.21:
NewEqualFiftythreeGlyphs = #`(
  (-72/53 . "accidentals.flatflat.2down")
  (-66/53 . "accidentals.flatflat.1down")
  (-60/53 . "accidentals.flatflat")
  (-54/53 . "accidentals.flatflat.1up")
  (-48/53 . "accidentals.flatflat.2up")

  (-42/53 . "accidentals.flat.2down")
  (-36/53 . "accidentals.flat.1down")
  (-30/53 . "accidentals.flat")
  (-24/53 . "accidentals.flat.1up")
  (-18/53 . "accidentals.flat.2up")

  (-12/53 . "accidentals.natural.2down")
  (-6/53  . "accidentals.natural.1down")
  (0      . "accidentals.natural")
  (6/53   . "accidentals.natural.1up")
  (12/53  . "accidentals.natural.2up")

  (18/53  . "accidentals.sharp.2down")
  (24/53  . "accidentals.sharp.1down")
  (30/53  . "accidentals.sharp")
  (36/53  . "accidentals.sharp.1up")
  (42/53  . "accidentals.sharp.2up")

  (48/53  . "accidentals.doublesharp.2down")
  (54/53  . "accidentals.doublesharp.1down")
  (60/53  . "accidentals.doublesharp")
  (66/53  . "accidentals.doublesharp.1up")
  (72/53  . "accidentals.doublesharp.2up")
)


>> 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.
>
> Between the stable vs. dev versions I'm not finding inconsistent behavior of key sig padding.
>
> Check the attached for makamGlyphs definitions, note blanks as unneeded placeholders for future errors. Is that acceptable?

It seems that LilyPond merely inserts no glyph and does not issue a diagnostic, so it makes no difference. So  even if you do not want to have that in the final version, you might add some valid glyph names for debugging purposes.



_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Turkish makam using regular.ly

Hans Åberg
In reply to this post by Torsten Hämmerle

> On 21 Oct 2018, at 10:56, Torsten Hämmerle <[hidden email]> 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 with
> spacing/positioning issues for big-arrow-up doublesharp).

I have made a file e53.ly with these your new glyph names, which when compiled engraves all note names with Helmholtz-Ellis all arrowed accidentals. Graham Breed's retuning file regular.ly must be present.


_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel

e53.ly (13K) Download Attachment
regularE53.ly (13K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Turkish makam using regular.ly

Adam Good-3
Torsten and everyone greetings,

RE: the key signatures for Turkish makam, I've made definitions for about
91 different makams like Rast, Hicaz, Segah, etc. These definitions are in
the turkish-makam.ly file, attached. We need each makam's key signature to:
1. look as they do in standard print (there are good reasons why some
accidentals are included while others not)
2. be fully transposable because, why not, that's why we're here :)

For 89 of the 91 key signatures defined, there are no problems which is
nice.

But so far for only these makams:
bestenigar
revnaknuma

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

However, we don't want the "fb" accidental printed in the key signature.
Bestenigar needs a key signature that looks like saba which have a tonic of
"a" in Turkish notation. We DO want "fb" accidental printed in the score.
And we need it to be able to transpose... if we want
\key bfc \bestenigar

We don't want bfc in the key signature BUT yikes, we do need a bfk in the
key signature because

Attached is a shortish example showing that Rast and Segah transposition
works great and shows bestenigar and revnaknuma with the fb in the key
signature with two examples of what Bestenigar and Revnaknuma should look
like.

Would it be simple enough to tell lilypond:
"if the key signature is bestenigar or revnaknuma, don't print the tonic's
accidentals in the key signature. DO print them in the score.

The example needs turkish-makam.ly and regular.ly to work.

Thank you ahead and I hope I've presented everything clear enough.

Adam

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel

KeySigIssues.pdf (86K) Download Attachment
regular.ly (4K) Download Attachment
turkish-makam.ly (25K) Download Attachment
KeySigIssues.ly (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Turkish makam using regular.ly

Torsten Hämmerle
Adam Good-3 wrote
> Attached is a shortish example showing that Rast and Segah transposition
> works great and shows bestenigar and revnaknuma with the fb in the key
> signature with two examples of what Bestenigar and Revnaknuma should look
> like.

Hi Adam,

When applying my solution to your bestenigar and revnaknuma examples
(denoted "Torsten's mod") perfectly matches your manually tweaked "should
look like this" versions.
That's pretty good for a start (and it's transposable), but I'll think about
a convenient syntax.

As it looks like, we need a customized non-standard function somewhere,
because the key signature resp. the pitches-alist it produces has to depend
on the final tonic ("final" because of transpability).
In standard LilyPond and western music, the key signature matches the scale,
and, actually the "key signatures" like \minor, \major, \dorian etc. are
actually saved as scales.
That's why it is getting a bit inconvenient if we need to omit scale
accidentals in the key signature, at least if this has to be work in all
keys and even with transposition.

This is the current bestenigar and revnaknuma result:

<http://lilypond.1069038.n5.nabble.com/file/t3887/bestenigar-revnaknuma.png>

All the best,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/Dev-f88644.html

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Turkish makam using regular.ly

Hans Åberg-2
In reply to this post by Adam Good-3

> On 31 Oct 2018, at 19:51, Adam Good <[hidden email]> 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 octave above, and it looks as though is a. I found this [1], it has an additional accidental at e.

Then the finalis should also be the key, as it is always within the scale.

1. http://www.eksd.org.tr/makamlar/bestenigar_makami.php

> However, we don't want the "fb" accidental printed in the key signature. Bestenigar needs a key signature that looks like saba which have a tonic of "a" in Turkish notation. We DO want "fb" accidental printed in the score. And we need it to be able to transpose... if we want
> \key bfc \bestenigar

Is is then possible to have both f and fb, and set the key signature as to want.



_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Turkish makam using regular.ly

Adam Good-3
In reply to this post by Torsten Hämmerle
On Wed, Oct 31, 2018 at 5:06 PM Torsten Hämmerle <[hidden email]>
wrote:

> When applying my solution to your bestenigar and revnaknuma examples
> (denoted "Torsten's mod") perfectly matches your manually tweaked "should
> look like this" versions.
> That's pretty good for a start (and it's transposable), but I'll think
> about
> a convenient syntax.
>
> As it looks like, we need a customized non-standard function somewhere,
> because the key signature resp. the pitches-alist it produces has to depend
> on the final tonic ("final" because of transpability).
> In standard LilyPond and western music, the key signature matches the
> scale,
> and, actually the "key signatures" like \minor, \major, \dorian etc. are
> actually saved as scales.
> That's why it is getting a bit inconvenient if we need to omit scale
> accidentals in the key signature, at least if this has to be work in all
> keys and even with transposition.


 Hi Torston,
Yes that's what I meant by it's working great, a little too great :)

Now with you amazing "Torston's mod" set to on, for example Huzzam makam's
bfc (b1k flat) is getting nuked from the key sig:

%%%
HUZZAMmusic = \makamKey \relative c' {
  \key bfc \huzzam bfc' c d efb fb g a bfc
}
%%%

I imagine any makam that "ends on a microtone" will suffer the same, ie,
evic, evcara, segah, etc just to name a few.

Adam
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Turkish makam using regular.ly

Adam Good-3
In reply to this post by Hans Åberg-2
On Wed, Oct 31, 2018 at 5:46 PM Hans Åberg <[hidden email]> 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 additional accidental at e.
>
> Then the finalis should also be the key, as it is always within the scale.
>

Typically but bestenigar is one of those rare makams in which it's not and
keep in mind this only happened 2 out of 91 makams for me so far. There's
bound to be at least one more.

In terms of musicality I get it...bestenigar's behavior starts out and uses
so much of makam saba's behavior. It's a quick turn at the end to a finalis
on the pitch IRAK. And the high leading tone of eb will never find its way
into the key signature.

http://www.neyzen.com/nota_arsivi/02_klasik_eserler/011_bestenigar/bestenigar_p_tanburi_numan_ney.pdf


> Is is then possible to have both f and fb, and set the key signature as to
> want.
>

I would just recommend going with what's tradition. I actually find it
difficult to read through bestenigar pieces with the fb in the key
signature and not showing up in the score. It doesn't look familiar to me.
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Turkish makam using regular.ly

Hans Åberg-2

> On 1 Nov 2018, at 02:40, Adam Good <[hidden email]> wrote:
>
> On Wed, Oct 31, 2018 at 5:46 PM Hans Åberg <[hidden email]> 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 additional accidental at e.
>
> Then the finalis should also be the key, as it is always within the scale.
>
> Typically but bestenigar is one of those rare makams in which it's not and keep in mind this only happened 2 out of 91 makams for me so far. There's bound to be at least one more.
>
> In terms of musicality I get it...bestenigar's behavior starts out and uses so much of makam saba's behavior. It's a quick turn at the end to a finalis on the pitch IRAK. And the high leading tone of eb will never find its way into the key signature.
>
> http://www.neyzen.com/nota_arsivi/02_klasik_eserler/011_bestenigar/bestenigar_p_tanburi_numan_ney.pdf
>  
> Is is then possible to have both f and fb, and set the key signature as to want.
>
> I would just recommend going with what's tradition. I actually find it difficult to read through bestenigar pieces with the fb in the key signature and not showing up in the score. It doesn't look familiar to me.

It is possible have it, by just changing the accidental of the first scale degree:
bestenigar = #'((0 . -24/53)(1 . -24/53)(2 . -24/53)(3 . 0)(4 . -24/53)(5 . -48/53)(6 . -24/53))
revnaknuma = #'((0 . -24/53)(1 . -24/53)(2 . 0)(3 . 0)(4 . 0)(5 . -24/53)(6 . -24/53))

Actually, as LilyPond admits this, I considered this feature when writing a more general pitch system originally intended for LilyPond, but removed it, as did not have any examples of its use and it clashes with anything other tradition to write scales.



_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Turkish makam using regular.ly

Adam Good-3
Hans,
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 important microtonal pitch like IRAK to C, I don't know other than
to say you can. What do you think? Considering it's only happening for two
makams I'd be willing to let it slide.

Still I wonder and as a self admitting (and envious) non coder, wouldn't it
be possible to do add a conditional statement in the makam file:

%%%
if the makam is either besteniger or revnaknuma
then do TorstonsMod
else just be normal
%%%

Again, anything like that or even being able to understand Torston's code
is beyond my skills. I wish! Just a musician.

with full on respect,

Adam

On Thu, Nov 1, 2018 at 3:22 AM Hans Åberg <[hidden email]> wrote:

> It is possible have it, by just changing the accidental of the first scale
> degree:
> bestenigar = #'((0 . -24/53)(1 . -24/53)(2 . -24/53)(3 . 0)(4 . -24/53)(5
> . -48/53)(6 . -24/53))
> revnaknuma = #'((0 . -24/53)(1 . -24/53)(2 . 0)(3 . 0)(4 . 0)(5 .
> -24/53)(6 . -24/53))
>
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Turkish makam using regular.ly

Hans Åberg-2

> On 1 Nov 2018, at 18:37, Adam Good <[hidden email]> 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 important microtonal pitch like IRAK to C, I don't know other than
> to say you can. What do you think? Considering it's only happening for two
> makams I'd be willing to let it slide.

I think that they do not write the key signature of bestenigar, but decide to omit some accidentals. Historically, the key signature is used to simplify notation, not necessarily to indicate the scale. So, for example, in A major, one can use the key signature of D or G major.

So just write the key signature of bestenigar to include all its notes so that it shows up properly when transposed. Having an accidental in the first scale degree is likely to cause confusion when transposing.

Then use something special when some accidentals should be omitted: A key signature of another mode, or some special code, what you deem fit best.

> Still I wonder and as a self admitting (and envious) non coder, wouldn't it
> be possible to do add a conditional statement in the makam file:
>
> %%%
> if the makam is either besteniger or revnaknuma
> then do TorstonsMod
> else just be normal
> %%%
>
> 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 the code, I think.



_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Turkish makam using regular.ly

Hans Åberg-2
In reply to this post by Adam Good-3

> On 1 Nov 2018, at 18:37, Adam Good <[hidden email]> 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 generators, and for Turkish music, one needs one more.



_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Turkish makam using regular.ly

Adam Good-3
In reply to this post by Hans Åberg-2
On Thu, Nov 1, 2018 at 3:45 PM Hans Åberg <[hidden email]> 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 the code, I think.
>

 Correct, Torston has not posted the code yet here on the dev list but he
did post on the lilypond user list. Torston could that be shared? Or have
you cooked up something even more awesome?

Adam
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Turkish makam using regular.ly

Hans Åberg-2

> On 2 Nov 2018, at 14:51, Adam Good <[hidden email]> wrote:
>
>> On Thu, Nov 1, 2018 at 3:45 PM Hans Åberg <[hidden email]> 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 the code, I think.
>
>  Correct, Torston has not posted the code yet here on the dev list but he did post on the lilypond user list. Torston could that be shared? Or have you cooked up something even more awesome?

Ah, I missed that. Anyway, that would be one way to go, as your example transpose of bestenigar from fb to showed that you want it to be excluded only in some keys. Such a function might be useful for other cases where the written key signature does not agree with scale of the tune.



_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Turkish makam using regular.ly

Torsten Hämmerle
Hi, Adam and Hans (in alphabetical order),

I had to stop to think about it (the key signature problem).
*Result: forget about all the fancy tricks, LilyPond can do it
out-of-the-box!*

It's rather uncommon (to say the least) to spare out a certain scale step
from the key signature, so it took a while until I noticed that this can be
done in a very simple and obvious way. Even transposition will work,
provided all the accidentals/notes needed are there.

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 without step 0 (and 7), the definitions will look like this:

bestenigar = #'((1 . -24/53)(2 . -24/53)(3 . 0)(4 . -24/53)(5 . -48/53)(6 .
-24/53))
revnaknuma = #'((1 . -24/53)(2 . 0)(3 . 0)(4 . 0)(5 . -24/53)(6 . -24/53))

KeySigIssues.ly
<http://lilypond.1069038.n5.nabble.com/file/t3887/KeySigIssues.ly>  

Demonstrating bestenigâr, revnaknüma (and the untouched hüzzâm for
comparison), all the requirements are met without any hazzle:

<http://lilypond.1069038.n5.nabble.com/file/t3887/redef-bestenigar-revnaknuma.png>

We all know an extreme case of ignoring accidentals in the key signature:
when specifying no key at all, it's not C major, it's just nothing and there
will be no key signature and all the accidentals will be displayed in the
music.
Here, we just have a mixture of the two extremes: all steps specified vs.
nothing specified, it just took me a while to realize. LilyPond is so
amazing… :D

HTH,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/Dev-f88644.html

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
123