The Jammin music composition software has been designed to provide users with compositional, audio processing and communication tools. Jammin supports musicians with its familiar music data structure based upon note/sound events, and provides methods for organising, manipulating, sharing and analysing that musical data. Jammin scores can be rendered as MIDI or audio files for storage and later processing or playback in real-time. Jammin can read and write MIDI files, audio files, and its own .jam files.
It was a group project in 2007 involving six undergrads (inc myself) in their third year studying a computer science or software-engineering degree. It as a small approx 3 month project for one of our papers for which we chose to develop a musical composition tool which we named “Jammin”. The team consisted of the following:
- Michael Walmsley (Classical tracks and Arrangement)
- Frances Bourke (Beat tracks)
- Scott Thompson (Rythmn tracks)
- Paul Klein (Back-end server
- Myself (Client-side networking and GUI)
- Ryan O’ Conner (Main GUI and IO management).
One of the team ended up dropping the paper because of time constraints / personal reasons so the project actually involved five of us. Lesson learnt: The more people involved in a single project increases the complexity of the development! Of coarse, theres a huge benifit for with working as a team, but on a small-size project with many people the benifts begin to drop off.
When I can be bother / someone asks … the binaries / manual… and source/docs/tests etc…
It is wirtten in java. The musical scores uses JMusic (http://jmusic.ci.qut.edu.au/) – which was very messy and buggy, Michael had to fix a lot of bugs and made improvements with the interactions. The networking uses TCP… for sharing the muscial compoistions I wrote a simple file transfer protocol called JCP (Jammin Commications Protocol). This was my first networking project and the comminations was rather crude but does the job! Most of my efforts was seperating the client-side networking model from the GUI – the GUI then become trivial to implement.
The purpose of the project was really to learn about working in a team on a single project so we used a bunch of tools for keeping our source understandable, reliable and protected. We used oldschool CVS and ant. We took on a lightweight agile methodology:
Jumble is really good! Its a tool that has been developed at Waikato University which mutates your code and reruns your unit tests and grades your tests to see how well they actually test the code your trying to test. Like testing for coverage. Find jumble at: http://jumble.sourceforge.net/ – use it! We alsoused “the poor mans approach to integrity checks” at the class level. Another simple method for improving quality of code without too much effort – using JUnit for verbose feedback on failed integrity checks at realtime.
Other neat tools we used were: Ant, Check-Style plugin for Eclipse, CVS and some CVS Management tool which integrated JUnit, Jumble and Checkstyle…
The GUI was prettied up using substance (https://substance.dev.java.net/).