Re: Persian music

[Werner LEMBERG]

> Many thanks for all your help, we can now write Persian music!!

Great!  Please file a bug report (with all your macros, fonts, etc.)
so that we eventually add Persian accidentals directly to the feta
fonts -- as you can see, the stem widths and the height of the Persian
accidentals don't completely fit to the other accidentals.


Werner


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Persian music package

[Hans Åberg]

> On 31 Jul 2021, at 19:41, Kees van den Doel  wrote:
> 
> A decade ago I wrote the attached header persian.ly which supports Persian 
> music notation + microtuning.
> A hack with a downloaded font is necessary as the Persian microtonal symbols, 
> the koron and sori are not available in Lilypond,
> Strange, as these have been standard for over a century and there is a 
> substantial body of music written requiring it.
> I'm still getting occasional requests for the package and I've used it to 
> transcribe and compose many hours of Persian traditional music.
…
> Anyone have an idea on how I can get it to work with current version?

You might switch to using SmuFl and E53/E72; the accidentals are available in 
the Bravura font. E53 can now be used with Graham Breed's file regular.ly. For 
ETs multiples of 12, it is not needed.

I send you files for E53 and E72 with Helmholtz-Ellis notation. For Persian 
music, the double comma accidental would be suitable.

I recommend using E72 because relative E53/Pythagorean tuning, E72 adjusts the 
diatonic scale to E12, but the neutral seconds change only a few cents.

Adam Good reworked the Turkish makam file, and expressed interest in Arabic and 
Persian music, too. He also felt the the E53/E72 combination was good.

Re: Persian music package

[Kees van den Doel]

Hi Hans,
Thanks but I don't see how this helps.
I don't see the Koron or Sori anywhere in those files you sent. Tuning is
defined correctly in persian.ly already so there is no problem to solve
there.  Problem is it does not compile anymore persian.ly v > 2.12.
Cheers,
Kees

On Sat, Jul 31, 2021 at 11:49 AM Hans Åberg  wrote:

>
> > On 31 Jul 2021, at 19:41, Kees van den Doel  wrote:
> >
> > A decade ago I wrote the attached header persian.ly which supports
> Persian music notation + microtuning.
> > A hack with a downloaded font is necessary as the Persian microtonal
> symbols, the koron and sori are not available in Lilypond,
> > Strange, as these have been standard for over a century and there is a
> substantial body of music written requiring it.
> > I'm still getting occasional requests for the package and I've used it
> to transcribe and compose many hours of Persian traditional music.
> …
> > Anyone have an idea on how I can get it to work with current version?
>
> You might switch to using SmuFl and E53/E72; the accidentals are available
> in the Bravura font. E53 can now be used with Graham Breed's file
> regular.ly. For ETs multiples of 12, it is not needed.
>
> I send you files for E53 and E72 with Helmholtz-Ellis notation. For
> Persian music, the double comma accidental would be suitable.
>
> I recommend using E72 because relative E53/Pythagorean tuning, E72 adjusts
> the diatonic scale to E12, but the neutral seconds change only a few cents.
>
> Adam Good reworked the Turkish makam file, and expressed interest in
> Arabic and Persian music, too. He also felt the the E53/E72 combination was
> good.
>
>
>

Re: Persian music package

[Knute Snortum]

On Sat, Jul 31, 2021 at 10:42 AM Kees van den Doel  wrote:
>
> A decade ago I wrote the attached header persian.ly which supports Persian 
> music notation + microtuning.
> A hack with a downloaded font is necessary as the Persian microtonal symbols, 
> the koron and sori are not available in Lilypond,
> Strange, as these have been standard for over a century and there is a 
> substantial body of music written requiring it.
> I'm still getting occasional requests for the package and I've used it to 
> transcribe and compose many hours of Persian traditional music.
>
> At the time it was version 2.12.2 and I took a snapshot of that version with 
> the additional fonts already installed and an "example" directory to 
> illustrate usage of persian.ly.
>
> Available at https://persianney.com/misc/LilyPond.zip
>
> It does not work anymore with current Lilypond version: when compiling 
> provided  example (after copying font files as documented in persian.ly) it 
> trips over
>
> "(ly:parser-set-note-names parser pitchnames)"
>
> but that may not be all. I noticed there is no type1 directory anymore in the 
> current Lilypond version.
>
> Anyone have an idea on how I can get it to work with current version?  It 
> works perfectly fine with the old version, but it is a bit annoying to be 
> forced to use 2.12.

