[smufl-discuss] Re: Some ideas

[T.J. Usiyan]

I do want to emphasize the point that there really are not that many
components to chord symbols. There are a stupid amount of ways to
represent those components but there are not that many actual pieces.
I have spent quite a bit of time working on interpreting text
representations of chord symbols and these are the pieces I currently
use. Augmented, Half Diminished, Major, Minor, Diminished, Dominant,
Suspended, Flat, Sharp, Add, Omit, 0-9. Again, I have many variations
on those pieces but that really seems tractable. Even imagining that I
missed half of the pieces that brings us to 24 groups. My argument is
that we can provide a _means_ to represent those groups to aid
drawing. There is no way that we can encode all valid combinations of
these pieces but–in providing a means to represent the pieces–we can
provide a way to work in those _pieces_ and not the glyphs comprising
them. laying out "Dom" as one block next to "7♭9" over a bar over "5"
is slightly nicer than laying out each individual component I would
think.

I will let it go now as it seems that most of us seem against it. I
just wanted to get that out before we table it.

TJ

On Fri, May 31, 2013 at 2:07 PM, Joseph Berkovitz <[hidden email]> wrote:

> On May 31, 2013, at 12:58 PM, "David Webber" <[hidden email]> wrote:
>
>> From: Joseph Berkovitz
>>
>>> In this case my opinion agrees with Daniel's: the encoding of chord symbols should be out of scope for SMuFL.
>
> Sorry, there's a misunderstanding… I only meant that SMuFL should not attempt to encode partially or fully realized chord symbols made of multiple glyphs (which I think was the essence of Daniel's objection). I do not have a problem with code points for a small number of individual glyphs that are helpful in creating chord symbols, and in fact these will be quite helpful.
>
>> I'm not sure what the problem is.  The necessary characters are limited essentially to
>>
>> alphabetic
>> numeric
>> parentheses
>> accidentals
>> plus
>> minus
>> and a few special symbols:
>> circle in the air for diminished
>> circle with a stroke for half diminished
>> capital-delta-like triangle
>>
>> If you're happy to demand that applications just decide where to draw these relative to one another, and how to size them, that's all the font needs.
>
> In fact I am asking for exactly that, and so I think that we're perhaps in agreement.  Any reasonable text font (SMuFL aside) will already provide these:
>> alphabetic
>> numeric
>> parentheses
>> plus
>> minus
>
> And SMuFL "text-oriented code points" can provide these:
>> accidentals (these were already discussed on the list)
>> circle in the air for diminished
>> circle with a stroke for half diminished
>> capital-delta-like triangle
> and a few other chord-symbol specialties that are fairly easy to agree on.
>
> What I am eager to avoid is attempts to build geometric relationships between chord symbol glyphs into the standard via ligatures or other font skulduggery. Those relationships are hard to codify.
>
> .            .       .    .  . ...Joe
>
> Joe Berkovitz
> President
>
> Noteflight LLC
> Boston, Mass.
> phone: [phone]
> www.noteflight.com
> "Your music, everywhere"
>
>
> #############################################################
> This message is sent to you because you are subscribed to
>   the mailing list <[hidden email]>.
> To unsubscribe, E-mail to: <[hidden email]>
> To switch to the DIGEST mode, E-mail to <[hidden email]>
> To switch to the INDEX mode, E-mail to <[hidden email]>
> Send administrative queries to  <[hidden email]>
>

#############################################################
This message is sent to you because you are subscribed to
  the mailing list <[hidden email]>.
To unsubscribe, E-mail to: <[hidden email]>
To switch to the DIGEST mode, E-mail to <[hidden email]>
To switch to the INDEX mode, E-mail to <[hidden email]>
Send administrative queries to  <[hidden email]>