Re: Turkish makam

[Hans Åberg]

> 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 koma sharp" so I'll add those
> in my key signature which, using turkish-makam.ly
> 
> \key g \rast

One issue is that if wanting to use different finalis, then they might prefer 
to give another name. LilyPond, on the other hand, requires the note to be 
indicated.

So extension might be to have the signature note as default. Say
or
  \key \rast
  \signature \rast
expanding to
  \key g \rast
  

Re: Turkish makam

[Luca Fascione]

Right, I see. Thanks for explaining Adam, this is obviously a world I have
not seen until now,
and a very interesting new way of thinking about music and its written form.

To give you a better sense of where I was coming from, imagine that a
person sits down to write a piece,
this person having a need for one of the makams that are not already in
turkish-makam.ly (for the sake of argument, let's say this is "neva")
Assuming that this particular makam is one of the more uncommon ones,
wouldn't it be simpler to just have something like

neva = #(define-makam g a bfc c d e fb)

and then later in the file

\key g \neva

(I do realize the notes and key are the wrong ones, of course, I just
copied your example for rast here just so I had something concrete to type
down)

I guess I'm thinking: if it's the case that only ever a few files could
exist in these more rare forms,
it seems that there wouldn't be much value in having them in the global
file, including the fact that
for the person needing to engrave such a piece they'd need to either alter
the distribution or wait for
an update before they can proceed. Or is my thinking missing some aspect
here?

I'm saying this because this is a common pattern in software engineering:
providing common
constructs in libraries, and augment this with enough extension mechanisms
so that uncommon
things can be achieved, through a potentially less convenient route.

L

On Wed, Jan 18, 2023 at 5:07 AM Adam Good  wrote:

> On Mon, Jan 16, 2023 at 4:30 AM Luca Fascione 
> wrote:
>
>> All this being said, I just read there are hundreds of makams, which
>> makes me wonder whether it
>> wouldn't be more effective to provide a simple method to indicate the
>> makam of a piece at the start
>> of the score, for all but the most common N ones (maybe N could be
>> somewhere between 50 and 100?).
>>
>
> Very creative speculating on your part! However, it's really very very
> simple and nothing needs to happen here. For starters, makams are not
> scales or too akin to what we think of as modes in "western music", they're
> like melodic journeys that have a beginning note or area and always always
> always have a finalis or ending note that never deviates. This journey is
> called "seyir" which could translate to "path". Though they are not simply
> scales, one can strip a makam down to its most basic form and notate a
> simple 7 note scale and since we may need accidentals, we really like to
> use a key signature.
>
> 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 koma sharp" so I'll add those
> in my key signature which, using turkish-makam.ly
>
> \key g \rast
>
> That's it. At the top of the score in the titling I would write the makam
> name and the form of the composition:
>
> Rast Şarkı
> or
> Rast Peşrevi
>
> etc.
>
> The most common makams number around 60+ then they start to get more rare.
> But they exist and I'd defined them in turkish-makam.ly
>
> I hope that makes sense and gives something of an idea. I sure do
> appreciate the interest!!
>
> Adam
>


-- 
Luca Fascione

Re: Turkish makam

[Adam Good]

On Mon, Jan 16, 2023 at 4:30 AM Luca Fascione  wrote:

> All this being said, I just read there are hundreds of makams, which makes
> me wonder whether it
> wouldn't be more effective to provide a simple method to indicate the
> makam of a piece at the start
> of the score, for all but the most common N ones (maybe N could be
> somewhere between 50 and 100?).
>

Very creative speculating on your part! However, it's really very very
simple and nothing needs to happen here. For starters, makams are not
scales or too akin to what we think of as modes in "western music", they're
like melodic journeys that have a beginning note or area and always always
always have a finalis or ending note that never deviates. This journey is
called "seyir" which could translate to "path". Though they are not simply
scales, one can strip a makam down to its most basic form and notate a
simple 7 note scale and since we may need accidentals, we really like to
use a key signature.

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 koma sharp" so I'll add those
in my key signature which, using turkish-makam.ly

\key g \rast

That's it. At the top of the score in the titling I would write the makam
name and the form of the composition:

Rast Şarkı
or
Rast Peşrevi

etc.

The most common makams number around 60+ then they start to get more rare.
But they exist and I'd defined them in turkish-makam.ly

I hope that makes sense and gives something of an idea. I sure do
appreciate the interest!!

Adam

Re: Turkish makam

[Hans Åberg]

> 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 
>> ones.
> Being it said that I'm not clear what the harm is when a file of this kind(*) 
> gets big,
> I would like to bring up that "-extended" is a naming pattern that is likely 
> to create trouble, 
> because there's no obvious rule, given makam "X" to know in which file it 
> belongs.
> In turn this will make the separation annoying for users, and will create 
> potentially annoying
> discussion among contributors when a missing makam needs to be added.
> 
> If the file must be broken up (and again, I'm doubtful it has to), it seems 
> to me that it
> would serve everybody much better if the naming was more descriptive of the 
> content

Adam Good said he put them in the new file, and that seems best unless other 
issues arise.

> --> I don't know anything about Turkish music, …

Rather than transposing existing makam, they prefer to give new names, and in 
addition, in the common AEU notation system, the symbols ♯ and 턪 are not the 
sharp and doublesharp of Pythagorean tuning, but microtonal accidentals, so the 
accidentals of key signatures and otherwise will transpose in peculiar manner. 
Also, one may not write out all accidentals in the key signature, but it is 
common to write the name of the makam above it.

I described the theoretical background in the post below:
https://lists.gnu.org/archive/html/lilypond-devel/2022-12/msg00187.html

Re: Turkish makam

[Luca Fascione]

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 ones.
>
Being it said that I'm not clear what the harm is when a file of this
kind(*) gets big,
I would like to bring up that "-extended" is a naming pattern that is
likely to create trouble,
because there's no obvious rule, given makam "X" to know in which file it
belongs.
In turn this will make the separation annoying for users, and will create
potentially annoying
discussion among contributors when a missing makam needs to be added.

If the file must be broken up (and again, I'm doubtful it has to), it seems
to me that it
would serve everybody much better if the naming was more descriptive of the
content

--> I don't know anything about Turkish music, but I'll offer a bit of wild
speculation with the intention
of providing an example of how the reasoning goes. Please do look past the
specifics, and try to
see the flavour of the argument.

For the sake of argument, one might use a historical classification, or a
structural keyword.
Obviously it might be useful to draw from established systems, if there is
one.

All this being said, I just read there are hundreds of makams, which makes
me wonder whether it
wouldn't be more effective to provide a simple method to indicate the makam
of a piece at the start
of the score, for all but the most common N ones (maybe N could be
somewhere between 50 and 100?).

I'm thinking one might prepare a command that would take appropriate
arguments (maybe a name and the interval sequence?)
and establish that from then onwards that is the current makam in use?

--> end of wild speculation

(*) "this kind":
 - effectively a big long list/dictionary of values
 - clearly the case that the values will never change (beyond what will be
bugfixes of the "clerical error" kind)

L

-- 
Luca Fascione

Re: Turkish makam

[Hans Åberg]

> 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.
> 
> The turkish-makam.ly file contains if I remember correctly, key signature 
> definitions for just over 200 different makams. These I grabbed via various 
> sources (books and online) and contain many (mostly?) less known makams. If 
> anyone finds anything that's not in there let me know!

Fine! —Having them all in a single file is easier to use, and computers are so 
fast these days, it likely does not matter.

If one would wants to transition from the original “makam.ly 
<http://makam.ly/>” to ”turkish-makam.ly <http://turkish-makam.ly/>", what 
changes would be needed to be done (disregarding the MIDI tuning)? —There is 
“convert-ly” that might do the changes. It could then be deprecated and removed.

Re: Turkish makam

[Luca Fascione]

On Sun, Jan 15, 2023 at 2:45 PM Adam Good  wrote:

> on the topic of naming, [...] I find it's a great idea to make the names
> as descriptive and specific as possible. Ideas, for example:
>
> turkish-makam.ly
> arabic-maqam.ly
> persian-dastgah.ly
> arabic-rhythms.ly (I forget the Arabic term...iqa?)
> balkan-keysigs.ly
> balkan-rhythms.ly
> greek-byzantine.ly
>
>
FWIW, I feel this is a very good naming pattern, it's concise and super
clear about what's up.
Loveit

L

-- 
Luca Fascione

Re: Turkish makam

[Werner LEMBERG]

> Though I'm forever grateful for the original makam.ly include
> file. I'd much prefer to use the name turkish-makam.ly and could
> easily see makam.ly simply disappear for the next release.

Good to know, thanks.

> While we're on the topic of naming, and I should pick this up in the
> other thread, I find it's a great idea to make the names as
> descriptive and specific as possible. Ideas, for example:
> 
> turkish-makam.ly
> arabic-maqam.ly
> persian-dastgah.ly
> arabic-rhythms.ly (I forget the Arabic term...iqa?)
> balkan-keysigs.ly
> balkan-rhythms.ly
> greek-byzantine.ly

Patches and/or merge requests are highly welcomed :-)


Werner

Re: Turkish makam

[Adam Good]

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

The turkish-makam.ly file contains if I remember correctly, key signature
definitions for just over 200 different makams. These I grabbed via various
sources (books and online) and contain many (mostly?) less known makams. If
anyone finds anything that's not in there let me know!

Adam

Re: Turkish makam

[Hans Åberg]

> 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
> ideas for another .ly file in the future turkish-usul.ly which will give
> defintions for rhythmic aspects of Turkish classical music. "Usul" is
> basically the rhythmic equivalent in study and theory to "makam". The two
> files would conveniently live right next to one another in the ly
> directory. And the usul file will be large enough that I'd much rather not
> use that material in the turkish-makam file.
> 
> Though I'm forever grateful for the original makam.ly include file. I'd
> much prefer to use the name turkish-makam.ly and could easily see makam.ly
> simply disappear for the next release. turkish-makam is a huge upgrade.

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

[Adam Good]

On Sat, Jan 14, 2023 at 4:00 AM Hans Åberg  wrote:

>
> > On 14 Jan 2023, at 08:06, Werner LEMBERG  wrote:
> >
> >>> Too bad that `makam.ly` is essentially undocumented...
> >>
> >> From what I can see, makam.ly is the original faulty file, only
> >> there for backwards compatibility, which might be removed if there
> >> is no need for that.
> >
> > We could make it become deprecated in the next release, to be
> > completely removed in the release after.
>
> If there are no compatibility issues, perhaps turkish-makam.ly <
> http://turkish-makam.ly/> might be renamed makam.ly <http://makam.ly/>.
> Adam Good might give his view.
>

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
ideas for another .ly file in the future turkish-usul.ly which will give
defintions for rhythmic aspects of Turkish classical music. "Usul" is
basically the rhythmic equivalent in study and theory to "makam". The two
files would conveniently live right next to one another in the ly
directory. And the usul file will be large enough that I'd much rather not
use that material in the turkish-makam file.

Though I'm forever grateful for the original makam.ly include file. I'd
much prefer to use the name turkish-makam.ly and could easily see makam.ly
simply disappear for the next release. turkish-makam is a huge upgrade.

While we're on the topic of naming, and I should pick this up in the other
thread, I find it's a great idea to make the names as descriptive and
specific as possible. Ideas, for example:

turkish-makam.ly
arabic-maqam.ly
persian-dastgah.ly
arabic-rhythms.ly (I forget the Arabic term...iqa?)
balkan-keysigs.ly
balkan-rhythms.ly
greek-byzantine.ly

Adam

Re: Turkish makam

[Hans Åberg]

> On 14 Jan 2023, at 08:06, Werner LEMBERG  wrote:
> 
>>> Too bad that `makam.ly` is essentially undocumented...
>> 
>> From what I can see, makam.ly is the original faulty file, only
>> there for backwards compatibility, which might be removed if there
>> is no need for that.
> 
> We could make it become deprecated in the next release, to be
> completely removed in the release after.

If there are no compatibility issues, perhaps turkish-makam.ly 
 might be renamed makam.ly . Adam 
Good might give his view.

Re: Turkish makam

[Werner LEMBERG]

>> Too bad that `makam.ly` is essentially undocumented...
> 
> From what I can see, makam.ly is the original faulty file, only
> there for backwards compatibility, which might be removed if there
> is no need for that.

We could make it become deprecated in the next release, to be
completely removed in the release after.


Werner

Re: Turkish makam

[Hans Åberg]

> On 13 Jan 2023, at 19:03, Werner LEMBERG  wrote:
> 
>> [...] a possible future change could be, say,
>> 
>>  \include "arabic.ly"
>>  \language "arabic-hel"
>> 
>> but I don't see much benefit for that.
> 
> Hmm, probably it *is* the way to go – this is exactly what is done in
> `makam.ly` and `turkish-makam.ly`.  Too bad that `makam.ly` is
> essentially undocumented...

From what I can see, makam.ly is the original faulty file, only there for 
backwards compatibility, which might be removed if there is no need for that. 
The file turkish-makam.ly  is the corrected one 
written by Adam Good.

I described the theoretical background in the post below:
https://lists.gnu.org/archive/html/lilypond-devel/2022-12/msg00187.html

Re: Turkish makam using regular.ly

[Adam Good]

On Thu, Mar 14, 2019 at 9:25 AM Hans Åberg  wrote:

>
> How is it going with those glyphs? The Turkish AEU notation system does
> not have all the glyphs needed for a transposable system, so one might use
> those glyphs to fill the gaps.
>

I second that this would be fantastic!

Adam
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Hans Åberg]

> 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
>  accidentals.flatflat.2up
>  accidentals.flatflat.1down
>  accidentals.flatflat.2down
>  accidentals.flat.1up
>  accidentals.flat.2up
>  accidentals.flat.1down
>  accidentals.flat.2down
>  accidentals.natural.1up
>  accidentals.natural.2up
>  accidentals.natural.1down
>  accidentals.natural.2down
>  accidentals.sharp.1up
>  accidentals.sharp.2up
>  accidentals.sharp.1down
>  accidentals.sharp.2down
>  accidentals.doublesharp.1up
>  accidentals.doublesharp.2up
>  accidentals.doublesharp.1down
>  accidentals.doublesharp.2down

How is it going with those glyphs? The Turkish AEU notation system does not 
have all the glyphs needed for a transposable system, so one might use those 
glyphs to fill the gaps.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam (and beyond) contribution(s) to Lilypond

[Karlin High]

On 11/22/2018 3:25 PM, Adam Good wrote:

I need guidance from someone here to make it happen, like
a mentor as mentioned in the contributor guide. Would a developer be
willing to help me?


I think currently, your mentor will be the lilypond-devel list.



I'd say follow the Contributor Guide instructions for submitting a patch 
for code review, and your mentor for that particular patch will be 
whichever of the most-frequent contributors takes the most interest in it.


If someone plans to be a major, ongoing contributor to the project, I 
think having a single mentor would be the way to go.


For someone like me, contributing just one patch ever, it's worked out 
well to follow the Contributor Guide instructions and ask this list for 
help as needed.


Following the list has also been helpful; no way can I understand the 
discussions on the finer points of C++ or Scheme, but I'd like to think 
it does help me stay in touch with how to work with the community. It 
also gives me an idea of which of the main developers have what skills, 
and which ones are most likely to match my style of work and communication.


To contribute a patch, getting accounts for the SourceForge issue 
tracker and Rietveld code review isn't hard. I don't ever plan to get 
Git commit access unless not having that is causing someone else a big 
inconvenience. My skill with Git isn't enough to let me fully understand 
the effects of my actions. I'm quite happy to attach a review-complete 
patch to the issue tracker and let someone else apply it.

--
Karlin High
Missouri, USA

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Turkish makam (and beyond) contribution(s) to Lilypond

[Adam Good]

Greetings Lilypond-dev'ers,

Here's Adam Good in Brooklyn, NY.

I've shown up on the dev list recently but here's a better introduction.
I'm a musician with a passion and fairly decent understanding of Turkish
makam and musics of east Europe, the Balkans and beyond. I've spent the
past two months working out a very good update to the current makam.ly file
with some wonderful help from Hans Aberg, Torsten Haemmerle and notably
Graham Breed using his work on regular.ly work.

I have, from what I can see, a working replacement for makam.ly in the form
of turkish-makam.ly that gives us full transposition possibilities and key
signatures for 201 makams, something makam.ly wasn't capable of previously.

I would love for turkish-makam.ly to end up in the main Lilypond
distribution but I need guidance from someone here to make it happen, like
a mentor as mentioned in the contributor guide. Would a developer be
willing to help me?

In the future I'd like to update arabic.ly to arabic-maqam.ly and would
like to contribute something for Persian / Iranian music.

Hopefully someone has thoughts.

All the best,
Adam Good
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Hans Åberg]

