In article <[email protected]>, Marc Sabatella <[email protected]> wrote: > My first impressions are, this looks fantastic!
Great, glad you like it! I'm hoping that Werner will approve the changes and merge them even at their current level, as I believe they are already a big improvement, and we can then add further changes to address your points below and others that crop up. > Just a few observations: > > > a) A chord symbol never crosses the barline at the end of a measure. > > Is this a conscious choice, or something that's hard to work around? I > found I wasn't thrilled with this. It's mainly to do with the fact that each measure is calculated and stretched individually. So it's not at all easy to look ahead, only behind, and that within the same measure. It looked messier to me if long chord symbols at the end of a measure just overflowed to the next measure by default. > Maybe if there was a separate style > parameter to set the minimum-space-to-barline differently from minimum > space to next chord. The style parameter you've already added appears > to work as advertised, including use of negative values to effectively > disable this whole mechanism. Yes, I think another style parameter to set the spacing to the following barline would be a good and straightforward addition. I'll have a look at adding it. Again, it could be set to a large negative value to disable. > > c) If chords are dragged vertically to be clear of each other, they > > are allowed to overlap horizontally. > > This seems a bit glitchy. I have to move a chord way above the others > in order to get the space to close up. Although maybe that's a question > of font metrics - just because the chord appears to clear the others > doesn't mean their bounding boxes do. Not a big deal, though. Yes, I noticed that too. Perhaps yet another style parameter to set the amount of vertical overlap to accept without horizontal spacing kicking in. It might even be useful to make the default non-zero, e.g. 0.2sp. > > e) When a chord symbol is clicked on to edit, it jumps down > > vertically, and then returns to the correct position > > This has been the case for a while now, yes? So not related to your > changes, I assume. That's correct. It irks me rather, but I thought it better to leave it to be solved separately, rather than delay everything else. > One thing I do see is that the spacing appears only partially > implemented until you leave chord edito mode completely. That is, when > you first add a chord and hit the space bar, it just adds space to the > next note. Only when you hit Esc does the measure respace itself > completely. Not a problem necessarily; I just wanted to be sure this is > intentional / known. I'll have a look at this in more detail. It's probably to do with mode switching (or not, when using space) and layout flags. > Also, for whatever reason, major sevenths don't seem to be recognized > using stdchords.xml using any abbreviation I could think of. The date > on my copy is 3/28/13 and appears to have your space-around-accidentals > fixes. My chords.xml is from 9/8/12. It sure looks from it like Maj7 > should work, but it doesn't for me. I can get a major seventh chord in > cchords_muse just fine. I can also get it in stdchords by entering a > dominant seventh then changing it in Harmony Properties. Weird! I'll try it out and do some stepping through the code. > Anyhow, this will be great to have! Cheers, Tony -- Tony Mountifield Work: [email protected] - http://www.softins.co.uk Play: [email protected] - http://tony.mountifield.org ------------------------------------------------------------------------------ Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html _______________________________________________ Mscore-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mscore-developer