What about running it thru convert-ly in LilyPond's bin directory?

Re: Persian music package

[Hans Åberg]

> On 31 Jul 2021, at 21:03, Kees van den Doel  wrote:
> 
> Hi Hans,
> Thanks but I don't see how this helps.
> I don't see the Koron or Sori anywhere in those files you sent.

Change the names for the double arrowed accidentals to the ones you want to 
use. They are in smufldata.ily.

> Tuning is defined correctly in persian.ly already so there is no problem to 
> solve there.  

I recall you used E60. E72 might be a better choice. It is your choice though.

Re: Persian music package

[Jean Abou Samra]

Le 01/08/2021 à 00:54, Thomas Morley a écrit :

No idea why "glyph-name-alist" was not converted to
"alteration-glyph-name-alist" (an oversight?), had to do it manually.


Runnning convert-ly from 2.23.3 on this file, I
get the conversion correctly… Not sure why it didn't
work for you?

Cheers,
Jean

Re: Persian music package

[Jean Abou Samra]

Le 01/08/2021 à 08:06, Kees van den Doel a écrit :
convert-ly from LP v2.22.1 also didn;t add the "alteration-" here. 
Windows 10 system.


(Please keep the list posted, so everyone can reply
and benefit from the answers.)

convert-ly from 2.22.1 is expected not to do this,
because the renaming was done in LilyPond 2.23.3.

Best,
Jean

Re: Persian music package

[Kees van den Doel]

OK, so I'll stick with my own convert-ly files as I'm on the
stabgle version.

Problem now seems to be that the positioning tweak in persian.ly such as
"persianStringsXExtents" is no longer working correctly with my file.
Strangely the YExtents and Offset work fine, eg if I make Y-Extent large
the beams move out of the way.

persianStringsXExtents = #`(
   (-3/10 . (0 . 1) )
   (1/5   . (0 . 1.8)) %<--- this should control how "wide" the
koron is but it has no effect
   (0 . (0 . 1))
   (1/2   . (0 . 1))
   (2/5   . (0 . 1))
   (-1/2  . (0 . 1))
   (-3/5  . (0 . 1))
   (-1/10 . (0 . 1))
   (-1. (0 . 1.8))
   ( 1. (0 . 1.3))
)
\override Accidental.X-extent =  #(lambda (grob)
 (cdr (assoc (ly:grob-property grob 'alteration)
  persianStringsXExtents )))

On Sat, Jul 31, 2021 at 11:21 PM Jean Abou Samra  wrote:

> Le 01/08/2021 à 08:06, Kees van den Doel a écrit :
> > convert-ly from LP v2.22.1 also didn;t add the "alteration-" here.
> > Windows 10 system.
>
> (Please keep the list posted, so everyone can reply
> and benefit from the answers.)
>
> convert-ly from 2.22.1 is expected not to do this,
> because the renaming was done in LilyPond 2.23.3.
>
> Best,
> Jean
>

Re: Persian music package

[Jean Abou Samra]

Le 01/08/2021 à 09:58, Kees van den Doel a écrit :
OK, so I'll stick with my own convert-ly files as I'm on the 
stabgle version.


Problem now seems to be that the positioning tweak in persian.ly 
 such as "persianStringsXExtents" is no longer 
working correctly with my file. Strangely the YExtents and Offset work 
fine, eg if I make Y-Extent large the beams move out of the way.


persianStringsXExtents = #`(
       (-3/10 . (0 . 1) )
       (1/5   . (0 . 1.8))     %<--- this should control how "wide" 
the koron is but it has no effect

       (0     . (0 . 1))
       (1/2   . (0 . 1))
       (2/5   . (0 . 1))
       (-1/2  . (0 . 1))
       (-3/5  . (0 . 1))
       (-1/10 . (0 . 1))
       (-1    . (0 . 1.8))
       ( 1    . (0 . 1.3))
)
    \override Accidental.X-extent =  #(lambda (grob)
         (cdr (assoc (ly:grob-property grob 'alteration)
                  persianStringsXExtents )))



Does this code illustrate your problem?

\version "2.22.1"

{
  \override Accidental.X-extent = #'(-2 . 2)
  
}

If so, this comes from the spacing of accidentals
being based on so-called skylines, namely outlines,
and not only extents. This was probably not the
case for accidentals in an old version such as 2.12.
You can observe the skylines using

