Re: preliminary proposal: New Unicode characters for Arabic music half-flat and half-sharp symbols

[Garth Wallace via Unicode]

On Wed, May 16, 2018 at 12:42 AM, Hans Åberg via Unicode <
unicode@unicode.org> wrote:

>
> > On 16 May 2018, at 00:48, Ken Whistler via Unicode 
> wrote:
> >
> > On 5/15/2018 2:46 PM, Markus Scherer via Unicode wrote:
> >> I am proposing the addition of 2 new characters to the Musical Symbols
> table:
> >>
> >> - the half-flat sign (lowers a note by a quarter tone)
> >> - the half-sharp sign (raises a note by a quarter tone)
> >>
> >> In an actual proposal, I would expect a discussion of whether you are
> proposing to encode established symbols, or whether you are proposing new
> symbols to be adopted by the community (in which case Unicode would
> probably wait & see if they get established).
> >>
> >> A proposal should also show evidence of usage and glyph variations.
> >
> > And should probably refer to the relationship between these signs and
> the existing:
>
> It would be best to encode the SMuFL symbols, which is rather
> comprehensive and include those:
>  https://www.smufl what should be unified.org 
>  http://www.smufl.org/version/latest/


If you want to write up a proposal for that entire set of characters,
godspeed and good luck.

> U+1D132 MUSICAL SYMBOL QUARTER TONE SHARP
> > U+1D133 MUSICAL SYMBOL QUARTER TONE FLAT
> >
> > which are also half-sharp or half-flat accidentals.
> >
> > The wiki on flat signs shows this flat with a crossbar, as well as a
> reversed flat symbol, to represent the half-flat.
> >
> > And the wiki on sharp signs shows this sharp minus one vertical bar to
> represent the half-sharp.
> >
> > So there may be some use of these signs in microtonal notation, outside
> of an Arabic context, as well. See:
> >
> > https://en.wikipedia.org/wiki/Accidental_(music)#Microtonal_notation
>
> These are otherwise originally the same, but has since drifted. So whether
> to unify them or having them separate might be best to see what SMuFL does,
> as they are experts on the issue.
>

SMuFL's standards on unification are not the same as Unicode's. For one
thing, they re-encode Latin letters and Arabic digits multiple times for
various different uses (such as numbers used in tuplets and those used in
time signatures). There are duplicates all over the place, like how the
half-sharp symbol is encoded at U+E282 as
"accidentalQuarterToneSharpStein", at U+E422 as
"accidentalWyschnegradsky3TwelfthsSharp", at U+ED35 as
"accidentalQuarterToneSharpArabic", and at U+E444 as "accidentalKomaSharp".
They are graphically identical, and the first three even all mean the same
thing, a quarter tone sharp! The last, though meaning something different
in Turkish context (Turkish theory divides tones into 1/9-tones), is still
clearly the same symbol. The "Arabic accidentals" section even re-encodes
all of the non-microtonal accidentals (basic sharp, flat, natural, etc.)
for no reason that I can determine.

There are definitely many things in SMuFL where you could make a claim that
they should be in Unicode proper. But not all, and the standard itself is a
bit of a mess.

Re: L2/18-181

[Richard Wordingham via Unicode]

On Thu, 17 May 2018 01:24:09 +0100
Michael Everson via Unicode  wrote:

> It sounds to me like a fault in the keyboard software, which could be
> fixed by the people who own and maintain that software.

We had this discussion a few years ago.  See
http://www.unicode.org/mail-arch/unicode-ml/y2015-m08/0036.html.

Richard.

Re: L2/18-181

[Richard Wordingham via Unicode]

On Wed, 16 May 2018 17:41:12 -0500
Anshuman Pandey via Unicode  wrote:

> > 3. Keyboard design is more difficult because consonants like ক্ষ
> > are encoded as conjunct forms instead of atomic characters.  
> 
> Ignorant question on my part: is it difficult to use character
> sequences as labels for keys? I see keys for both क्ष and ज्ञ on the
> iOS Hindi keyboard, and त्र is tucked away under त.

