The problem with data
Jacob Hart and I have been working on visualisation and interaction for computational musicology. This happens at the cross-section of the IRiMaS and FluCoMa projects, incorporating ideas, code and strategies from both. In the most recent HackSpace session, we spoke mostly about the problem of implementing or choosing a database technology. For context: we work from within Max 8, but may want to open our tools to other languages and software applications, so generic formats and exporting functions are crucial to these efforts.
Before looking to build our own technology to solve the problems of data storage and retrieval, we investigated existing solutions.
entrymatcher by Alex Harker:
entrymatcher ships with extremely rapid queries (especailly on the bleeding edge compiles), it’s querying language is not suited to our research aims and preferences compositional aims. Also, despite the existence of neat and concise C++ code to build into a Max object it would not be frictionless to port this particular object to other environments.
- simple access methods with a high ceiling for complexity
- portability: the SQLite database is a file that can be parsed in other languages and environments
- simple read mechanisms, just point toward the entire database contained in a file
Once thoroughly tested our tools for computational musicology will be released into the public domain, most likely through github. As we are currently in the early development stages we are also interested in fielding any comments or insight into this area of research.