> 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 Imail Hakkı 
> Özkan's book on makam and on nezyen.com 's list of both common and uncommon 
> makams.

It has come a long way!

> Please see attached and let me know what you think. It depends of course on 
> regular.ly

The file also depends, for use with SMuFL, on the openlilylib and another, so 
if you want to keep it in the distribution, perhaps somebody can comment on 
that.

Perhaps some multiple of E12 might be tested as complement: E60 and E72 are two 
candidates. E60 has larger commas at 20 c (cent) though smaller than E53 at 
22.641 c, but E72, with smaller commas at 16.667 cent, is a decent 
approximation of the 11-limit, that is, rational intervals using primes up to 
11 (2, 3, 5, 7, and 11). In the old one, I think the ET is in effect 2*54 with 
a comma mostly, but irregularly set in E54, making it not transposable, with a 
comma at 22.222 c, which is very close to E53, but the minor second differs by 
about ten cents.

I found, using a ChucK program I made that can play exact regular tunings, that 
the Pythagorean tuning, of which E53 is a very good approximation, sounded 
oriental sort of. So the E53 you have now, in addition to that it is what the 
Turkish AEU notation formally refers to, seems to the right point of departure 
from the musical point of view.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Hans Åberg]

> 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 treat right under her nose but she doesn't know
> it because she can't see it.