\version "2.22.1"

#(ly:set-option 'debug-skylines)

\layout {
  \context {
    \Score
    \override Accidental.after-line-breaking =
    #(lambda (grob)
   (set! (ly:grob-property grob 'stencil)
 (ly:stencil-add
   (ly:grob-property grob 'stencil)
   (ly:separation-item::print grob
    % \override Accidental.horizontal-skylines = 
#ly:grob::simple-horizontal-skylines-from-extents

  }
}

{
  \override Accidental.X-extent = #'(-2 . 2)
  
}


Now try adding

\layout {
  \context {
    \Score
    \override Accidental.horizontal-skylines = 
#ly:grob::simple-horizontal-skylines-from-extents

  }
}

and you'll get an effect on spacing.

Best,
Jean

Re: Persian music package

[Thomas Morley]

Am So., 1. Aug. 2021 um 07:24 Uhr schrieb Jean Abou Samra :
>
> Le 01/08/2021 à 00:54, Thomas Morley a écrit :
> > No idea why "glyph-name-alist" was not converted to
> > "alteration-glyph-name-alist" (an oversight?), had to do it manually.
>
> Runnning convert-ly from 2.23.3 on this file, I
> get the conversion correctly… Not sure why it didn't
> work for you?
>
> Cheers,
> Jean

Aargh...
I accidently used convert-ly from 2.22.0.
The one (from 2.23.3) works correctly.

Cheers,
  Harm

Re: Persian music package

[Thomas Morley]

Am So., 1. Aug. 2021 um 09:58 Uhr schrieb Kees van den Doel :
>
> OK, so I'll stick with my own convert-ly files as I'm on the stabgle version.
>
> Problem now seems to be that the positioning tweak in persian.ly such as 
> "persianStringsXExtents" is no longer working correctly with my file. 
> Strangely the YExtents and Offset work fine, eg if I make Y-Extent large the 
> beams move out of the way.
>
> persianStringsXExtents = #`(
>(-3/10 . (0 . 1) )
>(1/5   . (0 . 1.8)) %<--- this should control how "wide" the koron 
> is but it has no effect
>(0 . (0 . 1))
>(1/2   . (0 . 1))
>(2/5   . (0 . 1))
>(-1/2  . (0 . 1))
>(-3/5  . (0 . 1))
>(-1/10 . (0 . 1))
>(-1. (0 . 1.8))
>( 1. (0 . 1.3))
> )
> \override Accidental.X-extent =  #(lambda (grob)
>  (cdr (assoc (ly:grob-property grob 'alteration)
>   persianStringsXExtents )))
>
> On Sat, Jul 31, 2021 at 11:21 PM Jean Abou Samra  wrote:
>>
>> Le 01/08/2021 à 08:06, Kees van den Doel a écrit :
>> > convert-ly from LP v2.22.1 also didn;t add the "alteration-" here.
>> > Windows 10 system.
>>
>> (Please keep the list posted, so everyone can reply
>> and benefit from the answers.)
>>
>> convert-ly from 2.22.1 is expected not to do this,
>> because the renaming was done in LilyPond 2.23.3.
>>
>> Best,
>> Jean

I'd simply drop your overrides for Accidental.Y-extent and Accidental.X-extent.
Let the skylines do their job as already proposed by Jean.

Furthermore I'd replace the override for Accidental.extra-offset by:
\override Accidental.Y-offset =
  #(lambda (grob)
  (cdr
(assoc-get
  (ly:grob-property grob 'alteration)
  persianStringsOffsets)))
Though, why do you use pairs in persianStringsOffsets? Iiuc, you only
use the cdr of each pair.

Cheers,
  Harm

Re: Persian music package

[Kees van den Doel]

On Sun, Aug 1, 2021 at 1:33 AM Jean Abou Samra  wrote:

>
> Does this code illustrate your problem?
>
> \version "2.22.1"
>
> {
>\override Accidental.X-extent = #'(-2 . 2)
>
> }
>

Yes and no. Your code *does* allow me to set the X-extent with those 2
numbers and it has an effect, whereas in persian.ly changing the
X-extent numbers has zero effect.

I added your code but get a runtime error or warning (?) at your
"(ly:stencil-add", referring to attached persianT.ly:

mintty screen dump

Drawing systems...persianT.ly:349:8: In procedure ly_stencil_add in
expression (ly:stencil-add (ly:grob-property grob #)
(ly:separation-item::print grob)): persianT.ly:349:8: Wrong type
(expecting Stencil): #f


I still can't control spacing with those additions by tweaking the #s.

Next, if I just add the latter part of your suggested code (ie not
after-line-breaking = stuff) there is an effect.
I can now move the first troublesome koron around with the X-extent number
pair, but this is no help as the notes don't move out of the way and the
accidental is still on top of one of the notes, so it seems to control
location but not size of the accidental?.

Cheers,
Kees


> If so, this comes from the spacing of accidentals
> being based on so-called skylines, namely outlines,
> and not only extents. This was probably not the
> case for accidentals in an old version such as 2.12.
> You can observe the skylines using
>
> \version "2.22.1"
>
> #(ly:set-option 'debug-skylines)
>
> \layout {
>\context {
>  \Score
>  \override Accidental.after-line-breaking =
>  #(lambda (grob)
> (set! (ly:grob-property grob 'stencil)
>   (ly:stencil-add
> (ly:grob-property grob 'stencil)
> (ly:separation-item::print grob
>  % \override Accidental.horizontal-skylines =
> #ly:grob::simple-horizontal-skylines-from-extents
>}
> }
>
> {
>\override Accidental.X-extent = #'(-2 . 2)
>
> }
>
>
> Now try adding
>
> \layout {
>\context {
>  \Score
>  \override Accidental.horizontal-skylines =
> #ly:grob::simple-horizontal-skylines-from-extents
>}
> }
>
> and you'll get an effect on spacing.
>
> Best,
> Jean
>
>
\version "2.22.0"
%{
Author: Kees van den Doel kvand...@shaw.ca

Init file for Persian music notation.

To  use download  the PostScript  Type  1 Microtonal  Font from  Andrián
Pertout  (http://www.pertout.com/PhD2007Introduction.htm)  and copy  the
.pfbfileintothedirectory
LilyPond/usr/share/lilypond/current/fonts/type1.

This header file defines Persian microtonal alterations, the approximate
quartertone   flat  (koron)  and   the  approximate   quartertone  sharp
(sori). They can be obtained by  appending 'k' (koron) and 'o' (sori) to
the English note symbol.  The  standard symbols for this were introduced
by Vaziri.

Key  signatures are  defined  for all  the  Persian modes,  there are  5
distinct scales  with microtones  and the normal  major scale.   All the
gushe's from all dastgahs can be notated with just these 6.

The note immediately  following a koron is sometimes  (when the interval
defined by  the note  before the koron  and after  the koron is  a minor
third, and the note below the  finalis in esfahan according to some (but
not all)  Persian musicians))  lowered by about  20 cents.  This  is not
notated, but considered part of the scale tuning. To accomodate this for
getting better sounding  MIDI I've introduced the "vlat"  (append 'v' to
the note) to indicate this. Actually  this note should also get a strong
vibrato,  and the  vibrato and  low tuning  are  perceptually integrated
(serialism!). This is just for MIDI and has no effect on the notation.

In the tuning  I've followed "Traditional Persian Art  Music, by Dariush
Tala'i".  The  tunings are  also very close  to those suggested  in "The
Dastgah  Concept in  Persian Music,  by  Hormoz Farhat".   See also  "Le
repertoire-modele  de  la  musique  iranienne,  by  Jean  During"  which
contains measurements  of the  intervals in actual  practice, consistent
with the tuning in this file.

There are no other tuning issues  in Persian music. Because the music is
monophonic  the difference  between  just intonation  (for example)  and
equal temperament is merely academic, because are no chords where out of
tune intervals are noticeable.

Note name suffixes:

ff for double-flat
			f  for flat
			k  for koron (about quarter-flat, -3/10 of whole tone, 60 cent)
			o  for sori  (about quarter-sharp, 2/10 of whole tone, 40 cent)
			s  for sharp
			x  for double-sharp
v  for 20 cent flat tuned note ("vlat", not notated)
fv for flat tuned 20C down (notated as a normal flat)
sv for sharp tuned 20C down (notated as a normal sharp: will never occur in traditional Persian music)

6 Persian  key signatures are  provided they are:

shur?   (shur gushe's with natural 5th degree)
 

Re: Persian music package

[Kees van den Doel]

On Sun, Aug 1, 2021 at 2:29 AM Thomas Morley 
wrote:

>
> I'd simply drop your overrides for Accidental.Y-extent and
> Accidental.X-extent.
> Let the skylines do their job as already proposed by Jean.
>

I should have answered you first. That seems to solve everything! At least
on the demo example, I'll start rerendering all my persian scores and hope
for the best. Also nice to get rid of all those hardcoded offsets.

Jean: Ignore my previous email I think I misunderstood you and merged your
two sample codes which was not intended I guess.


>
> Furthermore I'd replace the override for Accidental.extra-offset by:
> \override Accidental.Y-offset =
>   #(lambda (grob)
>   (cdr
> (assoc-get
>   (ly:grob-property grob 'alteration)
>   persianStringsOffsets)))
> Though, why do you use pairs in persianStringsOffsets? Iiuc, you only
> use the cdr of each pair.
>

Not sure I understand.  persianStringsOffsets is an assoc table with car
the key and cdr the pair to use?
My Scheme is a bit rusty, I once wrote a Scheme interpreter in Scheme but
that was 30 years ago.

Thanks for all the help.

Cheers,
Kees


> Cheers,
>   Harm
>

Re: Persian music package

[Kees van den Doel]

On Sun, Aug 1, 2021 at 2:29 AM Thomas Morley 
wrote:

>
> Furthermore I'd replace the override for Accidental.extra-offset by:
> \override Accidental.Y-offset =
>

Typo I assume and you mean "\override Accidental.extra-offset ="?


>   #(lambda (grob)
>   (cdr
> (assoc-get
>   (ly:grob-property grob 'alteration)
>   persianStringsOffsets)))
>
> That doesn't work because now you take the cdr twice. I think (assoc-get
... is the same as (cdr (assoc .. isn't it?
But assoc-get without cdr is nicer of course, didn't know about that.

Cheers,
Kees

Re: Persian music package

[Kees van den Doel]

On Sun, Aug 1, 2021 at 10:40 AM Kees van den Doel  wrote:

>
>
> On Sun, Aug 1, 2021 at 2:29 AM Thomas Morley 
> wrote:
>
>>
>> Furthermore I'd replace the override for Accidental.extra-offset by:
>> \override Accidental.Y-offset =
>>
>
> Typo I assume and you mean "\override Accidental.extra-offset ="?
>
>
>>   #(lambda (grob)
>>   (cdr
>> (assoc-get
>>   (ly:grob-property grob 'alteration)
>>   persianStringsOffsets)))
>>
>> That doesn't work because now you take the cdr twice. I think (assoc-get
> ... is the same as (cdr (assoc .. isn't it?
> But assoc-get without cdr is nicer of course, didn't know about that.
>

No that doesn't work, I must not understand something. Can you explain why
you suggest the change? If I keep the cdr as in your example it runs but
offsets are no longer right.  It works fine with assoc.

Cheers,
Kees

Re: Persian music package

[Thomas Morley]

Am Mo., 2. Aug. 2021 um 18:33 Uhr schrieb Kees van den Doel :
>
>
> Sorry, keep forgetting to "reply-all"...
> -- Forwarded message -
> From: Kees van den Doel 
> Date: Mon, Aug 2, 2021 at 9:24 AM
> Subject: Re: Persian music package
> To: Thomas Morley 
>
>
> Too many things wrong with that, starting with missing sori symbol, wrong 
> koron symbol in key signature.
>  'v' should affect only MIDI etc. The example mehr.ly  in the example/ in my 
> zip file is a better test, shur.ly I just posted to illustrate unmetered 
> notes.
>
> Cheers,
> Kees
> Kees
>
Please have a look at the attached pdf. Is it correct?
It's pretty difficult for me to get it right, not knowing persian music at all.

Cheers,
  Harm


persian-smufl-test.pdf
Description: Adobe PDF document

Re: Persian music package

[Kees van den Doel]

Looks good. For testing just compare output as gotten from my package with
old LP version. I haven't run all regression on the new persian.ly (that
works with current LP version) yet.

It's actually quite simple: everything is the same except for 2 new
accidentals Koron and Sori which affect pitch as documented. The -v suffix
affects only MIDI and could be dropped, was more of an experiment.
It seemed I could not add  these extra accidentals (and their pitch in
MIDI) but had to redefine all accidentals.
Ugly but it has worked fine for over a decade.

Proper integration with LP would be better but hasn't happened.

Anyways it's now working fine with current version so I'm happy.

Thanks,
Kees

On Tue, Aug 3, 2021 at 7:32 AM Thomas Morley 
wrote:

> Am Mo., 2. Aug. 2021 um 18:33 Uhr schrieb Kees van den Doel <
> kvd...@gmail.com>:
> >
> >
> > Sorry, keep forgetting to "reply-all"...
> > -- Forwarded message -
> > From: Kees van den Doel 
> > Date: Mon, Aug 2, 2021 at 9:24 AM
> > Subject: Re: Persian music package
> > To: Thomas Morley 
> >
> >
> > Too many things wrong with that, starting with missing sori symbol,
> wrong koron symbol in key signature.
> >  'v' should affect only MIDI etc. The example mehr.ly  in the example/
> in my zip file is a better test, shur.ly I just posted to illustrate
> unmetered notes.
> >
> > Cheers,
> > Kees
> > Kees
> >
> Please have a look at the attached pdf. Is it correct?
> It's pretty difficult for me to get it right, not knowing persian music at
> all.
>
> Cheers,
>   Harm
>

Re: Persian music package

[Thomas Morley]

Am Di., 3. Aug. 2021 um 17:03 Uhr schrieb Kees van den Doel :
>
> Looks good. For testing just compare output as gotten from my package with 
> old LP version. I haven't run all regression on the new persian.ly (that 
> works with current LP version) yet.

Ok, then you may be interested in the attached .zip.
There I made accidentals from the Bravura-font work.
It's all compilable with 2.22.0
Nevertheless, you will need to review/convert your old files, since
2.12. a lot happened.

> It's actually quite simple: everything is the same except for 2 new 
> accidentals Koron and Sori which affect pitch as documented. The -v suffix 
> affects only MIDI and could be dropped, was more of an experiment.
> It seemed I could not add  these extra accidentals (and their pitch in MIDI) 
> but had to redefine all accidentals.
> Ugly but it has worked fine for over a decade.
>
> Proper integration with LP would be better but hasn't happened.

The only thing which prevents us from doing so is indeed the absence
of accidental-glyphs for Sori and Koron.
I was going to write a bug-report, before I noticed we already have one:
https://gitlab.com/lilypond/lilypond/-/issues/738
And the there attached .zip contains already your persian.ly  lol

Cheers,
  Harm

Re: Persian music package

[Thomas Morley]

Am Di., 3. Aug. 2021 um 18:18 Uhr schrieb Thomas Morley
:
>
> Am Di., 3. Aug. 2021 um 17:03 Uhr schrieb Kees van den Doel 
> :
> >
> > Looks good. For testing just compare output as gotten from my package with 
> > old LP version. I haven't run all regression on the new persian.ly (that 
> > works with current LP version) yet.
>
> Ok, then you may be interested in the attached .zip.

Now attached ...
<>

Re: Persian music package

[Adam Good]

Hi Everyone,
I just had a chance to look at this thread today. Thomas I downloaded and
ran persian-smufl and it seems to work great.

Seems like the main thing holding up a persian.ly is the absence of two
glyphs. I'd be happy to help sponsor the creation of koron and sori
symbols...anyone else?

Adam


On Tue, Aug 3, 2021 at 12:19 PM Thomas Morley 
wrote:

> Am Di., 3. Aug. 2021 um 18:18 Uhr schrieb Thomas Morley
> :
> >
> > Am Di., 3. Aug. 2021 um 17:03 Uhr schrieb Kees van den Doel <
> kvd...@gmail.com>:
> > >
> > > Looks good. For testing just compare output as gotten from my package
> with old LP version. I haven't run all regression on the new persian.ly
> (that works with current LP version) yet.
> >
> > Ok, then you may be interested in the attached .zip.
>
> Now attached ...
>

Re: Persian music package

[Kees van den Doel]

Hi,

Please include the list in reply.

I have no Idea what E72 and E60 etc. is, to me it sounds like European
freeway names.

If you guys want to merge it into main LP distribution that's great, and
I'll be happy to help on Persian music issues but I'm fairly useless on
technical details.

The docs inside persian.ly are intended to give you all the info on Persian
music needed for correct typesetting, but if something is lacking let me
know and I'll add it when I update the package.

However you can always check how things should look/sound by downloading
the original package as it is working perfectly with old LP (and probably
with new, but I haven't regressed all my scores)  and has been extensively
used for over a decade.
MIDI tuning  is very important esp. if you are learning Persian tuning.

Cheers,
Kees

On Fri, Aug 6, 2021 at 1:56 AM Hans Åberg  wrote:

>
> > On 31 Jul 2021, at 22:30, Kees van den Doel  wrote:
> >
> > On Sat, Jul 31, 2021 at 1:25 PM Hans Åberg  wrote:
> >
> > Change the names for the double arrowed accidentals to the ones you want
> to use. They are in smufldata.ily.
> >
> >> Tuning is defined correctly in persian.ly already so there is no
> problem to solve there.
> >
> > I recall you used E60. E72 might be a better choice. It is your choice
> though.
> >
> > Sorry but I have no idea what you are talking about.
>
> I misremembered, I see now that the file persian.ly I have uses E53 and
> regular.ly:
>
> However, if you would want to make a version that is in the LilyPond
> distribution, that currently does not have the file regular.ly, you might
> make an E72 version, the two comma alterations actually being in E36. This
> is what Adam Good did with the rewritten makam file.
>
> The neutral seconds in E72, relative E53, only change a few cents, just
> adjusting the diatonic scales to E12. So it is a good alternative when
> mixing with E12 instruments, at least from the theoretical point of view:
> It would be nice to hear what somebody that knows this music well thinks.
>
>
>

Re: Persian music package

[Hans Åberg]

> On 6 Aug 2021, at 16:45, Kees van den Doel  wrote:
> 
> Please include the list in reply.

As you posted an email intended to be private, a correction: I did not 
misremember, you really do use E60. :-)

> I have no Idea what E72 and E60 etc. is, to me it sounds like European 
> freeway names. 

It is Scala notation for the ETs: E72 = 72 ET, etc.

> If you guys want to merge it into main LP distribution that's great, and I'll 
> be happy to help on Persian music issues but I'm fairly useless on technical 
> details.
> 
> The docs inside persian.ly are intended to give you all the info on Persian 
> music needed for correct typesetting, but if something is lacking let me know 
> and I'll add it when I update the package.
> 
> However you can always check how things should look/sound by downloading the 
> original package as it is working perfectly with old LP (and probably with 
> new, but I haven't regressed all my scores)  and has been extensively used 
> for over a decade.
> MIDI tuning  is very important esp. if you are learning Persian tuning.

If this is the case, you should use preferably E53, but as it requires Graham 
Breed's file regular.y which currently is not in the LilyPond distribution, the 
next best thing would be E72, and as Persian music raises by to commas (E72 
tonesteps), it is in actuality in E36. So I would recommend using those. It 
would be nice to hear what somebody that knows this music well thinks about how 
these different tuning sound with Persian music.

Re: Persian music package

[Kees van den Doel]

Well I know Persian music very well, and the tuning as-is is perfect, so
I'm not sure what we are talking about here.
Persian music doesn't "raise by commas". There are no "different tunings",
there is the current MIDI tuning which is correct and anything different is
wrong.

It's working fine now, nothing is broken that needs to be fixed??

As far as I'm concerned the problem of upgrading persian.ly to 2.22 is
solved.

Cheers,
Kees

On Fri, Aug 6, 2021 at 9:05 AM Hans Åberg  wrote:

>
> > On 6 Aug 2021, at 16:45, Kees van den Doel  wrote:
> >
> > Please include the list in reply.
>
> As you posted an email intended to be private, a correction: I did not
> misremember, you really do use E60. :-)
>
> > I have no Idea what E72 and E60 etc. is, to me it sounds like European
> freeway names.
>
> It is Scala notation for the ETs: E72 = 72 ET, etc.
>
> > If you guys want to merge it into main LP distribution that's great, and
> I'll be happy to help on Persian music issues but I'm fairly useless on
> technical details.
> >
> > The docs inside persian.ly are intended to give you all the info on
> Persian music needed for correct typesetting, but if something is lacking
> let me know and I'll add it when I update the package.
> >
> > However you can always check how things should look/sound by downloading
> the original package as it is working perfectly with old LP (and probably
> with new, but I haven't regressed all my scores)  and has been extensively
> used for over a decade.
> > MIDI tuning  is very important esp. if you are learning Persian tuning.
>
> If this is the case, you should use preferably E53, but as it requires
> Graham Breed's file regular.y which currently is not in the LilyPond
> distribution, the next best thing would be E72, and as Persian music raises
> by to commas (E72 tonesteps), it is in actuality in E36. So I would
> recommend using those. It would be nice to hear what somebody that knows
> this music well thinks about how these different tuning sound with Persian
> music.
>
>

Re: Persian music package

[Hans Åberg]

> On 6 Aug 2021, at 18:46, Kees van den Doel  wrote:
> 
> Well I know Persian music very well, and the tuning as-is is perfect, so I'm 
> not sure what we are talking about here.
> Persian music doesn't "raise by commas". There are no "different tunings", 
> there is the current MIDI tuning which is correct and anything different is 
> wrong.

The values you have set are wrong from the theoretical point of view:

Persian music uses the Pythagorean tuning of which E53 is a close 
approximation. The average values that Hormoz Farhat's Dastgah book indicates 
is a neutral second raised about two commas from the minor second, which is 
what one typically uses.

E53 has a sharp that is 5 commas, but a minor second m = 4 and a major second M 
= 5, which is what Graham Breed's file regular.ly does.

You have merely divided the LilyPond sharp into 5 parts, then using the 
theoretical comma values indicated above, without adjusting the minor and major 
seconds, so you land on E60.

Re: Persian music package

[Kees van den Doel]

Please include the list when replying.
I think this conversation serves no further purpose, so I won't reply
anymore.
K

On Fri, Aug 6, 2021 at 12:46 PM Hans Åberg  wrote:

> It is on stringed instruments one gets the Pythagorean tuning. A flute
> does not have such relative pitch references.
>
>
> > On 6 Aug 2021, at 21:41, Kees van den Doel  wrote:
> >
> > Excuse me for being direct, but this is nonsense. It's nice you've read
> that (outdated) book but I've been actively performing Persian music for
> decades and I know how we tune. If you want to learn check out my website
> https://persianney.com.
> >
> > Kees
> >
> >
> >
> > On Fri, Aug 6, 2021 at 11:47 AM Hans Åberg  wrote:
> >
> > > On 6 Aug 2021, at 18:46, Kees van den Doel  wrote:
> > >
> > > Well I know Persian music very well, and the tuning as-is is perfect,
> so I'm not sure what we are talking about here.
> > > Persian music doesn't "raise by commas". There are no "different
> tunings", there is the current MIDI tuning which is correct and anything
> different is wrong.
> >
> > The values you have set are wrong from the theoretical point of view:
> >
> > Persian music uses the Pythagorean tuning of which E53 is a close
> approximation. The average values that Hormoz Farhat's Dastgah book
> indicates is a neutral second raised about two commas from the minor
> second, which is what one typically uses.
> >
> > E53 has a sharp that is 5 commas, but a minor second m = 4 and a major
> second M = 5, which is what Graham Breed's file regular.ly does.
> >
> > You have merely divided the LilyPond sharp into 5 parts, then using the
> theoretical comma values indicated above, without adjusting the minor and
> major seconds, so you land on E60.
> >
>
>

Re: Persian music package

[Hans Åberg]

It is on stringed instruments one gets the Pythagorean tuning. A flute does not 
have such relative pitch references.


> On 6 Aug 2021, at 21:41, Kees van den Doel  wrote:
> 
> Excuse me for being direct, but this is nonsense. It's nice you've read that 
> (outdated) book but I've been actively performing Persian music for decades 
> and I know how we tune. If you want to learn check out my website 
> https://persianney.com.
> 
> Kees
> 
> 
> 
> On Fri, Aug 6, 2021 at 11:47 AM Hans Åberg  wrote:
> 
>> On 6 Aug 2021, at 18:46, Kees van den Doel  wrote:
>> 
>> Well I know Persian music very well, and the tuning as-is is perfect, so I'm 
>> not sure what we are talking about here.
>> Persian music doesn't "raise by commas". There are no "different tunings", 
>> there is the current MIDI tuning which is correct and anything different is 
>> wrong.
> 
> The values you have set are wrong from the theoretical point of view:
> 
> Persian music uses the Pythagorean tuning of which E53 is a close 
> approximation. The average values that Hormoz Farhat's Dastgah book indicates 
> is a neutral second raised about two commas from the minor second, which is 
> what one typically uses.
> 
> E53 has a sharp that is 5 commas, but a minor second m = 4 and a major second 
> M = 5, which is what Graham Breed's file regular.ly does.
> 
> You have merely divided the LilyPond sharp into 5 parts, then using the 
> theoretical comma values indicated above, without adjusting the minor and 
> major seconds, so you land on E60.
>