Godley
commented
9 years ago Do the system design diagrams give a good overall picture of the system, and are there any holes/is that a suitable replacement for the generated ones Ping couldn’t understand fully?
Figures 2 and 3:- fig 2 is hard to read and fig 3 has limited contrast so it might be better to leave 2 in the appendix and add labels to 3. The light theme is much better.
" ... meticulous attention must be paid ..." I'm finding some other things like this that proof-reading will need to sweep up. Also, I'm assuming things like 'lilypondtestcase' in parentheses are citations to be resolved in due course? If you start a paragraph with 'This' it is indicative it should be joined to the previous. Similarly 'It' at the start of a paragraph leaves the reader wondering what. Reference to 'duck typing' similarly - paragraphs should delineate related concepts and are useful signposting elements.
Line breaks in the class descriptions made fig 8 much harder to read than fig 7. The explanatory labels in 7 also helped a lot, though you might not have room for these in the much more complex fig 8. I don't feel qualified to pick out design holes per se, though fig 8 did seem to be chopped off at the bottom and somehow its name has been included - tree.png.
section 1.4.2, challenges to the renderer: does that sum up the reasons for late re design, and does it avoid sounding as if the late changes were a result of bad planning/research?
Very long sentence starting 1.4.1 - almost looks like still in note form. Didn't you use accepted standards/tools for issue tracking, by the way? 1.4.2 seems an honest and pragmatic appraisal of the situation. I would just phrase the last sentence slightly differently "...to fully design the structure from the outset .." because you did design in the initial stages, just not in every last detail.
P9 -can't 'collaborate results' - choose another verb - pool?
section 1.4.3, external libraries, GUI libraries: is the wording for the WX portion ok?
Didn't follow the sentence beginning 'Pythn as a language...'. 'being as' is clunky - 'since'? Wrap up several sentences into a paragraph if they are linked - reads in a fragmented way. Unclear why reason for dismissing Wx (or WX - be consistent) is 'recommendation from other developers' when you've just done a whole host of other reasons to go with Qt. Would be stronger if you referred back to your findings on Qt and reason from there.
section 1.4.3, external libraries, databases: MongoDB - is lack of research a valid reason/do I need to padd that out a bit? Sort of similar reasoning to the UI portion in that I’d got comfortable with SQLite and didn’t see a reason to change to a lesser known technology.
Not clear why only these three got into your final cut. MongoDB is not second in the table. I have to agree this section looks much less objectively argued than the one on UIs. 'It's' is wrong when you need the possessive pronoun - 'its' . Check for other instances too e.g. 2.1.
section 2.1 Project achievements: would it be more suitable to do a table of my primary objectives with a tick and comment on any thing I want highlighting? I haven’t filled in search processing as yet because I’m not sure how well going through each objective and writing “it works and it does this this and this” is a good format.
I don't think you could do justice to this in a table as well as it is possible to do in narrative form as you have at present, so certainly don't substitute a table for what you have now. A table in addition might help but I think in fact it would be better in the opening text of 2.1 to summarise the objectives and why you set them.
section 2.2.1 improved rendering capabilities: does this sum up the reasons for stopping working on this, and is this the most appropriate place for this to be put?
Seems fine to put this here and it is accepted that you can't do everything in one third-year project. Given that you mention what it can't do in terms of instruments (guitar, drum) then it would be good to state what instruments are supported. At present this is done in abstract as what features are present - back this up with some use cases for the non-music reading reader.
One final point - 'future developments' looks odd when we've just done 'further work' - not clear why these are separated in this way.
section 3.4: diagrams need to be moved to system design, have a general text which explains the links between the sub sections 3.5 also needs an intro