search

Godley / MuseParse

Repository for a python music parser. This works with MusicXML as the input format which forms a tree of objects in memory representing the piece. This can be optionally outputted to lilypond which produces a PDF, or perused for your own uses.
MIT License
7 stars 2 forks source link

arpeggiate testcase (the one we made) breaks because of a problem handling non-arpeggiates #20

Open Godley opened 9 years ago

Godley commented 9 years ago

Issue by Godley Friday Mar 06, 2015 at 12:37 GMT Originally opened as https://github.com/Godley/FYP/issues/157

Non arpeggiates have types "top" and "bottom". Where the first non arpeggiate appears it has both of these attribs attached to one note, but when we do the update it changes one of them to start and the other to top. various stuff to do to fix this, it's not a huge issue because it's unlikely a singular note will have a non-arpeggiate bracket so I'm labelling it as an enhancement.

Godley commented 9 years ago

Comment by Godley Friday Mar 06, 2015 at 12:40 GMT

in fact, I'm not even sure this is a problem: the failure is mostly in terms of the fact the test doesn't pass the basic comparison in the handler test. It still generates valid output, tho each note is missing an "\arpeggio" after the note...

Godley commented 9 years ago

Comment by Godley Friday Mar 06, 2015 at 12:42 GMT

a problem with this tho might be that the arpeggio bracket is intended to stop lilypond from making that part of a chord an arpeggiate, but at minute if we encounter an arpeggio bracket (a non-arpeggiate) then we go right to the bottom of the chord and place an endpoint there, whereas that info might already be loaded in. either way still not a huge problem, just need to look over the arpeggiate testcase