Project Ideas

Below you will find a handful of ideas for projects that might be appropriate for some of the participants in my two seminar courses. These are not intended to be definitive, exhaustive or even recommended project descriptions. I may add more ideas here over the next week. Read more for details ...

Building Tools for Musicians

Tablets for DAW control

Wacom (and similar tablets) offer a powerful, flexible control surface. Tablet2MIDI is an interesting tool for designing new MIDI-based control systems with a tablet. The screenshot at left is another example of such a control/GUI system. Project consists of two critical ingredients: (a) deciding what should be controllable, and how (what kinds of user input/motion etc.) (b) implementing something like Tablet2MIDI but to generate OSC to control Ardour or another DAW that understands OSC (Live could be used, for example). An initial implementation can be done using Max or Pure Data, but project would ideally create a new standalone application for tablet control surface design and use.

Using iphone/ipod touch or similar devices for control

Similar to the tablet project, but some difference in emphasis. The software already exists (Mrmr, TouchOSC, etc), so the issue is how best to use it (possibly fixing bugs along the way). Most existing demonstrations of this technology focus on a single static control GUI with just a few parameters. The project will involve designing a user interface that permits intuitive control of a system with many heirarchically arranged parameters. The target system is up to you, but it must be complex. Ardour is one candidate. Anyone involved in this project will need access to an ipod touch or iphone for at least part of the project. I may be able to arrange this, but it would be great if a student could do this themselves.Note: there could be more than one instance of this project

Physical/Digital Control Systems in Musical Instruments

aka "Why you can't play a synthesizer like a violin" ... this would be a paper project without an accompanying "implementation". Research, document, catalog, classify, critique the differences between direct physical control over an instrument (e.g. hitting, bowing, plucking, blowing, etc) and control via analog or digital systems (e.g. knob twiddling, MIDI, OSC, custom protocols). Examine the ways that these two fundamentally different approaches to control over sound-making affect the sound-making process. Suggest ways to expand the capabilities of either approach, to merge them or explain why they will never be equivalent.

DAW Design and Implementation

Scrubbing analysis and implementation

Carefully investigate scrubbing operations when using tape, ProTools, Logic, Live, including detailed signal analysis. Combine with with a use-case costs & benefits of different scrubbing models, preferably definitively identifying the best techique or designing a new one that merges the best of those studied. Implement. Initial implementation can use memory-resident data, but project should conclude with (at least) an indication of how to extend to disk-streamed data, and preferably an implementation.

Feature Analysis Fun

Get familiar with the feature-detecting VAMP plugins. Ardour already uses two VAMP plugins for note detection and percussive onset detection, to facilitate automated region splitting by the Rhythmn Ferret. But VAMP offers a lot more. Come up with some interesting ideas for how to use feature detection in the context of a DAW - they could be imitative of some existing product or something new. Implement. The framework for using VAMP inside Ardour is already established, so actually running the plugin is relatively easy. Understanding the plugins, what you could do with them, and actually doing something with them is up to you.

Studying process-level separation in a DAW

There are lots of good reasons to split apart the engine of a DAW and its GUI(s) into different processes connected by a communication protocol. So far, this has never been done in any significant way. This project would involve studying the performance costs of this separation, probably focused on two of the hardest areas: metering and waveform display. The data for both of these "belongs" to the engine, but must be displayed in the GUI. Design ways to efficiently share information required by the GUI, both on the same machine and potentially across a network. The goal is a proof-of-concept implementation that shows metering and waveform display, and at least 3 or 4 examples of notifications from the engine to GUI (e.g. "transport is moving") and similarly, 3 or 4 examples of control of the engine by the GUI (e.g. "start transport moving").

Multichannel 2d panning

Somewhere between traditional stereo panning and ambisonics is 2d panning, in which sound sources can be moved to any point on a plane, along with the monitor positions. More generic than commercial surround sound (5.1, 7.1 etc), there is no good implementation of this available, and if one exists that I don't know about, it will be built into a workstation. This project would specifically involve using JACK to create a standalone panning application to map N channels to M monitors. Channels/sources and speakers should be mobile (emphasis on sources), without audible artifacts. Placement outside the monitor positions implies handling delays - an interesting alternative to interpolating delay lines might be to use physical modelling of doppler effects, though the choice is up to you. The implementation should include a GUI to control its function, which can be part of the same process or remote-control via OSC or some similar protocol. Particular attention in the GUI to how to avoid information overload is required. A sufficiently ambitious target for this project could satisfy both seminar project requirements.

Parallelizing DSP in Ardour

Not a task for the weak of heart or spirit! Ardour's current handling of audio processing is deliberately single-threaded. Its reasonably obvious how to parallelize this. The work will involve adding a worker thread pool, using per-cpu buffers to replace all the current session-wide buffers, and dataflow analysis for scheduling (probably copying passive Jackdmp's model, or maybe something else). Careful instrumentation of the results, and exploration of the user of processor affinity and IRQ routing would also be interesting. If all these terms make some kind of sense to you, you could be right person for this task.