First, I pushed two more small changes to my fork on GitHub this morning:

- hack to allow a trailing space (entered via ctrl-space) in a chord 
symbol to bypass chord parsing, for the benefit of anyone who really 
would rather have an unrecognized chord than let MuseScore convert it to 
the form specified in the chord description file

- improvement to my fix for the issue with the text value displayed when 
going back and editing a chord: now it populates with the *first* name 
field in the chord description file, rather than the *last* name field 
(it still takes this over the value in chords.xml, which was the problem 
before)

I now consider all of this ready to issue a pull request for, and if I 
don't hear otherwise, I'll do so tomorrow.

I have been looking ahead at what would be involved in going further.  
Based on things we've discussed in the past, there are three areas for 
improvement I see:

1) handling of chords that are parseable but not recognized (ie, that 
don't match a predefined chord id)
2) giving user more direct control over rendering of chord symbols
3) firming up the parsed format and incorporating it into chords.xml 
and/or the chord description files, eliminating the need to parse name 
fields for the predefined chord id's

I see #3 as being a byproduct of work on #1 and #2, and thus not 
something I'd tackle first.

It actually appears that #1 isn't all that difficult.  Getting parseable 
but unrecognized chords to transpose is trivial; we didn't need a parser 
for that as the root and bass tpc's were already being calculated (and 
then thrown away!) for anything even remotely resembling a valid chord 
symbol.  Getting these chords to output to MusicXML shouldn't be too 
bad, either - I can generate reasonable kind & degree tags from the 
parsed form of any valid chord symbol I can think of, recognized or 
not.  Getting these chords to render at least somewhat reasonably is not 
too hard, either - I can generate a rudimentary render list from the 
parsed form pretty easily, too.  And I assume it would be 
straightforward to adapt that code to handle the rendering of valid but 
unrecognized chords constructed in the Harmony Properties dialog 
(although I have no idea where to find the code that deals with that 
dialog!)

#2 is definitely more challenging.  To do it right would require a 
complex new GUI element, and since this facility would potentially 
affect all chords - recognized and unrecognized - it would have to be 
fairly complete, powerful, and robust.  Otherwise, the user might be 
better served by our simply supplying a few more hand-tweaked chord 
description files.  Whereas even a half-baked job of #1, or of the 
parser itself that I already implemented, beats doing nothing.  Also, as 
I have mentioned before, #2 is something I think I could pull off about 
as well using a separate utility (perhaps delivered as a plugin) that 
simply generates chord description files for use with MuseScore as is, 
and thus could be implemented without disrupting the MuseScore schedule 
/ roadmap.

So even though my sense is that #2 is arguably the most important piece 
here as far as the end user is concerned, I kind of think it makes sense 
to tackle #1 first - at least, for me.  If someone else feels up to #2, 
great, and I'm happy to help as I can.

There is enough involved to #1 that I can't see myself getting it all 
done as quickly as I did the parser itself, but by the end of the month 
or early June seems quite feasible.  But I'm quite aware we want to get 
2.0 out sooner rather than later and that none of what I'm proposing is 
worth holding anything up for.

Marc


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
_______________________________________________
Mscore-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Reply via email to