You'll have to smell it!

> Torsten and Hans that's brilliant! In fact none of the makam key signature
> definitions will need a "tonic" as anything other than blank so I can take
> those all out and start at "1". Might lop off a k or two from the file size
> :)

But that is in the untransposed position. The normal would be that the 
accidental of the finalis shows up when it is transposed, like in F# minor or 
major.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Adam Good]

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 treat right under her nose but she doesn't know
it because she can't see it.

Torsten and Hans that's brilliant! In fact none of the makam key signature
definitions will need a "tonic" as anything other than blank so I can take
those all out and start at "1". Might lop off a k or two from the file size
:)

I'll have a new turkish-makam.ly file in the next few days. Just about to
head out of town.

Happy to know that's so easily solved congrats!

Adam
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Hans Åberg]

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

I was just about to suggest an implementation of that, but it is good if 
LilyPond already can do it! :-)

It might be usable for other types of scales, like pentatonic, if people don't 
bother to write key signature accidentals for notes that do not appear.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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
  

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


 

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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Hans Åberg]

> 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 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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Adam Good]

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 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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Hans Åberg]

> 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 generators, and for Turkish music, one needs one more.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Hans Åberg]

> 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 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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Adam Good]

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  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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Hans Åberg]

> 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 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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Adam Good]

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 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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Adam Good]

