[smufl-discuss] Re: Some ideas

[T.J. Usiyan]

Hello Joe,

While I agree that the issue is too large to completely embody in font
I think that providing a means to supply and describe chord symbol
components allows both application and font developers with the most
flexibility. If we attempt nothing in this area we provide the font
creator no guidance at all which I think is a mistake. Establishing a
metadata key and range of available points  still allows application
developers to ignore that information if present while also allowing
the font to provide 'pretty' forms of symbols.

TJ

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

> Thanks, Daniel and TJ.
>
> In this case my opinion agrees with Daniel's: the encoding of chord symbols should be out of scope for SMuFL.
>
> There is a near-inexhaustible set of ways to combine elements to make what someone, somewhere considers a valid chord symbol. There are also many ways to format such combinations, which inspire some very long (and often unresolvable) debates on the correct way to do so. Chord symbols have never been standardized to the same degree as conventional Western notation.
>
> Such complex decisions and policies are best left to the application developer, rather than attempting to embody them in a font. SMuFL should allow applications to decide how much flexibility they offer in this area.
>
> All in all, creating complex chord symbols is quite like creating a bunch of notes with stems, accidentals, flags, beams, etc.: one must position and scale a bunch of individual pieces in the desired visual relationship. I don't think there's any easy font-based way of dodging this bullet. Note that even "typical existing scoring applications" only use fonts to encode certain reusable fragments of chord symbols, which must then undergo substantial formatting to be placed in an instance of some symbol. And some other applications, like Noteflight, take a different approach of combining individual letter forms from regular text fonts along with individual notation glyphs from music fonts.
>
> …Joe
>
> On May 31, 2013, at 11:45 AM, "Daniel Spreadbury" <[hidden email]> wrote:
>
>> Thanks for this suggestion, TJ.
>>
>> My initial reaction to this proposal is that it will be hard to come up
>> with a relatively small number of components that could be combined
>> flexibly enough to produce a similarly flexible representation of chord
>> symbols.
>>
>> Typically existing scoring applications have entire fonts with upwards of
>> 200 glyphs (Opus Chords, for example, has 212; Jazz Chords has 227).
>> Catering for all of the different ways the basic chord qualities can be
>> rendered (M, m, ma, maj, etc. just for "major") and being able to create
>> stacks of up to three digits, with accidentals, and parentheses, plus
>> optional bass notes (ideally with the means to show the chord symbol like
>> a fraction, with the main chord offset up and left, and the bass note
>> offset down and right, with a fraction slash inbetween) seems like it
>> might be outside the scope of SMuFL.
>
>
> #############################################################
> 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]>