Plans for Halebopp 2009.1.1

The next year has arrived and a new release of Halebopp is due. That would be easy to manage if I had actually done anything in the past weeks. Since I have not, here is a list of things I want to address before the next release.

This is more like a laundry list for myself, so please don't be too disappointed about its formality.

• I feel blocked by the impression that the app could already use some refactoring. Here are a few points of critique:
  
• The song database wrapper is monolithic and can not be extended by components. Accessing objects in the database has to be individually written, although I know that it can be done in a more generic way. A solution would be to add support for transparent DB objects, which, based on a list of typed attributes, can serialize attribute changes to and from the database. I call the class SQLRecordProxy. A class could inherit from SQLRecordProxy to be able to transparently access the database through its attributes. DONE
  
• I do not feel comfortable at all with wave files being contained in the database. It makes debugging hard, and requires a non-SQL blob I/O interface. Doing this with raw binary files will simplify streaming and recording code, and makes auditing in an external program possible. Additionally, C++ code could access wave data without interfacing to Python. DONE
  
• Importing a wave stalls the program for the time of loading. I need to import from streams, perhaps threaded.
  
• Building wave visualizations can take a long time. This should be done in a thread as well.
• I need rhythm in the program to make it useful. Q-grids will provide a facility to organize rhythm and tempo. SQLRecordProxy will ease the implementation of Q-grids. PARTIALLY DONE
  
• It must be possible to duplicate clips.
• Multiselection is whack and needs to be standardized and properly reflected visually.
• I must find a good way to browse samples. If that isn't possible, allow drag and drop for samples at least.

Update: I am currently working on refactoring Halebopp as planned above, here are some remarks on implementation as I go along (just for housekeeping and showing off):

• SQLRecordProxy was finally named SQLRecord, and works as described, there is a set of loose tests contained in the sqlobject module as well.
• I chopped down the song database facade and used SQLRecord for waves, tracks and loops. The code is much easier to read and extend now. The song database has been renamed to "song.db2", because table structure is incompatible to earlier versions.
  
• Waves and digest data have been moved from blobs to external .raw and .digest files stored in a /wavestore subfolder relative to the database. The files contain no header, just pure data, so the files size equals the length of the sample.
• QGrids have a kind of visual representation, but are practically not editable at the moment, neither do they provide a metronome.