On Wed, Oct 31, 2018 at 5:06 PM Torsten Hämmerle 
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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Hans Åberg]

> 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 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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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:

 

All the best,
Torsten




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

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Adam Good]

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


KeySigIssues.pdf
Description: Adobe PDF document
% Utilities to re-tune regular tunings.

% Use these functions to choose a different regular
% tuning, with fifths taken from some equal temperament,
% and accidentals scaled accordingly.

% Only equal temperaments are supported because Lilypond uses
% rational numbers to denote pitch alterations.
% If you don't want an equal temperament you can probably
% find one anyway that's close enough to what you want.

% to use, add
%
% tuning = #31
% \include "regular.ly"
%
% somewhere near the top of the file.  (After any language setting.)

% Resets Lilypond's "default scale" containing the pitch of each
% unaltered note (the C major scale).
#(define (retune-nominals ET)
(ly:set-default-scale (ly:make-scale (list->vector
(map (lambda (fifths octaves) (* 6
  (+ (* fifths (best-fifth ET)) octaves)))
   '(0 2 4 -1 1 3 5) '(0 -1 -2 1 0 -1 -2))

% Finds the best size of fifth in the equal temperement with
% the given number of fifths to the octave.
% Note: the effective equal temperament may end up larger.
% For example, ask for 12 and "quartertones" will give you 24.
% If ET is a ratio, assume it describes the fifth, and return it.
#(define (best-fifth ET)
(if (integer? ET)
(/ (inexact->exact (round (* ET 0.5849625007))) ET)
ET))

% Takes the association of pitch names and returns a
% new copy where each alteration has the correct value
% relative to fifths in the given equal temperament.
#(define (retuned-pitchnames pitchnames ET)
(map (lambda (pitchname)
 (let ((pitch (cdr pitchname)))
 (cons (car pitchname)
 (ly:make-pitch
 (ly:pitch-octave pitch)
 (ly:pitch-notename pitch)
 (scale-alteration (ly:pitch-alteration pitch) ET)
 pitchnames))

% Takes a list mapping alterations to glyphs
% and re-tunes the alterations according to the size of fifth
% in the given equal temperament.
#(define (retune-glyphs glyphs ET)
(map (lambda (glyph) (cons (scale-alteration (car glyph) ET) (cdr glyph)))
 glyphs))

% Converts an alteration from the initial alteration size
% (that would give 12-equal) to the given equal temperament.
#(define (scale-alteration alteration ET)
(* 12 alteration (- (* 7 (best-fifth ET)) 4)))

% Scale an explicit scale
#(define (scale-scale keysig ET)
(map (lambda (note) (cons (car note) (scale-alteration (cdr note) ET)))
keysig))

% Retune the standard scales (major/ionian has no alterations)
minor = #(scale-scale minor tuning)
locrian = #(scale-scale locrian tuning)
aeolian = #(scale-scale aeolian tuning)
mixolydian = #(scale-scale mixolydian tuning)
lydian = #(scale-scale lydian tuning)
phrygian = #(scale-scale phrygian tuning)
dorian = #(scale-scale dorian tuning)

% Set the innards
newglyphs = #(begin
(retune-nominals tuning)
(ly:parser-set-note-names (retuned-pitchnames pitchnames tuning))
(retune-glyphs standard-alteration-glyph-name-alist tuning))

% Apply the new glyphs.
\layout {
  \context {
\Score
\override Accidental #'glyph-name-alist = \newglyphs
\override KeySign

Re: Turkish makam using regular.ly

[Hans Åberg]

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



e53.ly
Description: Binary data


regularE53.ly
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Hans Åberg]

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

Re: Turkish makam using regular.ly

[Adam Good]

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


turkish-makam.ly
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Hans Åberg]

> 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
>>  %\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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Hans Åberg]

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



turkish-makam.ly
Description: Binary data


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Hans Åberg]

> 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 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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Adam Good]

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
%\version "2.19.82"
\version "2.18.2"


%{

% 53-ET alterations in terms of 12-ET whole tones.

%}

#(define-public KOMA 1/10)
#(define-public BAKIYE 4/10)
#(define-public KUCUK 5/10)
#(define-public BUYUKMUCENNEB 8/10)

%%% WORK ON EKSIKMIRROREDSLASHED. Need 2.5k, not 2k
#(define-public EKSIK-IKI 2/10)
#(define-public EKSIK-UC 3/10)


%{

Define pitch names

%}