It can be.  It depends on the technology.

Pure X seems to be the worst.  At the basic level, one has a
bewildering map of key plus active modifier key to a single
Unicode character. (The space also include function keys.)  An
*application* can map keys to strings, but I know of no way of doing
that to all of a user's applications, both those running and those that
will run.  Even the logic for dead keys has to be applied by the
application, though I believe there are standard libraries that will
handle that.

The old method on Windows uses sets of data tables that may be termed
keyboards.  Populated sets are saved as DLLs, and there are limits on
what they can contain.  Windows' Microsoft Keyboard Layout Creator
(MSKLC) is a popular tool for creating and packaging these DLLs.
A key plus it modifiers can be mapped to:

1) A sequence of UTF-16 code units.  The documented limit is, I believe
4, but there are reports of people being able to use 6.  The four
sequences listed above each constitute a sequence of 3 code units, so
they can be readily accommodated.  This technique may well not work
for a script in the SMP, and I think one cannot use the MSKLC simply to
create the DLLs storing long sequences.  So here is an added layer of
complexity, though not relevant to the Bengali script.

2) A key can be designated a 'dead key'.  I think it has to have a
fallback to a BMP character, or rather, a single UTF-16 code unit.  On
then pressing a key that maps to a single code unit, this is converted
to another single code unit, which is the character that the
combination types.  The restriction is built into the data structure.

There is a technique to chain dead keys, but that is not relevant to
the difficulty or ease of typing ligatures.

The next level up I am acquainted with is the level of input methods.
Here, one types a sequence of characters on a 'simple' keyboard, and
this sequence controls the derivation of characters being input to the
application.  Modifier keys may be available to influence this
derivation.  Now, some of these input methods may be unreliable, and
there may be problems for users who can switch between simple
keyboards, e.g. US and British, or US and Hindi.

If this type of method works, then inputting sequences in response to
a single keystroke is not a problem.  Multiple key strokes can be a
different matter, as the interface with applications may be ill-defined
or broken.  I have found this a problem with using the backslash key to
cycle through candidate characters, and deleting SMP characters in
LibreOffice has in the past resulted in the creation of lone surrogates.

Now, writing these input methods can be easy.  I have fairly simple
input methods for inputting both true characters and sequences
perceived as characters for Emacs, ibus (using KMfL) and fcitx (using
M17n).  However, the ibus method has been unreliable in the past, and I
have fallen back to a simple X keyboard map.  When I do that, I lose
the ability to input sequences by a single keystroke.

Richard.

Re: L2/18-181

[Michael Everson via Unicode]

It sounds to me like a fault in the keyboard software, which could be fixed by 
the people who own and maintain that software.

> On 17 May 2018, at 01:20, Richard Wordingham via Unicode 
>  wrote:
> 
> On Thu, 17 May 2018 00:34:35 +0100
> Michael Everson via Unicode  wrote:
> 
>> This is not a fault of the encoding.
>> 
>>> On 16 May 2018, at 23:01, Richard Wordingham via Unicode
>>>  wrote:
>>> 
>>> I think simple Windows keyboards have a limit of 4 16-bit code
>>> units; for an Indic SMP script, one couldn't map  to a single
>>> key, as it would require 6 code units.  
> 
> It is a consequence of the policy of avoiding precomposed characters.
> If there were a precomposed character for , the keyboard could emit
> that character - job done.
> 
> One objection is that one would need a sequence of decompositions:
> 
>  = 
>  = 
> 
> Some people are vehemently opposed to unnatural characters like
> .
> 
> Presumable the official view is that Windows Text Services have taken us
> beyond that point, and the likes of  above are not needed.
> 
> If X persists, perhaps named sequences should be assigned numbers so
> that X can make a generic allocation of keysym codes to named
> sequences.
> 
> Richard. 

Re: L2/18-181

[Richard Wordingham via Unicode]

On Thu, 17 May 2018 00:34:35 +0100
Michael Everson via Unicode  wrote:

> This is not a fault of the encoding.
> 
> > On 16 May 2018, at 23:01, Richard Wordingham via Unicode
> >  wrote:
> > 
> > I think simple Windows keyboards have a limit of 4 16-bit code
> > units; for an Indic SMP script, one couldn't map  to a single
> > key, as it would require 6 code units.  

It is a consequence of the policy of avoiding precomposed characters.
If there were a precomposed character for , the keyboard could emit
that character - job done.

One objection is that one would need a sequence of decompositions:

 = 
 = 

Some people are vehemently opposed to unnatural characters like
.

Presumable the official view is that Windows Text Services have taken us
beyond that point, and the likes of  above are not needed.

If X persists, perhaps named sequences should be assigned numbers so
that X can make a generic allocation of keysym codes to named
sequences.

Richard. 

Re: L2/18-181

[Michael Everson via Unicode]

And Icelandic. And Irish. And so on. 

> On 16 May 2018, at 23:41, Anshuman Pandey via Unicode  
> wrote:
> 
>> 2. Collation is different between the Assamese and Bengali languages,
>> and code point order should reflect collation order.
> 
> The same issue applies to dictionary order for Hindi, Marathi, which
> differ from the conventional Sanskrit order for Devanagari.

Re: L2/18-181

[Michael Everson via Unicode]

This is not a fault of the encoding.

> On 16 May 2018, at 23:01, Richard Wordingham via Unicode 
>  wrote:
> 
> I think simple Windows keyboards have a limit of 4 16-bit code units;
> for an Indic SMP script, one couldn't map  to a single key, as it
> would require 6 code units.

Fwd: L2/18-181

[Anshuman Pandey via Unicode]

> On May 16, 2018, at 3:46 PM, Doug Ewell via Unicode  
> wrote:
>
> http://www.unicode.org/L2/L2018/18181-n4947-assamese.pdf
>
> This is a fascinating proposal to disunify the Assamese script from
> Bengali on the following bases:

‘Fascinating’ is a not a term I’d use for this proposal.

If folks are interested in a valid proposal for disunification of
Bengali, please look at the proposal for Tirhuta.

> 1. The identity of Assamese as a script distinct from Bengali is in
> jeopardy.

This is not a technical matter. Moreover, its typical rhetoric used by
various language communities in South Asia. Fairly standard fare for
those familiar with such issues.

The proposal needs to show how the two scripts differ, ie. conjuncts,
CV ligatures, etc. The number forms are similar to those already
encoded. Again, cf. Tirhuta.

> 2. Collation is different between the Assamese and Bengali languages,
> and code point order should reflect collation order.

The same issue applies to dictionary order for Hindi, Marathi, which
differ from the conventional Sanskrit order for Devanagari.
Orthographies for various languages put conjuncts and other things at
the end, which are not considered atomic letters. Nothing special in
this regard for Assamese and Bengali.

> 3. Keyboard design is more difficult because consonants like ক্ষ
> are encoded as conjunct forms instead of atomic characters.

Ignorant question on my part: is it difficult to use character
sequences as labels for keys? I see keys for both क्ष and ज्ञ on the
iOS Hindi keyboard, and त्र is tucked away under त.

> 4. The use of a single encoded script to write two languages forces
> users to use language identifiers to identify the language.

Same applies to each of the 40+ varieties of Hindi, as well as
Marathi, etc. Another ignorant question: how to identify the various
languages that use Arabic and Cyrillic?

> 5. Transliteration of Assamese into a different script is problematic
> because letters have different phonological value in Assamese and
> Bengali.

Transliteration or transcription? In any case, this applies to other
languages written using similar scripts: a Marathi speaker pronounces
ज and ऋ differently than a Hindi speaker does.

> It will be interesting to see where this proposal goes.

Hopefully, it does not go too far. What it proposes is contrary to
Unicode and redundant.

> Given that all
> or most of these issues can be claimed for English, French, German,
> Spanish, and hundreds of other languages written in the Latin script, if
> the Assamese proposal is approved we can expect similar disunification
> of the Latin script into language-specific alphabets in the future.

