Turkish makam using regular.ly

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

Turkish makam using regular.ly

Adam Good-3
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

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

KEY_SIGNATURES_regularE53_TEST.ly (6K) Download Attachment
turkish-makam-ADAM.ly (19K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Turkish makam using regular.ly

Hans Åberg-2

> On 20 Oct 2018, at 03:24, Adam Good <[hidden email]> 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
[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 20 Oct 2018, at 03:24, Adam Good <[hidden email]> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Turkish makam using regular.ly

David Kastrup
Hans Åberg <[hidden email]> writes:

>> On 20 Oct 2018, at 03:24, Adam Good <[hidden email]> 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
[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
Hans thank you for passing this along to the dev list, replies below...

On Sat, Oct 20, 2018 at 4:40 AM Hans Åberg <[hidden email]> 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
[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 David Kastrup

> On 20 Oct 2018, at 19:03, David Kastrup <[hidden email]> 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
[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 20 Oct 2018, at 19:25, Adam Good <[hidden email]> 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 <[hidden email]> 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
[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
> Could you please show a pdf of your Cemil Bey Hicazkar Pesrev using HE arrowed accidentals?

I have transposed it down to normal sounding pitch values. But the point is, since it is transposable, one can choose whatever one wants using \transpose g d. Thus getting the MIDI right even though using Turkish note names, which are written a 4th higher than sounding. It might help to remove the confusion about the AEU sharps as well.

> And how to make that an option?

I'll have to return to that, but using essentially the same input code only using a Smufl font and openLilyLib for the arrow glyphs. Thus those that so want can write normal Turkish AEU notation, but also make Helmholtz-Ellis scores at need, which would be great for Western musicians.





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

HicazkarPesrevi.pdf (307K) Download Attachment
=?utf-8?B?SGljYXprYcyCciBQZXPMp3JldmnigJRUYW5idXJpzIIgQ2VtaWwgQmV5IHAx?= =?utf-8?B?LmpwZWc=?= (106K) Download Attachment
=?utf-8?B?SGljYXprYcyCciBQZXPMp3JldmnigJRUYW5idXJpzIIgQ2VtaWwgQmV5IHAy?= =?utf-8?B?LmpwZWc=?= (99K) 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 Adam Good-3

> On 20 Oct 2018, at 19:25, Adam Good <[hidden email]> 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.


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

regularE53smufl.ly (13K) Download Attachment
smufldata.ily (87K) Download Attachment
definitions.ily (17K) Download Attachment
regular.ly (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

<http://lilypond.1069038.n5.nabble.com/file/t3887/multi-arrow-accidentals-example.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

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
[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:
>
> 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
[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 11:03, Torsten Hämmerle <[hidden email]> wrote:
>
> 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.
>
> <http://lilypond.1069038.n5.nabble.com/file/t3887/multi-arrow-accidentals-example.png>

If one typesets the file regularE53smufl.ly, one gets output below. Some single arrow accidentals are also missing in LilyPond, I think.


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

regularE53smufl.pdf (196K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Turkish makam using regular.ly

Torsten Hämmerle
In reply to this post by Werner LEMBERG
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
[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 10:10, Graham Breed <[hidden email]> 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
[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
In reply to this post by Hans Åberg
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
[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
In reply to this post by Hans Åberg
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
[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 21 Oct 2018, at 14:42, Torsten Hämmerle <[hidden email]> 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
[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
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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
123