makamPitchNames = #`(
  (cfbm . ,(ly:make-pitch -1 0 (- BUYUKMUCENNEB)))
  (cfk . ,(ly:make-pitch -1 0 (- KUCUK)))
  (cfb . ,(ly:make-pitch -1 0 (- BAKIYE)))
  (cfu . ,(ly:make-pitch -1 0 (- EKSIK-UC)))
  (cfi . ,(ly:make-pitch -1 0 (- EKSIK-IKI)))
  (cfc . ,(ly:make-pitch -1 0 (- KOMA)))
  (c . ,(ly:make-pitch -1 0 NATURAL))
  (cc . ,(ly:make-pitch -1 0 KOMA))
  (cb . ,(ly:make-pitch -1 0 BAKIYE))
  (ck . ,(ly:make-pitch -1 0 KUCUK))
  (cbm . ,(ly:make-pitch -1 0 BUYUKMUCENNEB))

  (dfbm . ,(ly:make-pitch -1 1 (- BUYUKMUCENNEB)))
  (dfk . ,(ly:make-pitch -1 1 (- KUCUK)))
  (dfb . ,(ly:make-pitch -1 1 (- BAKIYE)))
  (dfu . ,(ly:make-pitch -1 1 (- EKSIK-UC)))
  (dfi . ,(ly:make-pitch -1 1 (- EKSIK-IKI)))
  (dfc . ,(ly:make-pitch -1 1 (- KOMA)))
  (d . ,(ly:make-pitch -1 1 NATURAL))
  (dc . ,(ly:make-pitch -1 1 KOMA))
  (db . ,(ly:make-pitch -1 1 BAKIYE))
  (dk . ,(ly:make-pitch -1 1 KUCUK))
  (dbm . ,(ly:make-pitch -1 1 BUYUKMUCENNEB))

  (efbm . ,(ly:make-pitch -1 2 (- BUYUKMUCENNEB)))
  (efk . ,(ly:make-pitch -1 2 (- KUCUK)))
  (efb . ,(ly:make-pitch -1 2 (- BAKIYE)))
  (efu . ,(ly:make-pitch -1 2 (- EKSIK-UC)))
  (efi . ,(ly:make-pitch -1 2 (- EKSIK-IKI)))
  (efc . ,(ly:make-pitch -1 2 (- KOMA)))
  (e . ,(ly:make-pitch -1 2 NATURAL))
  (ec . ,(ly:make-pitch -1 2 KOMA))
  (eb . ,(ly:make-pitch -1 2 BAKIYE))
  (ek . ,(ly:make-pitch -1 2 KUCUK))
  (ebm . ,(ly:make-pitch -1 2 BUYUKMUCENNEB))

  (ffbm . ,(ly:make-pitch -1 3 (- BUYUKMUCENNEB)))
  (ffk . ,(ly:make-pitch -1 3 (- KUCUK)))
  (ffb . ,(ly:make-pitch -1 3 (- BAKIYE)))
  (ffu . ,(ly:make-pitch -1 3 (- EKSIK-UC)))
  (ffi . ,(ly:make-pitch -1 3 (- EKSIK-IKI)))
  (ffc . ,(ly:make-pitch -1 3 (- KOMA)))
  (f . ,(ly:make-pitch -1 3 NATURAL))
  (fc . ,(ly:make-pitch -1 3 KOMA))
  (fb . ,(ly:make-pitch -1 3 BAKIYE))
  (fk . ,(ly:make-pitch -1 3 KUCUK))
  (fbm . ,(ly:make-pitch -1 3 BUYUKMUCENNEB))

  (gfbm . ,(ly:make-pitch -1 4 (- BUYUKMUCENNEB)))
  (gfk . ,(ly:make-pitch -1 4 (- KUCUK)))
  (gfb . ,(ly:make-pitch -1 4 (- BAKIYE)))
  (gfu . ,(ly:make-pitch -1 4 (- EKSIK-UC)))
  (gfi . ,(ly:make-pitch -1 4 (- EKSIK-IKI)))
  (gfc . ,(ly:make-pitch -1 4 (- KOMA)))
  (g . ,(ly:make-pitch -1 4 NATURAL))
  (gc . ,(ly:make-pitch -1 4 KOMA))
  (gb . ,(ly:make-pitch -1 4 BAKIYE))
  (gk . ,(ly:make-pitch -1 4 KUCUK))
  (gbm . ,(ly:make-pitch -1 4 BUYUKMUCENNEB))

  (afbm . ,(ly:make-pitch -1 5 (- BUYUKMUCENNEB)))
  (afk . ,(ly:make-pitch -1 5 (- KUCUK)))
  (afb . ,(ly:make-pitch -1 5 (- BAKIYE)))
  (afu . ,(ly:make-pitch -1 5 (- EKSIK-UC)))
  (afi . ,(ly:make-pitch -1 5 (- EKSIK-IKI)))
  (afc . ,(ly:make-pitch -1 5 (- KOMA)))
  (a . ,(ly:make-pitch -1 5 NATURAL))
  (ac . ,(ly:make-pitch -1 5 KOMA))
  (ab . ,(ly:make-pitch -1 5 BAKIYE))
  (ak . ,(ly:make-pitch -1 5 KUCUK))
  (abm . ,(ly:make-pitch -1 5 BUYUKMUCENNEB))

  (bfbm . ,(ly:make-pitch -1 6 (- BUYUKMUCENNEB)))
  (bfk . ,(ly:make-pitch -1 6 (- KUCUK)))
  (bfb . ,(ly:make-pitch -1 6 (- BAKIYE)))
  (bfu . ,(ly:make-pitch -1 6 (- EKSIK-UC)))
  (bfi . ,(ly:make-pitch -1 6 (- EKSIK-IKI)))
  (bfc . ,(ly:make-pitch -1 6 (- KOMA)))
  (b . ,(ly:make-pitch -1 6 NATURAL))
  (bc . ,(ly:make-pitch -1 6 KOMA))
  (bb . ,(ly:make-pitch -1 6 BAKIYE))
  (bk . ,(ly:make-pitch -1 6 KUCUK))
  (bbm . ,(ly:make-pitch -1 6 BUYUKMUCENNEB))
  
)

%% Set pitch names.
pitchnames = \makamPitchNames
#(ly:parser-set-note-names parser makamPitchNames)


tuning = #53
\include "regular.ly"

%%% WORK ON EKSIKMIRROREDSLASHED

