Week 8 Report

23/11/2007 - Term 1, Week 8 (end of)

Change from timetable

In the timetable provided for this term's work, the progress report is scheduled to be submitted to the university on Monday of week 10. This was a mistake (caused by an error on the module website at that time). The progress report is, in fact, due in Monday of week 9 (at the time of writing - three days to go).

Progress

Work has been done on designing the system and finalising design documentation in preparation for the progress report due in next week.

Project State

Currently, all my time is being spent on catching up with design documentation and writing a progress report that is due in for midday on Monday (26th November 2007). This progress report will mark the end of the design phase of development.

This report will detail where progress has differed from what was predicted over the last term and will present a revised timetable for the remainder of development time.

Week 8 Tasks

Complete and submit progress report.

: 23 Nov 2007 11:36 |  Tags: Weekly-Project-Report |  Comments (0) |  Close comments |  Report a problem

Week 7 Report

12/11/2007 - Term 1, Week 7 (Start of)

Progress

• Continued work on system design
• Continued work on prototype development

Progress Evaluation

I am on track to have the full design of the system completed by the end of term 1, which is as intended.

Current Project State

The system itself is in the process of being designed at the same time as a prototype is being developed. This is appropriate as it gives me an oppotunity to learn what practically works on in the browser, especially when taking into account the plethora of compatibility issues. This design will need to have been finalised by week 10, when the design phase needs to have finished and a progress report written.

Week 7 Tasks

1. Continue designing the system
2. Continue prototype development. Look into getting a server-side prototype up as well as javascript for the browser.
3. Look into the source of graphics for the system.

Weekly Schedule

: 12 Nov 2007 15:07 |  Tags: Weekly-Project-Report |  Comments (0) |  Close comments |  Report a problem

Week 6 Report

05/11/07 - Term 1, Week 6 (Start of)

Progress

• It has been decided what is to be used to create the software. Namely Ruby on Rails and Javascript
• Work has begun on a more functional prototype
• Some research has been done into how the music symbols might be obtained. It may be possible to find freely distributed music notation fonts on the internet (e.g. list of music fonts,here)

Progress Evaluation

Following the last supervisor meeting, it has been decided that I should get on with codins a working prototype of the system. Although what is actually going to be in the system has been decided, the exact structure of the scores in the browser - in the javascript has not been finalised. It would be good to design this.

Current Project State

I would describe the current project state as being a cross between design activities and implementation activities. The project development has become more agile than the specification originally implied to allow for the design of the system to change as prototypes are developed. 

Week 6 Tasks

1. Complete design of the data structures used in the system 
2. Continue development in Javascript and Ruby in Rails
3. Continue research into music-symbol graphics

Weekly Schedule

: 06 Nov 2007 18:07 |  Tags: Weekly-Project-Report |  Comments (0) |  Close comments |  Report a problem

Weekly Schedule

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:
http://blogs.warwick.ac.uk/files/notate/timetable_t1.png.

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.

Weekly Schedule

: 30 Oct 2007 11:53 |  Comments (0) |  Close comments |  Report a problem

Week 5 Report

29/10/2007 - Term 1, Week 5 (Start of)

Progress

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.
• Research has begun into what sort of development tools will be used throughout the project. So far Ruby on Rails, Python, PHP and Javascript have been considered. A conclusion has not yet been reached.

Progress Evaluation

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

1. Finalise choice developments tools
   
2. Finalise choice of data storage systems
3. Consider graphics requirements
   
4. Continue the development of prototypes of futher sophistication
5. Produce a set list of requirements

Week 5 Schedule

My general weekly schedule may be found here.

: 30 Oct 2007 11:46 |  Tags: Weekly-Project-Report |  Comments (0) |  Close comments |  Report a problem

Conclusion on Specification Change

Proposed Change

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:

specchange1.pdf

Decision

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.

: 25 Oct 2007 15:19 |  Tags: Project-Documentation |  Comments (0) |  Close comments |  Report a problem

Data Structure Research

It seems that there will be several main areas to consider when it comes to the storage of data in this system:

1. How to store personal user information and musical scores on the server.
2. What format should the scores be in to transfer them from the server to the client browser.
3. 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.
• As well as doing this the structure of the scores could be stored in a similar (or different) way as javascript objects that contain these visual html objects.
• It may be possible to send the pure (Music)XML to the browser and use an XSLT to convert it, on the fly, to html that can be displayed. Event-based Javascript would be used to update the XML in reaction to the user's actions.

Other  Comments

• 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.

: 24 Oct 2007 23:51 |  Comments (0) |  Close comments |  Report a problem

Week 4 Report

22/10/2007 - Term 1, Week 4 (Start of)

Progress

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 working on a Javascript prototype (Task 3). The aims of the prototype have been to research into the potential capabiltities of Javascript and to help me learn how to use it. Little functionality has been produced, but it has been useful in giving an overall impression of what the final score editor may look like. Screenshots may be found here.
• 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).
  

Progress Evaluation

Task Completion - In general, the amount of work completed this week was less than expected. Most notably I didn't get around to beginning the requirements/use-case analyses despite intending to seven days ago. However, this is due to the new uncertainty in the aim of the system and to the unexpectedly large number of hours spent experimenting with Javascript, and so is justifiable. Overall, progress is adequate, especially considering how early it is in the project lifespan. It is important to have completed these tasks by the end of this week however, which should mark the end of the Analysis phase.

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.

In conclusion, I would say I overestimated the amount of work I was capable of doing in the proposed time, especially when it came to research work (e.g. learning Javascript). In the future, it would be better to allow myself more time on research-type tasks.

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

1. Finalise decision on how the aim of the project should be changed (if at all). Justify the choice.
2. Decide on and complete appropriate analysis: Requirements Analysis and/or Use-Case Analysis.
3. Finalise the decision on what tools will be used. Justify the choice.
4. Research potential data structures for use within the system.
5. Consider how the graphics in the system (musical symbols) will be obtained.

Week 4 Working Schedule

Monday	14-16	2hrs
Tuesday	09-12	3hrs
Wednesday	11-12,13-17	5hrs
Thursday	10-12,13-14	3hrs
Friday	10-11:30	1.5hrs
Saturday	10-14	4hrs

Total no. hours: 18.5

Further Comments

• 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.

: 22 Oct 2007 13:30 |  Tags: Weekly-Project-Report |  Comments (1) |  Close comments |  Report a problem

Week 3 Report

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

1. Set up SVN repository
2. Decide on and begin appropriate analysis: Requirements Analysis and/or Use-Case Analysis
3. Start building a simple prototype of the intended music score editor in Javascript

Week 3 Working Schedule

Tuesday	0900-1200	3hrs
Wednesday	1300-1700	4hrs
Thursday	1000-1300	3hrs
Friday	-	0hrs
Saturday	1000-1400	4hrs

Total number of working hours planned:  14 hours

Further Comments

• 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.

: 15 Oct 2007 16:55 |  Tags: Weekly-Project-Report |  Comments (0) |  Close comments |  Report a problem

Specification Submission

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:

Project Specification (as originally submitted).

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:

timetable_01

: 15 Oct 2007 16:00 |  Tags: Project-Documentation Project-Timetable |  Comments (0) |  Close comments |  Report a problem