lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Turkish makam


From: Luca Fascione
Subject: Re: Turkish makam
Date: Mon, 16 Jan 2023 10:30:18 +0100

On Sun, Jan 15, 2023 at 3:49 PM Hans Åberg <haberg-1@telia.com> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]