#(define eksikMirroredSlashedFlat
  (if (defined? 'eksikMirroredSlashedFlat)
   eksikMirroredSlashedFlat #f))

%%% For Turkish Makam, need 6/53, 18/53, 24/53, 30/53, 48/53
makamGlyphs = #`(
   (-48/53 . "accidentals.flat.slashslash")
   (-30/53 . "accidentals.flat")
   (-24/53 . "accidentals.flat.slash")
   (-18/53 . "accidentals.flat.slash")
   (-12/53 . ,(if eksikMirroredSlashedFlat "accidentals.mirroredflat.backslash" "accidentals.mirroredflat"))
   (-6/53  . "accidentals.mirroredfla

Re: Turkish makam using regular.ly

[Torsten Hämmerle]

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.

All the best,
Torsten



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

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Hans Åberg]

> 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.
> Most notably, we'll have to distinguish between the (bigger) standard arrows
> and the smaller multi-arrows.
> There are different versions of single arrow accidentals (with standard
> arrow and smaller arrow) and even the attachment point is different.
> Example: sharp with standard arrow up has the arrow attached on the right,
> the smaller arrows are attached on the left. Double-flats are similar.

I looked a little on that, but I do not have any preference.

> It's sheer co-incidence that I read about your makam activities an so I
> thought I'd drop a note.

It is my idea to use the Helmholtz-Ellis notation for Turkish, Arab and Persian 
music: The single arrows are for Turkish music, and the double arrows are a 
mean value for the microtonal notes in Arab and Persian music, though strictly, 
there is no tradition for their exact values.

There are two caveats with Turkish notation: One is that is is normally noted a 
4th above the sounding pitch.  And common AEU (Arel-Ezgi-Uzdilek) swaps the 
sharp sign for a microtonal sharp.

> All the Gould and Stein-Zimmermann accidentals currently contained in
> Bravura/Dorico are in scope.

You mean i LilyPond? What version.

> Nice to know that somebody will be going to actually use them. ;)
> My samples shown in this thread are far from showing the complete set,
> though.

It is a nice application.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Torsten Hämmerle]

Hans Åberg wrote
> I do not have any preference about the names. You can see the Smufl names
> in the file regularE53smufl.ly I posted.

I actually used the SMuFL names to see what accidentals used are missing in
Emmentaler.
My proposed names are (hopefully) in accordance with LilyPond glyph naming
conventions and I just wanted to give you an impression of how they will
most likely be named.

And thanks for confirming my speculation that the use of Bravura was
primarily because of missing Emmentaler glyphs.

All the best,
Torsten




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

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Torsten Hämmerle]

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.
Most notably, we'll have to distinguish between the (bigger) standard arrows
and the smaller multi-arrows.
There are different versions of single arrow accidentals (with standard
arrow and smaller arrow) and even the attachment point is different.
Example: sharp with standard arrow up has the arrow attached on the right,
the smaller arrows are attached on the left. Double-flats are similar.

It's sheer co-incidence that I read about your makam activities an so I
thought I'd drop a note.

All the Gould and Stein-Zimmermann accidentals currently contained in
Bravura/Dorico are in scope.
Nice to know that somebody will be going to actually use them. ;)
My samples shown in this thread are far from showing the complete set,
though.

All the best,
Torsten




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

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Hans Åberg]

> 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 regular.ly
>> here's the new makam include file:
>> turkish-makam-ADAM.ly
> 
> I think key signatures can also be processed by regular.ly.  So they can be 
> defined in a tuning-independent way (although in this case it's a tuning that 
> looks a lot like 53et).

Yes, that seems to work. Use
  makamHicazkar = #'((0 . 0) (1 . -4/10) (2 . -1/10) (3 . 0) (4 . 0) (5 . 
-4/10) (6 . -1/10))
  makamHicazkar = #(scale-scale makamHicazkar tuning)
where the number 10 is the double of the sharp value 5 in E53, I think, instead 
of
  makamHicazkar = #'((0 . 0) (1 . -24/53) (2 . -6/53) (3 . 0) (4 . 0) (5 . 
-24/53) (6 . -6/53))

So one might define a tone-step variable 1/(2(M - m)) from the ET number, where 
M and m are the ET values for the major and minor seconds, and write the scale 
in terms of multiples of that.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Torsten Hämmerle]

Werner LEMBERG wrote
> Indeed.  I suggest that the tips of the arrows don't cross the staff
> lines.


Hi Werner,

Yes, the by far most difficult task when dealing with arrows (and slahes!)
is to avoid them being obscured by the stave lines.
The smaller the design size, the bigger the problem.

Here are the experiences I made with arrowed/slashed accidentals:

* slashes/arrows must not end within stave lines because that obscures their
form and makes them look shorter than they are
* Either stay within stave spaces or clearly intersect the lines
* For small design sizes, slashes have to become (relatively) thicker and
the "small arrows" need to become (relatively) large in order to keep up
readability.

As far as the tiny arrows are concerned, I'll still have to work on suitable
attachment points.
In the Emmentaler-20 example attached, it can never be avoided that arrows
cross stave lines (up to three arrowheads, and everything has to work for
accidentals on a line and between lines).
But if they cross a line, they'll have to cross it clearly.

But I'll be glad to discuss this once the triple accidentals have been fixed
(I also filled in the missing quarter-note gap)… And these triple
accidentals provide a greatly enhanced enhanced functionality, even if it is
not fully used (yet).

*Example: Changed Metafont accidental arrow parameters*
Up to now, the arrowup/arrowdown parameter has just been a boolean: false
meant "no arrow", true meant "arrow". Now I've changed it to integer values:
0 means "no arrow", positive values mean "that many standard arrows",
negative values mean "that many tiny arrows".
The arrow mechanism technically works for all the flats, naturals and
sharps.

Thanks for the helpful (and encouraging) hint,
Torsten




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

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Werner LEMBERG]

> Sorry, I forgot to attach an screenshot of some of the future
> Emmentaler tiny-arrow accidentals.

Very nice!

> It's not the final design state, there's still some tweaking needed.

Indeed.  I suggest that the tips of the arrows don't cross the staff
lines.


Werner

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Hans Åberg]

> 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 correctly, the main reason for switching to Bravura are
> missing Emmentaler accidental glyphs (obviously the multi-arrowed ones, if I
> look at your definition files).