Fascinating. I mean, terrible.

All my best,
Anshuman

Re: L2/18-181

[Richard Wordingham via Unicode]

On Wed, 16 May 2018 13:46:22 -0700
Doug Ewell via Unicode  wrote:

> http://www.unicode.org/L2/L2018/18181-n4947-assamese.pdf
> 
> This is a fascinating proposal to disunify the Assamese script from
> Bengali on the following bases:

> 3. Keyboard design is more difficult because consonants like ক্ষ
> are encoded as conjunct forms instead of atomic characters.

Users of X do have a valid gripe here.  An X keyboard mapping can only
accept single codepoints; sequences require explicit support by the
application.  Advanced applications get round this by using an input
method, but they can be unreliable, particularly over networks.  (I
ended up creating an X keyboad mapping as back-up, but when I use it
I lose all my 'ligature' keys.) However, that seems to be an argument
for deprecating Bengali, rather than for disunifying Bengali and
Assamese.

I think simple Windows keyboards have a limit of 4 16-bit code units;
for an Indic SMP script, one couldn't map  to a single key, as it
would require 6 code units.

It would be handy to have characters whose only use was to input text;
adding characters that are subject to composition exclusions would not
change whether text is in NFC, in NFD, or neither. 

Of course, if the scripts were disunified, would we have to ban Assamese
domain names in the new 'Assamese script' as they would be ambiguous
with Bengali names.

Richard.

Re: Choosing the Set of Renderable Strings

[Richard Wordingham via Unicode]

On Wed, 16 May 2018 05:23:08 -0800
James Kass via Unicode  wrote:

> Note that although the proposal gave canonical combining class
> zero to both the tone marks and the vowel signs, the on-line Unicode
> data gives canonical combining class 230 to the tone marks.

There were several changes from ccc=0 to non-zero that were sneaked in
between the UTC agreeing to proceed with the proposal and Unicode 5.2
being published.  That may have been a test of vigialnce; we failed.  I
have seen no benefit from the changes - U+A160 TAI THAM SIGN SAKOT is
not a virama (it should not appear in valid text), and having the tone
marks and the invisible stacker have distinct non-zero classes has
caused lots of irritation.

We should probably have risked Tai Tham being excluded from the BMP and
gone for the Tibetan model; normalised would not then damage Tai tham
text.

> > **The placement may be different to that of MAI KANG
> > in /bɔː waː/ ᨷᩴ᩠᩵ᩅᩣ  > SIGN AA> or ᨷᩴ᩠ᩅ᩵ᩣ  > SIGN AA> - I don't know whether the first or the second
> > tone mark is dropped.  

> FWIW, neither is dropped in the display here, although they don't
> display identically.  The first string shows TONE-1 positioned to the
> right of MAI KANG, the second string superimposes them.  (Windows 7
> running LibreOffice in order to enable the USE from HarfBuzz.)

The full uncontracted writing is .  Both syllables have TONE-1, but I have not seen two identical
tone marks from different phonetic syllables in the same stack.  The
person typing the contraction drops a tone mark, not the rendering
system.

> Substituting U+1A36 TAI THAM LETTER NA for BA in the above strings,
> ᨶᩴ᩠᩵ᩅᩣ  ᨶᩴ᩠ᩅ᩵ᩣ, and trying to get the ligature are in the attached
> *.PNG file. Here's the four strings for the PNG:
> 
> \u1A36\u1A74\u1A75\u1A60\u1A45\u1A63
> \u1A36\u1A74\u1A60\u1A45\u1A75\u1A63
> \u1A36\u1A75\u1A63\u1A74
> \u1A36\u1A63\u1A74\u1A75

A lot of fonts have trouble ligating NA and AA when there is material
between them.  (Hint: Classify all non-spacing subscript consonants as
marks, and spacing subscript consonants as bases, and set the ligating
lookup to ignore marks.)

