Development - Godley/Music-Library GitHub Wiki

Methodology

Please don't just contribute a random block of code without consideration for how this project has been developed previously. I originally used no methodology and the code got messy. I started using TDD, hence you will find a folder of tests for every primary objective. I then started reporting issues, then TDDing, then closing issues.

Working

If you want to find something to work on, before you go off hunting for it, check the issues. They are organised into separate milestones which either relate to an objective or a goal. When you're working on something assign it to yourself.

Infrastructure

This app separates into 4 primary objectives, each of which are mostly independent of each other. To understand the infrastructure I'll explain a bit about how each one works individually, and how they interact with each other.

General notes

This app uses cross platform libraries for basically everything and I'd like to keep it that way. The only requirement for installation and development before working with bits of the system is to have LilyPond installed, as you can see from the installation instructions.

Rendering System

code: MuseParse The program has in it a system of rendering sheet music. The library used in this program is separated into another Repo as well as an entry on pypi. You can find more details on it in the other repo.

Metadata scanner

code: implementation/primaries/ExtractMetadata/classes This objective handles a lot of different things and is essentially the brains of the outfit. There's about 5 classes relating to this bit:

  • FolderBrowser: Basically this is what does the scanning for new files. You give it a list of files in the db, it gets a list of the files in the folder (xml and mxl files included), gives 3 diff lists:
    • new mxl files
    • old files: files which are in the database but aren't in the folder
    • new files: files which are in the folder but aren't in the database
  • Unzipper: takes a list of mxl files, unzips them and deletes the intermediary files.
  • DataLayer: communicates with an SQLite file, runs SQL queries etc.
  • MetadataParser: scans an XML file for information. Uses SAX same as the rendering system
  • MusicManager: connects all the bits together. This also connects with the API manager mentioned next

Flow

Basic operation of this section is as follows: Music Manager is initialised and ran by the application. It's given a folder to start with. The music manager will then initialise the DataLayer - if there's no music db file in the folder then it will create it and create a bunch of tables. From this the Music manager will fetch a list of all the offline files in the database - aka files belonging to the user which already were in that folder. It then gives that list to the FolderBrowser object, which comes back with the lists given. From this the music manager will:

  • give the MXL files to the unzipper
  • concatenate the new xml files with the new ones from the folder browser
  • scan each file in turn for data using the metadata scanner
  • tell the data layer to archive the old files
  • give the data layer the data collected from the new ones

Searching

This is perhaps the most simple objective: searching. Basically, this allows the user to enter text in either the search box of the main window, or the search box of the playlist window. It's really just a method which parses the input and is given back to the MusicManager to send the queries to the data layer. If more explanation is needed than that then please prod me.

API layer

Next up is the API or online sources objective. This splits into 2 classes:

  • API: this class is to be subclassed by all APIs and is really abstract. You can't use this standalone because it will throw not implemented exceptions everywhere. The idea is it provides all the methods an API class should provide so we can use all of them without thinking too much about how they do the work. Subclassed by MScoreAPI.
  • API manager: maintains a dictionary of sources to collect data from, handles grabbing large sets of files and asking each API for info about them. Passes all that data back to the MusicManager for processing.

If the API layer is to be extended, then the dev should first subclass the API class - you may use MScoreAPI as an example of how and what is expected from each method. Then add this source to the dictionary in API manager, with an instantiation of the class you created and a unique string of the source.