On Jun 5, 2013, at 3:03 AM, [email protected] (Tony Mountifield) wrote: > existing scores only identify a valid chord using root, "base" > (should really be bass) and extension (chord ID), with no text indicating the > type > of chord. With your proposed lack of a chord ID list, how would the chords in > such > scores get recognised correctly on loading?
My plan is to change the default for *new* scores to not load chords.xml by default, but existing 1.X scores would continue to load it. I'd probably do this by having a style option to control the loading of chords.xml, and while the default for new scores would be set to "no", 1.X scores would default to "yes". The first time you save an old score in 2.0, the names will be written to the score, so you'd be free to turn off that option at any time to convert to WYTIWYG mode. There would probably be a bit more to it than that, to handle other special cases, but that would be the gist of it. As for the "mi" and "ma" glyphs in MuseJazz, this is handled by a set of token-rendering rules within the chord description file. I will provide two new chord description files - a generic one to replace stdchords.xml as the default, and a MuseJazz-specific one to replace the various "cchords" files for use in the "Jazz" templates and other scores that choose to use MuseJazz chords. The new MuseJazz-specific chord description file knows about the "ma" and "mi" glyphs and substitutes them automatically. The way unrecognized chords are rendered is the part of what I have done that I am most excited about. The token-rendering rules provide a ton of flexibility and will be very easy to customize, and they can produce great-looking results. For anyone interested in details, here's how it works (anyone else can stop reading here!) === The parser breaks each chord into a series of tokens - turning Cma7#11 into C, ma, 7, #, 11. Each token is then rendered individually, by consulting the rules in the chord description file. If there is no rule defined for a token, then it is rendered as plain text. But if there is a rule defined, then the token is output accordingly, using the exact same <render> syntax (and code to handle it) as currently used for chord id's. This allows for glyph substitution, superscripting, and more, on a token-by-token basis. So, <sym code="0xe180” name=ma-glyph> <token> <name>ma</name> <render>m:0:-3 ma-glyph m:0:3</render> </token> will cause the token "ma" to render using the glyph at 0xe180, superscripted 3 units, no matter what chord it appears within. Better still, the "token" definition can take an optional "class" attribute - as in, <token class="modifier"> ... This allows you to have different rendering rules for a token depending on its function within the chord. Thus, the "ma" in Cma7#11 can (and does) render differently from the "ma" in Cmi(ma7). The first (class=”quality") currently renders at the baseline; the second (class="modifier") renders superscripted. Similarly with the 7's in that example, or the 9's in C9 (class="extension") versus C7b9 (class="modifier"). Numbers that have "modifier" function will render superscripted and a bit smaller than numbers that have "extension" function. All controlled by a set of token-rendering rules in the chord description file. If you take another look at the image at the end of the post I linked to in my previous message, you'll see this in action. That is not a mockup - this is exactly what is produced by the set of token-rendering rules I created for the new MuseJazz-specific chord description file, with no chord id list whatsoever. The fact that no chord id is needed means that the same rendering would apply to anything you type that is at all parseable. Want Cmaj7#11b9sus(no5)? You got it, and it will render consistently with your other chords. And once my pending pull request goes through, it will also export to MusicXML correctly. I think with this in place as the default, very few people would ever see the need to customize anything further. Marc ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j _______________________________________________ Mscore-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mscore-developer