Yes, that is the only reason. LilyPond has only some of them, so that would 
leave gaps in E53, and also in E72, if one would use it there.

> Incidentally, I'm planning to fill in the Emmentaler gaps in the (very) near
> future directly after issue #3356 has been fixed (in two weeks latest).
> In the course of issue #3356 "add triple flats/sharps" I've unified and
> considerably generalized the Metafont accidental glyph definitions so that
> it is now possible to create a whole variety of arrowed accidentals (the
> existing standard arrows as well as new stacked smaller arrows, "black"
> flats (with filled-in counters), etc.
> 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).

Great!. Then Smufl is not needed at all for these here.

> The new glyph names for the tiny-arrowed accidentals (just the ones you
> currently use are mentioned here) will be
> 
>  accidentals.flatflat.1up
>  accidentals.flatflat.2up
>  accidentals.flatflat.1down
>  accidentals.flatflat.2down
>  accidentals.flat.1up
>  accidentals.flat.2up
>  accidentals.flat.1down
>  accidentals.flat.2down
>  accidentals.natural.1up
>  accidentals.natural.2up
>  accidentals.natural.1down
>  accidentals.natural.2down
>  accidentals.sharp.1up
>  accidentals.sharp.2up
>  accidentals.sharp.1down
>  accidentals.sharp.2down
>  accidentals.doublesharp.1up
>  accidentals.doublesharp.2up
>  accidentals.doublesharp.1down
>  accidentals.doublesharp.2down
> 
> That way, we can gradually make LilyPond's Emmentaler keep up with SMuFL
> accidentals (and Dorico… ;))

I do not have any preference about the names. You can see the Smufl names in 
the file regularE53smufl.ly I posted.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Torsten Hämmerle]

Sorry, I forgot to attach an screenshot of some of the future Emmentaler
tiny-arrow accidentals.
It's not the final design state, there's still some tweaking needed.


 

All the best,
Torsten



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

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Torsten Hämmerle]

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!
If I understand it correctly, the main reason for switching to Bravura are
missing Emmentaler accidental glyphs (obviously the multi-arrowed ones, if I
look at your definition files).

Incidentally, I'm planning to fill in the Emmentaler gaps in the (very) near
future directly after issue #3356 has been fixed (in two weeks latest).
In the course of issue #3356 "add triple flats/sharps" I've unified and
considerably generalized the Metafont accidental glyph definitions so that
it is now possible to create a whole variety of arrowed accidentals (the
existing standard arrows as well as new stacked smaller arrows, "black"
flats (with filled-in counters), etc.
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).

The new glyph names for the tiny-arrowed accidentals (just the ones you
currently use are mentioned here) will be

  accidentals.flatflat.1up
  accidentals.flatflat.2up
  accidentals.flatflat.1down
  accidentals.flatflat.2down
  accidentals.flat.1up
  accidentals.flat.2up
  accidentals.flat.1down
  accidentals.flat.2down
  accidentals.natural.1up
  accidentals.natural.2up
  accidentals.natural.1down
  accidentals.natural.2down
  accidentals.sharp.1up
  accidentals.sharp.2up
  accidentals.sharp.1down
  accidentals.sharp.2down
  accidentals.doublesharp.1up
  accidentals.doublesharp.2up
  accidentals.doublesharp.1down
  accidentals.doublesharp.2down

That way, we can gradually make LilyPond's Emmentaler keep up with SMuFL
accidentals (and Dorico… ;))


All the best,
Torsten




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

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Hans Åberg]

> 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 turn needs to be somewhere where 
LilyPond sees it. On MacOS, I installed it as a global font.

Then the file regularE53smufl.ly is the same as regularE53.ly, only with 
different accidental glyphs. So there is not much extra work to get the 
Helmholtz-Ellis notation, once the Turkish AEU has been done.

Just put the files below in the same directory, and make sure LilyPond sees the 
font Bravura.otf, which is available at
  https://www.smufl.org/fonts/
Then compile regularE53smufl.ly.



regularE53smufl.ly
Description: Binary data


smufldata.ily
Description: Binary data


definitions.ily
Description: Binary data


regular.ly
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Hans Åberg]

> 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:
> 
>> Looks great! A possibility is to add a compile option using Helmholtz-Ellis 
>> arrowed accidentals, which would be better for non-Turkish to approach this 
>> music, and also avoid the confusion about the sharp signs in AEU notation. I 
>> made a example of that, Hicazkâr Peşrevi by Tanburî Cemil Bey. It depends on 
>> Smufl, though.
>> 
>> Also, you might include your new makam file in the LilyPond distribution, 
>> along with regular.ly, Graham Breed I recall okayed that in the past, but 
>> somehow it as not happened so far. Maybe some of the developers here can 
>> tune in on that.
>> 
> I'm currently in an email exchange with Graham Breed about some of this and 
> he also suggested including regular.ly along with though also said the 
> following:
> 
> "Ideally, it would be a function added to the Scheme API so you don't even 
> need an include file."
> 
> Is this doable? We would still need to set our temperament but before I get 
> too far ahead of myself, could that be:
> 
> (was)
> tuning = #53
> %\include "regular.ly"
> 
> (proposal) 
> \eqtemptuning \53
> 
> (something like that)

You might use something like:
   #(define (return-ET ET) ...)
which defines the regular.ly newglyphs and then sets it in the \layout. It is 
also used to retune the standard scales using
  minor = #(scale-scale minor tuning)
etc.

I use in regularE53.ly:
  % 53-ET tonestep
  #(define-public COMMA 6/53)
The 6 comes from LilyPonds use of whole tonesteps in an octave I think.

Then
  % 53-ET alterations in terms of 12-ET whole tones.
  #(define-public FLAT (* -5 COMMA))
  #(define-public SHARP (* 5 COMMA))
is just the differente between the major M and minor m seconds in E53, M = 9, m 
= 4, M - m = 5 which is what sharps ans flats later with.

> Regarding the differences in our key signatures, right I hadn't thought of 
> that! I'll go ahead and change all 0/53 to simply 0. As David Kastrup it 
> doesn't make a difference to Scheme.

I was thinking about 1/53. :-)

