All entries for October 2007
October 30, 2007
Introduction of the Weekly Schedule
My university course timetable has been uploaded to this blog. Highlighted throughout the week are the times where I will be on campus and available to work on the project. The schedule may always be found at the url:
Weekly Project Reports
From now on, the Week # Schedule section of each weekly project report will link to the general schedule and will add more information only if there is some expected deviation from it, for that particular week.
29/10/2007 - Term 1, Week 5 (Start of)
Following is the work done over the last week:
- A decision has been made regarding the proposed change to the specification. It was decided that the aim and scope of the project would remain unchanged.
- Some research has been done (and concluded) concerning the data storage requirements of the system. It has been decided that MusicXML will be a used throughout the system. It has yet to be decided exactly how the system will use this to display the score to the user at the browser.
Significantly fewer goals have been acheived than expected. It had been the intention that, by the end of this week, all research and requirement-elicitation type tasks would have been completed. However, I remain in the throes of data structure and development tool research.
Given that the essential requirements of the system are now well established in my mind, the formality of producing a list of requirements is not hindering the design of the system. However it would still be useful to have this documentation.
Current Project State
As anticipated in last weeks report, the Analysis phase is going to have to continue through the next week, despite the original intention to have begun design work by now. The project timetable will be updated.
All outstanding Analysis-style tasks need to be completed by the end of this week.
Week 5 Tasks
- Finalise choice developments tools
- Finalise choice of data storage systems
- Consider graphics requirements
- Continue the development of prototypes of futher sophistication
- Produce a set list of requirements
Week 5 Schedule
My general weekly schedule may be found here.
October 25, 2007
In short, I was considering expanding the Aim of the system. Instead of only being a score editor/creator, the system would aim to be an entire web-community where users have profiles (and can view each other's profiles). Each user would be able to upload (or create with the editor) their scores and view, comment on and perhaps edit (or suggest modifications to) each other's scores. The proposal in more detail, along with advantages and disadvantages of adopting it may be found in this document:
I have decided not to adopt the change of aim, for the simple reason that it would not lead anything that would be a better choice of project for the module itself. As advised by my supervisor, it would involve a lot of extra programming and usability issues, without adding much more of a challenge. It would be significantly more work, but not worth a great deal more in terms of assessment.
It is, however, worth considering as the eventual aim of the project, at the very least suggesting that the finished system could be further expanded to become a full web-community based around musical scores.
It may also be worth considering allowing users to edit each other's scores in the system anyway. It will be useful and will lead to some interesting situations of version control and permissions on the scores at the very least.
October 24, 2007
It seems that there will be several main areas to consider when it comes to the storage of data in this system:
- How to store personal user information and musical scores on the server.
- What format should the scores be in to transfer them from the server to the client browser.
- What should the structure of the actual client webpage be - in what structure will the scores be kept (and modified) at the user-end?
On the Server
SQL Database: Store all the personal info required for user-accounts in an SQL Database on the server. The music scores themselves could also be stored in the database however, it would probably make far more sense to store each score in it's own file on the server and perhaps give the location of it within the database for each user. This begs the question: What file format should be used to store the scores (see below)?
Music Score file format
Aside from designing my own file format for musical scores, there are many already established formats out there (e.g. GUIDO, NIFF, MIDI, MusicXML, LilyPond) which could be used. The most widely used format at the moment is MusicXML, which is now supported by all the leading commercial applications. In terms of simplicity and sufficiency (for storing scores) At the moment, the best choice is MusicXML for the following reasons:
- It is XML; As genuine XML it is well supported (by servers and browsers) and opens up opportunities to use XSLTs for the convertion to other formats (most significantly html). It is also human-readable.
- Well-supported: If the system supports MusicXML it will be useful to users who will be able to download their scores in this format and load them into many other applications.
- It is specifically designed for notation (unlike many of the other options) and includes everything the system will need to store and nothing extra (for example MIDI is designed for audio rather than notation).
In the browser
When it comes to handling the score in the browser, a few options seem possible:
- Generating an html structure that corresponds to the score (i.e. each note is a html 'div' having image of the approriate note). This may be performed at the server before sending the page, or purely by scripts run at the browser.
- A highly relevant thesis on generation of graphical musical scores from text-based input can be found here. It details the workings of this website which converts GUIDO music notation (text input) into (an image of) the score.
October 22, 2007
22/10/2007 - Term 1, Week 4 (Start of)
In relation to the proposed tasks of week 3, the following work has been completed:
- An SVN repository has been set up (Task 1), this may be found at http://svn.draknek.org/notate
- Time has been spent researching possible structures for storing and transferring musical scores. Specifically, a previously developed format called MusicXML is being researched.
- A webserver has been set up that is compatible with Ruby on Rails. This will be used to host the final website and may be useful in terms of beta versions or prototypes that may be user-tested. It may be found at http://notate.draknek.org
- I have also been dedicating some thought towards changing the general aim of the system. At the moment the aim is:
To develop a web-application to allow musicians to easily and intuitively create and edit their own sheet-music online.
However, it may be more effective to instead, aim the system towards being a community in which people can share their musical scores with each other, perhaps rating each other's score and offering advice to one another. The essential requriements of the system would remain unchanged (An online sheet-music editor would still be included for users) but it would almost certainly mean more work in terms of the rest of the website. The situation remains undecided.
- Further requirements analysis of the system has yet to have begun (Task 2).
Time - The time spent working was mostly in-line with the proposed schedule for the week, with the exception of a few hours where other commitments had to take priority. In future, taking these sort of potential commitments into account should lead to a more realistic schedule. Overall, I spent about the same number of hours working as I intended.
Current Project State
Beginning of the second week of the two weeks allocated for system analysis (as laid out in the specification). All tasks previously associated with this phase need to have been completed by the end of the week.
Some time also needs to be spent considering what data structures will be useful for the storage and transfer of music scores.
Week 4 Tasks
- Finalise decision on how the aim of the project should be changed (if at all). Justify the choice.
- Decide on and complete appropriate analysis: Requirements Analysis and/or Use-Case Analysis.
- Finalise the decision on what tools will be used. Justify the choice.
- Research potential data structures for use within the system.
- Consider how the graphics in the system (musical symbols) will be obtained.
Week 4 Working Schedule
Total no. hours: 18.5
- The emphasis of this week is on the completion of the Analysis phase of development. After this milestone it should be possible to start the Design and Implementation of the system. It is important that documentation is produced this week that justifies and finalises the aim of the system, the requirements of the system and the tools that will be used throughout the rest of the development of the system.
- If it becomes clear that the full completion of the Analysis phase of development is too ambitious, I will complete as many of the tasks as I can this week and the project timeline will be re-designed next Monday to factor in a further week of Analysis. At some point in the week it may transpire that more analysis-tasks need to be completed than originally specified here anyway.
October 15, 2007
15/10/2007 - Term 1, Week 3 (Start of)
Current Project State
Following the completion of the specification, I now begin the Analysis phase of the project. According to the specification this will involve the following tasks:
- Clarification of what the system should do by carrying-out a requirements analysis or a use-case analysis.
- Research possible development tools, decide on what to use and then familiarise myself with them in preparation for the design and implementation of the system.
- Give some thought to how the graphics that will be needed for the system (especially musical symbols) will be obtained. Look into possible solutions (e.g. creating them from scratch, paying for an existing set, paying someone else to create them)
It has also been suggested by my supervisor that putting some work into creating early prototypes would be a good idea.
First of all, however, I will need to set up the SVN system that will be used throughout the course of the whole project. It will be necessary to complete this first so all documentation and code resulting from the next two weeks may be stored in this repository.
According to the current schedule I have 2 weeks to complete this phase of development.
Week 3 Tasks
- Set up SVN repository
- Decide on and begin appropriate analysis: Requirements Analysis and/or Use-Case Analysis
Week 3 Working Schedule
Total number of working hours planned: 14 hours
- The working schedule above overestimates how long each task will take to be completed and probably overestimates how many hours I will realistically be able to give. I have scheduled things this way out of uncertainty in my own time estimation abilities and to make sure that the work I have set out to do will be completed. As the weeks progress my hope is that I will become better experienced in estimating how long I will take to complete tasks. This should make my own work schedules easier to follow.
- Monday is not included in this schedule, as it was the day on which I set up this development blog and planned my work for the rest of the week. In general Monday will be the day on which I evaluate the work completed over the previous week and set out what work I intend to do over the next week. In the future it should not take so much time to complete these progress reports.
Last thursday I submitted the first version of the specification for this project, in accordance with this module's first deadline. The document itself may be found here:
This specification is expected to change significantly, several times, over the course of the project, particularly in terms of the project timeline. Elements of the timetable will change as the requirements of the Notate application are finalised and, as the tasks themselves are greater understood, it may become apparent that more time will need to be scheduled on specific activities that I am currently overlooking or underestimating. All future versions of the timetable will be made available on this page.
The initial project schedule may be found within the specification document, or a seperate version may be found here:
The intention for this page is for it to be regularly updated with weekly entries that will evaluate the work done over the last week and detail what work is intended for each upcoming week. There will also be entries marking significant decisions and changes in the development of the project. Furthermore, any documentation produced will be uploaded to this blog and linked to in an entry.
It will always be possible to see the most up-to-date version of the overall project timetable here, along with all previous versions. All entries that include information relating to timetable updates will be tagged 'Project-Timetable'.
Project supervisor: Sara Kalvala
Weekly supervisor meetings: 14:00 Thursdays in CS309
University of Warwick homepage: link
Module webpage: link
Module organiser: Steve Matthews