The project is geared towards an implementation of a simulation-based physical modelling sound synthesis framework in a highly parallel form, using the resources at the Parallel Computing Centre (EPCC). The framework itself allows a user (a composer) to create his own, possibly very complex percussion instrument, consisting of a network of connected objects, such as bars and plates, and then to ?play? it, by generating a score of hit times, locations, strengths, and then ?listen? to it by taking multichannel output from various locations on the instrument. The environment itself has already been prototyped in Matlab, and used by a professional composer in order to generate a short piece of music, performed this year at the Digital Audio Effects conference in Como, Italy. Sound quality is excellent, but run times are, however, quite slow---on the order of several minutes to generate a second of sound, for a reasonably complex instrument configuration. It would be extremely useful to have a fast implementation.
Another possibility would involve looking at GPUs in order to perform audio synthesis; a colleague of mine in Helsinki University of Technology (Lauri Savioja) is looking into this, with Nvidia, from the point of view of audio spatialization, but I think a synthesis engine is a possibility as well---so does he.
A further aim of the project would be to train a composer to use the system, and generate a piece of multichannel music, which could potentially be performed in the near future. I have worked with composers in the past, in Matlab, but figuring out a way in which a composer could work with HPC is not obvious?the musician wants to be able to experiment immediately, and not have to wait for jobs to be queued; in the longer term, real-time synthesis, suitable for live performance is desirable---this might be an argument for looking at the GPUs, rather than at EPCC as a solution.
By the way,
the title of the project here is maybe a little misleading...there's no music composition involved, just sound generation. Could we change this?
Stefan
Well, I suppose composition is still the longer term goal, and you would like to get a composer to work with it if you could, so I'm inclined to think we can leave the title as is?
I guess...but the composition tag sort of implies that we're doing something along the lines of algorithmic composition or even work at the cognitive level. This isn't that---it's number crunching at the level of sound generation only! We'd like to be able to link up with others doing FDTD modelling in other areas, and also people interested in non-musical sound (i.e., in virtual environments and games) so the composition tag might scare them off.
Stefan
an update...
the communication costs are, as expected, the big bottleneck.
We have considered going the route of diagonalization (pre run time), so as to sever the inter-node connections, but this has a huge number of disadvantages, especially in a synthesis environment. In essence, if you do this, you end up with the usual "modal" formulation where you are building sounds out of sine waves---which is ok for simple systems, but just awful if you want to generate more complex virtual objects, or deal with nonlinearities (which is how the sounds get interesting). Not to mention the big precomputation load (eigenvalue solver) and all the inherent problems...
So we've decided against this, and will be trying to do the best we can with sparsely connected schemes...
Stefan
IDEA Lab project
Submitted by sbilbao on Tue, 05/18/2010 - 14:58.Hi folks,
the project has been under way for about a month now, and involves several members of staff at EPCC, as well as an MSc student working along the same lines.
So far, we've been looking at ports of several "canonical" pieces of code from Matlab to C, and finding appropriate benchmarks suitable for audio...which is an interesting problem in itself! As it turns out, the algorithms are quite sensitive to rounding errors, and in single-precision, this leads, perceptually, to small frequency errors...which are imperceptible, but which lead to phase errors in the long term! So any sample-by-sample comparison of audio output will eventually, over a time scale of several seconds, lead to an apparently large deviation. So we've dropped this formulation of error, and are looking instead at a spectral magnitude comparison instead (i.e., phase eroors are not considered).
The Matlab-to-C ports are nearly done, and we're just now moving into the next phase of porting to the Tesla...I'm quite excited about not having to wait around for half an hour to produce a few seconds of audio!
More soon,
Stefan