Loading an existing score (created with 1.1), which has chords placed on 1st and 3rd beat
All chords are shown over the 1st beat, and trying to move them shows them to belong to that 1dst beat (the dotted line while draging point to the 1st beat)
I also noticed, but didn't report, that the chord names were overlapping at the beginning of the bar. On a multi-page score with chords on the second page, this puts both chords on the first beat, and if you move them they appear linked to the first page. Sounds the same to me.
I'm pretty sure your bug (chord position not saved) is different, though. You were talking about chords that were on beat one the whole time, but you had dragged to look like they were on beat three even though they were still attached to beat one I'm pretty sure the bug being discussed currently involves chords that are actually attached to beat three.
BTW, my recollection is that this was a known issue when lasconic added support to 1.1 for chord symbols not attached to specific notes - ie, the behavior where space bar would stop on every beat, not just on every note. It was kind of an accident, I think, that the 1.1 architecture allowed chords not attached to notes, but the trunk doesn't currently allow chords not attached to notes. So the "space bar stops at each" facility was added to 1.1 with full knowledge that the particular implementation used wouldn't work in the trunk until that bit of architecture was revisited.
Marc, since no score was provided, I can only assume that all chords were added to actual notes, not only to beat 1 or empty beats. One of my 1.1 scores has chords that were added to existing notes on other that beat 1, and they all collapse to beat 1 under 2.0.
That could be, but if so, I would still be willing to bet that it was *recorded in the MSCZ file* as having being attached to the beat position, as a result of that change to the space bar logic. It seems that would have been the simpler implementation.
And as far as I am concerned, attaching chords to beat positions rather than to notes is *right* solution anyhow. A chord symbols is not like an lyric syllable mark that applies to one specific note only. It is more like, hmm, a hairpin that applies to a *ranges of time positions*: In this case, "every time position between here and the next chord symbol". It applies equally whether there are notes in that region or not.
I guess in that sense a chord symbol is more like a tempo marking, which I would argue should probably be treated similarly. And I suspect it is - in 1.1 at least, I can attach a tempo marking to a note in one staff of a score and find it present in all extracted parts even if those parts don't have notes at that position. So in those extracted parts at least, the tempo marking is being stored as being attached to the time position, not to any particular note. And that's as it should be.
So I think 2.0 just needs to be extended to support chords attached to beat positions directly, that that should remain the way chords are actually stored.
I was just trying to see if an XML export/import would be a solution for now, but the trunk is far too unstable right now and crashes when reading the XML produced from 1.1. I did find that using XML does solve some import issues from v1 into v2, but those should get fixed when v2 heads into the home stretch.
Comments
Sounds related to #12435: [Trunk] R4754 Chord letter issues
Related maybe, but not identical
I also noticed, but didn't report, that the chord names were overlapping at the beginning of the bar. On a multi-page score with chords on the second page, this puts both chords on the first beat, and if you move them they appear linked to the first page. Sounds the same to me.
This description indeed sounds the same. But as you didn't report it ... ;-)
posted it at 28. July 2011
chord position not saved
I'm pretty sure your bug (chord position not saved) is different, though. You were talking about chords that were on beat one the whole time, but you had dragged to look like they were on beat three even though they were still attached to beat one I'm pretty sure the bug being discussed currently involves chords that are actually attached to beat three.
BTW, my recollection is that this was a known issue when lasconic added support to 1.1 for chord symbols not attached to specific notes - ie, the behavior where space bar would stop on every beat, not just on every note. It was kind of an accident, I think, that the 1.1 architecture allowed chords not attached to notes, but the trunk doesn't currently allow chords not attached to notes. So the "space bar stops at each" facility was added to 1.1 with full knowledge that the particular implementation used wouldn't work in the trunk until that bit of architecture was revisited.
Marc, since no score was provided, I can only assume that all chords were added to actual notes, not only to beat 1 or empty beats. One of my 1.1 scores has chords that were added to existing notes on other that beat 1, and they all collapse to beat 1 under 2.0.
That could be, but if so, I would still be willing to bet that it was *recorded in the MSCZ file* as having being attached to the beat position, as a result of that change to the space bar logic. It seems that would have been the simpler implementation.
And as far as I am concerned, attaching chords to beat positions rather than to notes is *right* solution anyhow. A chord symbols is not like an lyric syllable mark that applies to one specific note only. It is more like, hmm, a hairpin that applies to a *ranges of time positions*: In this case, "every time position between here and the next chord symbol". It applies equally whether there are notes in that region or not.
I guess in that sense a chord symbol is more like a tempo marking, which I would argue should probably be treated similarly. And I suspect it is - in 1.1 at least, I can attach a tempo marking to a note in one staff of a score and find it present in all extracted parts even if those parts don't have notes at that position. So in those extracted parts at least, the tempo marking is being stored as being attached to the time position, not to any particular note. And that's as it should be.
So I think 2.0 just needs to be extended to support chords attached to beat positions directly, that that should remain the way chords are actually stored.
I was just trying to see if an XML export/import would be a solution for now, but the trunk is far too unstable right now and crashes when reading the XML produced from 1.1. I did find that using XML does solve some import issues from v1 into v2, but those should get fixed when v2 heads into the home stretch.
R5327: I opened a 1.1 score and the chord symbols appeared in the right spot now. So I guess this is fixed. Can someone else please try.
Maybe you want to try issue #12435:[Trunk] R4754 Chord letter issues as well to see whether it works now.
Automatically closed -- issue fixed for 2 weeks with no activity.
I just tried again wit R5436, and the chords are loosing their position again when a score from 1.1/1.2 is opened.
NOT FOUND: 01
Score enclosed.
#15: this is a different bug, fixed in r5443.
Please create a new bug report for new bugs!
Automatically closed -- issue fixed for 2 weeks with no activity.