Your example appears to be using the font called 'A Tai Tham KH New'.
While the only way to type Pali _bho_ 'O' after other text in this font
or 'A Tai Tham KH' is to enter the correct sequence , the former font cannot render Pali _mano_ 'mind' (also used in
Northern Thai and probably also Tai Khuen) if one types the correct
sequence .  One has to type !  The *older* font 'A Tai Tham KH (at Version 2.0) does render the
correct spelling properly.  As an example of correct rendering, I
include the Pali for 'O mind!', _bho mano_, encoded  , as rendered by the Lamphun font.

Richard.

L2/18-181

[Doug Ewell via Unicode]

http://www.unicode.org/L2/L2018/18181-n4947-assamese.pdf

This is a fascinating proposal to disunify the Assamese script from
Bengali on the following bases:

1. The identity of Assamese as a script distinct from Bengali is in
jeopardy.

2. Collation is different between the Assamese and Bengali languages,
and code point order should reflect collation order.

3. Keyboard design is more difficult because consonants like ক্ষ
are encoded as conjunct forms instead of atomic characters.

4. The use of a single encoded script to write two languages forces
users to use language identifiers to identify the language.

5. Transliteration of Assamese into a different script is problematic
because letters have different phonological value in Assamese and
Bengali.

It will be interesting to see where this proposal goes. Given that all
or most of these issues can be claimed for English, French, German,
Spanish, and hundreds of other languages written in the Latin script, if
the Assamese proposal is approved we can expect similar disunification
of the Latin script into language-specific alphabets in the future.

--
Doug Ewell | Thornton, CO, US | ewellic.org

Re: preliminary proposal: New Unicode characters for Arabic music half-flat and half-sharp symbols

[Hans Åberg via Unicode]

> On 16 May 2018, at 09:42, Hans Åberg via Unicode  wrote:
> 
>> On 16 May 2018, at 00:48, Ken Whistler via Unicode  
>> wrote:
>> 
>>> A proposal should also show evidence of usage and glyph variations.
>> 
>> And should probably refer to the relationship between these signs and the 
>> existing:
> 
> It would be best to encode the SMuFL symbols, which is rather comprehensive 
> and include those:
> https://www.smufl.org
> http://www.smufl.org/version/latest/
> 
>> U+1D132 MUSICAL SYMBOL QUARTER TONE SHARP
>> U+1D133 MUSICAL SYMBOL QUARTER TONE FLAT
>> 
>> which are also half-sharp or half-flat accidentals.
>> 
>> The wiki on flat signs shows this flat with a crossbar, as well as a 
>> reversed flat symbol, to represent the half-flat.
>> 
>> And the wiki on sharp signs shows this sharp minus one vertical bar to 
>> represent the half-sharp.
>> 
>> So there may be some use of these signs in microtonal notation, outside of 
>> an Arabic context, as well. See:
>> 
>> https://en.wikipedia.org/wiki/Accidental_(music)#Microtonal_notation
> 
> These are otherwise originally the same, but has since drifted. So whether to 
> unify them or having them separate might be best to see what SMuFL does, as 
> they are experts on the issue.

Clarification: The Arabic accidentals, listed here as separate entities
  http://www.smufl.org/version/latest/range/arabicAccidentals/
appear in LilyPond as ordinary microtonal accidentals:
  
http://lilypond.org/doc/v2.18/Documentation/notation/the-feta-font#accidental-glyphs

So what I meant above is that originally, they were the same, i.e., when 
starting to use them in Arabic music, one took some Western microtonal 
accidentals. Now they mean microtones in the style of Arabic music, and the 
musical interpretation varies.

Re: Choosing the Set of Renderable Strings

[James Kass via Unicode]

In response to Richard Wordingham,

Sorry I can't answer many of your questions.  Hoping someone who can
does.  Note that although the proposal gave canonical combining class
zero to both the tone marks and the vowel signs, the on-line Unicode
data gives canonical combining class 230 to the tone marks.