Otherwise Scheme has exact and inexact numbers, and the exact numbers don't 
distinguish between integers and rationals as types.

> Figuring out all of those key signatures was a mind bender for me.

One should transpose to C major, and then compute the accidentals there.

> Could you please show a pdf of your Cemil Bey Hicazkar Pesrev using HE 
> arrowed accidentals? And how to make that an option?

I'll send it to you off the list, so as to lessen the traffic here.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Hans Åberg]

> 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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Adam Good]

Hans thank you for passing this along to the dev list, replies below...

On Sat, Oct 20, 2018 at 4:40 AM Hans Åberg  wrote:

>
> Looks great! A possibility is to add a compile option using
> Helmholtz-Ellis arrowed accidentals, which would be better for non-Turkish
> to approach this music, and also avoid the confusion about the sharp signs
> in AEU notation. I made a example of that, Hicazkâr Peşrevi by Tanburî
> Cemil Bey. It depends on Smufl, though.
>
> Also, you might include your new makam file in the LilyPond distribution,
> along with regular.ly, Graham Breed I recall okayed that in the past, but
> somehow it as not happened so far. Maybe some of the developers here can
> tune in on that.
>

I'm currently in an email exchange with Graham Breed about some of this and
he also suggested including regular.ly along with though also said the
following:

"Ideally, it would be a function added to the Scheme API so you don't even
need an include file."

Is this doable? We would still need to set our temperament but before I get
too far ahead of myself, could that be:

(was)
tuning = #53
%\include "regular.ly"

(proposal)
\eqtemptuning \53

(something like that)

Regarding the differences in our key signatures, right I hadn't thought of
that! I'll go ahead and change all 0/53 to simply 0. As David Kastrup it
doesn't make a difference to Scheme. Figuring out all of those key
signatures was a mind bender for me.

Could you please show a pdf of your Cemil Bey Hicazkar Pesrev using HE
arrowed accidentals? And how to make that an option?

Adam
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[David Kastrup]

Hans Åberg  writes:

>> 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:
>> turkish-makam-ADAM.ly
>> 
>> the other file:
>> KEY_SIGNATURES_regularE53_TEST.ly
>> shows the key signatures plus tonic pitch for quite a number of
>> different Turkish makams.
>
> There may be an issue with your key signatures: The first key should
> be (0 . 0) as it refers to the accidental relative C major in key C,
> which by tradition is none. So I got:
> % Makam Hicazkâr:
> makamHicazkar = #'((0 . 0) (1 . -24/53) (2 . -6/53) (3 . 0) (4 . 0) (5
> . -24/53) (6 . -6/53))
>
> Whereas you have:
> HicazZirgule = #'((0 . 0/53)(1 . -24/53)(2 . -6/53)(3 . 0/53)(4
> . 0/53)(5 . -24/53)(6 . -6/53))
> Hicazkar=\HicazZirgule
>
> The only difference is that I have 0 in some positions where you have 0/53.

To Scheme that is no difference.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Hans Åberg]

> 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:
> turkish-makam-ADAM.ly
> 
> the other file:
> KEY_SIGNATURES_regularE53_TEST.ly
> shows the key signatures plus tonic pitch for quite a number of different 
> Turkish makams. 

There may be an issue with your key signatures: The first key should be (0 . 0) 
as it refers to the accidental relative C major in key C, which by tradition is 
none. So I got:
% Makam Hicazkâr:
makamHicazkar = #'((0 . 0) (1 . -24/53) (2 . -6/53) (3 . 0) (4 . 0) (5 . 
-24/53) (6 . -6/53))

Whereas you have:
HicazZirgule = #'((0 . 0/53)(1 . -24/53)(2 . -6/53)(3 . 0/53)(4 . 0/53)(5 . 
-24/53)(6 . -6/53))
Hicazkar=\HicazZirgule

The only difference is that I have 0 in some positions where you have 0/53.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Turkish makam using regular.ly

[Hans Åberg]

> 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 file:
> turkish-makam-ADAM.ly
> 
> the other file:
> KEY_SIGNATURES_regularE53_TEST.ly
> shows the key signatures plus tonic pitch for quite a number of different 
> Turkish makams. 
> 
> Everything transposes like a charm! And I'm ecstatic about all of this.

Looks great! A possibility is to add a compile option using Helmholtz-Ellis 
arrowed accidentals, which would be better for non-Turkish to approach this 
music, and also avoid the confusion about the sharp signs in AEU notation. I 
made a example of that, Hicazkâr Peşrevi by Tanburî Cemil Bey. It depends on 
Smufl, though.

Also, you might include your new makam file in the LilyPond distribution, along 
with regular.ly, Graham Breed I recall okayed that in the past, but somehow it 
as not happened so far. Maybe some of the developers here can tune in on that.

> However! I must be honest, I'm not a coder and math often escapes me so, 
> pretty confused by why the koma definitions are fractions of 10...ie, for a 
> pitch of 4 koma difference, why is it a fraction of 4/10 wow I have no idea.

The one who knows about that is Graham Breed!

> Another question would be, what if I don't want to use 53ET to an octave. How 
> about 24ET octave? How do I calculate the fractions I'd need for determining 
> pitch? 
> 
> Does that question make sense?

For ETs multiples of 12, the regular.ly file is not strictly needed. But 
regular.ly works for any ET.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Turkish makam using regular.ly

[Adam Good]

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 file:
turkish-makam-ADAM.ly

the other file:
KEY_SIGNATURES_regularE53_TEST.ly
shows the key signatures plus tonic pitch for quite a number of different 
Turkish makams. 

Everything transposes like a charm! And I'm ecstatic about all of this.

However! I must be honest, I'm not a coder and math often escapes me so, pretty 
confused by why the koma definitions are fractions of 10...ie, for a pitch of 4 
koma difference, why is it a fraction of 4/10 wow I have no idea.

Another question would be, what if I don't want to use 53ET to an octave. How 
about 24ET octave? How do I calculate the fractions I'd need for determining 
pitch? 

Does that question make sense?

Any help is greatly appreciated!

Adam


KEY_SIGNATURES_regularE53_TEST.ly
Description: Binary data


turkish-makam-ADAM.ly
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel