#636 bad rendering of close-interval chords

closed
Chris Cannam
notation (282)
9
2012-09-16
2004-10-16
No

I did not check to see if this is a duplicate, and I have no idea what
intervals and stuff these are. I am on my way out the door, and
don't have time to look at this closely at all. It's too ugly to risk
letting it slip by. See the picture. Sorry if it's a duplicate.

Discussion

1 2 > >> (Page 1 of 2)
  •  
    Attachments
  • William
    William
    2004-10-17

    Logged In: YES
    user_id=1004577

    I cannot reproduce the problem. It works fine for me using
    latest CVS. I would upload a screenshot here but since
    Sourceforge doesn't allow anyone except the author of a bug
    report to upload attachments, I have attached my screenshot
    to my related BR# 957364 "Notation: Hard to select upper
    note in chords of seconds"
    https://sourceforge.net/tracker/?func=detail&atid=104932&aid=957364&group_id=4932

    By the way, the intervals in your chord are called
    "seconds", "thirds" and "fourths".

     
  • Chris Cannam
    Chris Cannam
    2004-10-17

    Logged In: YES
    user_id=13489

    I think RG's got confused somewhere with these. Maybe
    the wrongly-positioned chords have wrongly acquired an
    internal property marking them as having the wrong stem
    direction or something. What happens if you select all
    and then stem-down / stem-up to force the stems? Or
    restore default stems?

     
  • Logged In: YES
    user_id=663564

    What happens if you select all
    and then stem-down / stem-up to force the stems? Or
    restore default stems?

    Stem up/down waves a magic wand at it and cleans it right up.

    Restore computed stems screws it right back up.

    OK, I looked at the three first notes and all three (after restoring
    computed stems and knocking the heads back out of whack) seem to have
    a stem up. That's puzzling.

    Anyway, this is CVS up to date and make cleaned and even make installed
    as of the middle of yesterday somewhen. This issue crops up a lot in this
    particular imported MIDI file, but I can't include this file with this SF bug
    due to copyright issues.

     
  • William
    William
    2004-10-17

    Logged In: YES
    user_id=1004577

    I understand the whole file cannot be attached for copyright
    reasons, but it would be perfectly acceptable to attach just
    an extract of the file, i.e. the bar containing those
    repeated chords. I wonder whether you might be seeing the
    same beaming-related bug that I've seen occasionally but
    been unable to reproduce. Can you post the extract here?

     
  • Logged In: YES
    user_id=663564
    Originator: YES

    This is listed on Chris's todo for 1.7. I don't remember seeing a fix for this come across, but I just tried to recreate the sample picture, and it seems fine now. I played around with jamming C D E F G A B C together in a chord, all up and down the staff, and I can't find anything wrong now.

    Given that the comment thread talks about problems with stem direction weirdness, I bet if this wasn't intentionally fixed, it might be related to that recent bit of work that corrected another stem issue I encountered.

    Hard to say, since I didn't provide the MIDI file. It may be there is still something here, but it seems unlikely. I can't figure out a way to recreate the original behavior.

     
  • Chris Cannam
    Chris Cannam
    2008-02-23

    Logged In: YES
    user_id=13489
    Originator: NO

    Woah, interesting. I certainly didn't knowingly fix this one.

    Although you're probably right in principle to set it fixed/pending, I'm switching it back to unresolved at a high priority to remind me to look over it again. I am very keen to make sure this is thoroughly fixed for 1.7.

     
  • Logged In: YES
    user_id=663564
    Originator: YES

    I wasn't expecting it to be fixed when I looked. I was just revisiting this to see exactly what it was about, and I started with the original scenario depicted in the attached screen clip.

    Since you want to be really thorough, I just hit it with a bigger hammer. I notice a few noteworthy things.

    1) When entering chords (full of close intervals or not) the stem direction of the first note affects the entire cord. If I enter a two octave C major chord from the bottom C up, the stems go up, else if I enter from the top down, the stems go down. Not sure if this is a bug or a feature. It does export with the same stem direction, and maybe it's even a feature.)

    2) If I enter insanely tall stacks of insanely close notes (every letter note for three octaves) everything is fine for plain notes, and everything is fine for every random mixture of sharps, flats, and naturals I threw in. Rendering of the accidentals could be better, because if you have a gigantic stack of sharped and flatted and naturaled notes this close together, the accidentals piling up off to the left don't space themselves out the same way they do when I export the result to LilyPond. (I think this is kind of one of those things I'd just write off as "LilyPond will fix it, so carry on," like bad slur rendering and myriad other niggling things that all add up to why we encourage people to print via LilyPond in the first place.)

    3) Most importantly of these notables, I can still find a real rendering problem when I introduce double accidentals to the fray. A chord with just Bx and Cb always renders with both notes to the left of the stem, and similar things are possible with other mixtures. This looks like some kind of holdover from the "there is no such thing as B#" days to me. Some height on staff vs. MIDI pitch confusion or something, and I can only get it to happen with double accidentals in combination with non-doubled accidentals or naturals.

    Hammer away, but I'm satisfied enough for at least a "works for me" on this. The original scenario definitely works now. Maybe it's possible to find something that would import incorrectly. Let's try recreating the original scenario as MIDI then.

    Wild. I put the key to G major to sharp the Fs, then put in the three notes from the sample, D, F natural, G, pasted that to fill a measure, exported it to MIDI, and when I imported it back, it came out in 12/8 for some puzzling reason, in G minor instead of G major, and a weird clef. An alto clef. But when I corrected the clef and key, no rendering problem of the chords (before or after.)

    So finally I played the chord on my keyboard, and it was fine, and this that and the other were fine until I recorded wild keyboard banging chords, then put the result into Cb, then changed Cb to E. I wound up with a pretty hideous mess in bang.png

    File Added: banger.png

     
  •  
    Attachments
  • Logged In: YES
    user_id=663564
    Originator: YES

    I'm obstinately lowering the priority on this one again. It doesn't break unless you just get completely insane with it, and you've had three years and change to look at it without doing so. I want to discourage you from holding up a release over this one.

     
1 2 > >> (Page 1 of 2)