> **The placement may be different to that of MAI KANG
> in /bɔː waː/ ᨷᩴ᩠᩵ᩅᩣ  SIGN AA> or ᨷᩴ᩠ᩅ᩵ᩣ  SIGN AA> - I don't know whether the first or the second
> tone mark is dropped.

FWIW, neither is dropped in the display here, although they don't
display identically.  The first string shows TONE-1 positioned to the
right of MAI KANG, the second string superimposes them.  (Windows 7
running LibreOffice in order to enable the USE from HarfBuzz.)

> (Getting the tone and MAI KANG to interact after  SIGN AA, MAI KANG> has formed the NAA ligature from
>  seems impossible.

Substituting U+1A36 TAI THAM LETTER NA for BA in the above strings,
ᨶᩴ᩠᩵ᩅᩣ  ᨶᩴ᩠ᩅ᩵ᩣ, and trying to get the ligature are in the attached
*.PNG file. Here's the four strings for the PNG:

\u1A36\u1A74\u1A75\u1A60\u1A45\u1A63
\u1A36\u1A74\u1A60\u1A45\u1A75\u1A63
\u1A36\u1A75\u1A63\u1A74
\u1A36\u1A63\u1A74\u1A75

Re: preliminary proposal: New Unicode characters for Arabic music half-flat and half-sharp symbols

[Johnny Farraj via Unicode]

Hi Garth,

You are right, I sent a similar posting to the list 3 years ago. at that
time I was hoping get help from some of the more experienced members on the
list to write a proposal. this is a very specialized job and it could take
me months to figure out the process and learn the language. But no one was
able to help. so I'm trying again.

My motivation is being able to type these symbols directly into a MS-Word
document or HTML page, just like you would type a Western flat or sharp
accidental symbol today. My motivation is NOT to make these symbols
available in sheet music notation software; there are solutions for that
today and it's a whole different problem domain.

About the existing symbols

U+1D132 MUSICAL SYMBOL QUARTER TONE SHARP
U+1D133 MUSICAL SYMBOL QUARTER TONE FLAT

I don't know what musical tradition these belong to, as far as I know no
one uses them in real life.

I need to make the case for new symbols called Arabic Half Flat / Sharp. I
don't see my proposal really as a duplication of existing symbols for the
following reason: there is no universal way to notate such accidentals, and
every musical tradition with concepts such as half-flat and half-sharp has
its own standard. I am not an expert in any tradition other than Arabic.
therefore all I'm trying to do is add the Arabic version of these symbols.

the Arabic symbols I'm proposing are established, and have been the
standard for a good 75 years. Any Arabic notation (except for a few
remnants from the 1930s before this standard in use) uses the symbols I'm
proposing to add. I do not foresee any disagreement over what the
half-sharp/half-flat Arabic symbols look like, and I can include tons of
evidence in my proposal.

Can someone on the list volunteer to guide with writing a proposal?

I'm willing to do all the work, I just don't know how to start. I need a
template, and I will be happy to complete it with all the required
information.

thanks

Johnny Farraj




On Wed, May 16, 2018 at 12:32 AM, Garth Wallace  wrote:

> What happened to the previous proposal? As I recall, there was some good
> discussion after an email from you back in 2015 <
> http://www.unicode.org/mail-arch/unicode-ml/y2015-m03/0118.html> and
> Michael Everson offered assistance, but no formal proposal has been
> submitted to the Documents Register since then.
>
> These symbols are also used in Turkish notation and Western microtonal
> notation. They are far more common than MUSICAL SYMBOL QUARTER TONE SHARP
> and MUSICAL SYMBOL QUARTER TONE FLAT, which AFAICT only appear in the
> Unicode code charts and nowhere else.
>
> On Tue, May 15, 2018 at 10:47 AM, Johnny Farraj via Unicode <
> unicode@unicode.org> wrote:
>
>>
>> Dear Unicode list members,
>>
>> I wish to get feedback about a new symbol submission proposal.
>>
>> Currently the Miscellaneous Symbols table (2600-26FF) includes the
>> following characters:
>>
>> 266D ♭ MUSIC FLAT SIGN
>> 266F ♯ MUSIC SHARP SIGN
>>
>> while the Musical Symbols table (1D100 - 1D1FF) includes the following
>> characters:
>>
>> 1D12A 𝄪 MUSICAL SYMBOL DOUBLE SHARP
>> 1D12B 𝄫 MUSICAL SYMBOL DOUBLE FLAT
>> 1D12C 𝄬 MUSICAL SYMBOL FLAT UP
>> 1D12D 𝄭 MUSICAL SYMBOL FLAT DOWN
>> 1D130 𝄰 MUSICAL SYMBOL SHARP UP
>> 1D131 𝄱 MUSICAL SYMBOL SHARP DOWN
>> 1D132 𝄲 MUSICAL SYMBOL QUARTER TONE SHARP
>> 1D133 𝄳 MUSICAL SYMBOL QUARTER TONE FLAT
>>
>> None of these matches what's used in Arabic music notation.
>>
>> I am proposing the addition of 2 new characters to the Musical Symbols
>> table:
>>
>> - the half-flat sign (lowers a note by a quarter tone)
>> - the half-sharp sign (raises a note by a quarter tone)
>>
>> [image: Inline image]
>> [image: Inline image]
>>
>>
>> These are the correct symbols for Arabic music notation, and they express
>> intervals that are multiples of quarter tones. it would be really nice to
>> be able to include them directly in an HTML page or rich text document
>> using a native code rather than an image.
>>
>> I am the primary sponsor of this proposal. As far as my credentials, I am
>> the owner of http://maqamworld.com, the most widely used online resource
>> on Arabic music theory, in English.
>>
>> My co-sponsor is Sami Abu Shumays, author of http://maqamlessons.com,
>> another important online reference for Arabic music theory.
>>
>> Together, we are in the process of publishing a book on Arabic music
>> theory and performance with Oxford University Press, coming out late 2018.
>>
>> I can also enlist the support of many academics in the music theory field
>> who specialize in Arabic music.
>>
>> I welcome any feedback on this proposal.
>>
>> thanks
>>
>> Johnny Farraj
>>
>>
>>
>>
>>
>


-- 

Johnny

Re: preliminary proposal: New Unicode characters for Arabic music half-flat and half-sharp symbols

[Hans Åberg via Unicode]

> On 16 May 2018, at 00:48, Ken Whistler via Unicode  
> wrote:
> 
> On 5/15/2018 2:46 PM, Markus Scherer via Unicode wrote:
>> I am proposing the addition of 2 new characters to the Musical Symbols table:
>> 
>> - the half-flat sign (lowers a note by a quarter tone) 
>> - the half-sharp sign (raises a note by a quarter tone)
>> 
>> In an actual proposal, I would expect a discussion of whether you are 
>> proposing to encode established symbols, or whether you are proposing new 
>> symbols to be adopted by the community (in which case Unicode would probably 
>> wait & see if they get established).
>> 
>> A proposal should also show evidence of usage and glyph variations.
> 
> And should probably refer to the relationship between these signs and the 
> existing:

It would be best to encode the SMuFL symbols, which is rather comprehensive and 
include those:
 https://www.smufl.org
 http://www.smufl.org/version/latest/

> U+1D132 MUSICAL SYMBOL QUARTER TONE SHARP
> U+1D133 MUSICAL SYMBOL QUARTER TONE FLAT
> 
> which are also half-sharp or half-flat accidentals.
> 
> The wiki on flat signs shows this flat with a crossbar, as well as a reversed 
> flat symbol, to represent the half-flat.
> 
> And the wiki on sharp signs shows this sharp minus one vertical bar to 
> represent the half-sharp.
> 
> So there may be some use of these signs in microtonal notation, outside of an 
> Arabic context, as well. See:
> 
> https://en.wikipedia.org/wiki/Accidental_(music)#Microtonal_notation

These are otherwise originally the same, but has since drifted. So whether to 
unify them or having them separate might be best to see what SMuFL does, as 
they are experts on the issue.