1. Audio Timestretching Adam Lederer Prototype Slideshow

2. What It Is This is NOT the kind of timestretching I mean

3. The kind I mean Is more like this

4. But polyphonic! This is difficult to show Something like that

5. This is currently quite possible But neither common nor generally of high quality This timestretching doesn't sound very good!

6. A more thorough Definition of the Mission To process an audio file in such a way as to stretch the sound events therein across a longer timescale, but also preserving pitches/frequencies and their changes over time, in keeping with the preservation of general subjective impression to the greatest possible subjective extent, and introducing as little artifacting as possible.

7. Transient Detection Transient detection is one thing I want to apply to my approach, to see whether it makes a difference or not. With transient detection, I would time-stretch each individual “hit” individually, and then process them separately. Alternatively, I could use the transients to indicate frequency elements being introduced into the mix, and could use those as critical points to determine sound-signatures, to help me isolate them, if necessary.

8. The most basic function necessary for my project: FFT This is something I've been wanting to write/learn more about for a while, since it's rather fundamental, so that's the first function I'll be implementing. One approach could be a pure frequency-based time-interpolation method, but that wouldn't preserve general impression (I'm looking more for an exponential/logarithmic response to transients), and I don't know whether or not artifacting would be a problem. It's an approach I will explore.

9. Progress Timestretching: Is not here. I've been working on implementing it in a cross- platform audio/GUI library called JUCE. JUCE is not a very stable library, but I've been learning to use it and learning to use Linux for developing over the course of the year. Although it's difficult to work with, I highly recommend JUCE as a very capable library with a logical, if convoluted, architecture.

10. Progress 2 As a lowly, amateur developer, I have been fumbling around with bugs and compile errors and learning to make simple GUI's and audio playback, and dealing with issues both self-created and out of my control, rather than implementing any interesting or progressive elements of the project, such as the actual purpose of the project (Audio Timestretching), or transient detection, or FFT (although FFT is next on the list, as I've abandoned audio playback for now).

11. Lessons Learned I've decided it wasn't the wrong decision to use JUCE, although it would have been easier to use Java – JUCE gives me the option of porting the project to a real-time format, whereas Java does not, and would be too slow anyway. However, I have learned to be a better coder. Not a lot better, but better. I have a better idea, now, of how much time bugs and errors and administration issues can take up, especially when you don't have access to administer to the development system.

12. Lesson learned, in short Always try to develop on a computer you yourself have full control over. Also, it can be frustrating to unwittingly be part of the beta process for a technology you hoped to use productively.

13. What JUCE looks like Here's a screenshot from one of the demo projects I made to learn how to use the JUCE library: Note that the audio functions don't actually work in this example, although they were on the way there before I scrapped them, realizing I was using too old of a version of the library to correctly use Linux audio.