Re: Getting Off The Ground

It's probably best understood as a loose coupling. Without SMuFL, you can have semantically-correct markup but no idea about the "original" notehead, for example. By embedding the SMuFL codepoint in the XML it serves to clarify the intended symbol. This helps interoperability between notation systems so that one MusicXML file can be rendered using the same symbols in two different notation editors.

We're also working on SMuFL support in the upcoming release of MEI, so it's not directly tied to MusicXML. I think the idea of combining SMuFL and MusicXML was more to coalesce a group of people working on music notation applications, rather than a strict dependency between the two projects.

-Andrew

> On Sep 30, 2015, at 10:59 PM, Knut Nergaard <knut.nergaard@gmail.com> wrote:
> 
> Den 30. sep. 2015 kl. 16:29 skrev "James Sutton" <jrs@jmsutton.co.uk <mailto:jrs@jmsutton.co.uk>>:
> 
>> 3. SMuFL
>>    I'm not clear why the MusicXML standard needs to be coupled to a font mapping standard. Wouldn't it be simpler for each standard to stand alone?
> 
> From a font developer standpoint, I second this, and in light of the differing fields of knowledge and issues constituting the MusicXML and SMuFL communities, I would think it would be appropriate with different sub-groups/mailing lists.
> 
> I for one have questions and suggestions related specifically to SMuFL, most of which I think would be of no immediate interest to the MusicXML community. 
> 
> Knut Nergaard